Comment 5 for bug 719843

On Sat, May 7, 2011 at 11:57 AM, Aaron Peachey <email address hidden> wrote:

> In terms of the db and backend implementation my immediate thought is to
> create a new table for deleted (due to modification) reviews so they can
> stay on record. The table would act pretty much like an audit history
> table in a normal commercial app db and the 'modified' review would just
> replace it in the main Reviews table.
>

Hi Aaron (sorry for not getting back earlier - UDS and all that). Do we need
to keep an audit history if we only allow editing of a review for the first
few hours?

>
> This way, if there is any questionable content in any of the earlier
> reviews and an issue arises later, we still retain a record of
> everything the user has submitted, just in case. By moving it to a
> different table we would not be unnecessarily bloating the main reviews
> table.
>
> A couple of other points:
> a. Do we need to limit the number of times a user can modify their review?
>

I don't think so - I think enabling them to edit as many times as they want
for the first X minutes/hours after creation is ok? If they need to re-write
it after that, they can delete it and start again as you mention.

> b. If a review has been flagged and is awaiting moderation, how do we
> handle user trying to modify it?
>

Good point - I think if it has been manually flagged by someone, we should
not allow it to be edited until it has been moderated. What do you think?

> c. Should there be a time limit on how long after submitting the review a
> user is able to modify it before it is 'locked' for modification?
>

Yes, I think that would make most sense.