Last Comment Bug 376766 - No longer possible to indicate possibly-problematic reviews
: No longer possible to indicate possibly-problematic reviews
Status: RESOLVED FIXED
:
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Public Pages (show other bugs)
: 3.0
: All All
: -- normal
: 3.2
Assigned To: Fred Wenzel [:wenzel]
:
Mentors:
Depends on: 384797 395088
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-06 19:42 PDT by Xavier
Modified: 2016-02-04 14:51 PST (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Production DB changes (353 bytes, text/plain)
2007-07-24 09:22 PDT, Fred Wenzel [:wenzel]
no flags Details
Database and development data changes (3.86 KB, patch)
2007-07-24 09:30 PDT, Fred Wenzel [:wenzel]
no flags Details | Diff | Splinter Review
Changes to the editor pages (2.78 KB, patch)
2007-07-24 09:32 PDT, Fred Wenzel [:wenzel]
fligtar+bugs: review+
Details | Diff | Splinter Review
Frontend (and related) changes (14.20 KB, patch)
2007-07-24 09:35 PDT, Fred Wenzel [:wenzel]
no flags Details | Diff | Splinter Review
L10n additions (en-US only) (2.07 KB, patch)
2007-07-24 09:35 PDT, Fred Wenzel [:wenzel]
wclouser: review+
Details | Diff | Splinter Review
Frontend patch, revision 1 (13.46 KB, patch)
2007-08-08 09:10 PDT, Fred Wenzel [:wenzel]
morgamic: review+
Details | Diff | Splinter Review
Production DB changes, revision 1 (482 bytes, text/plain)
2007-08-08 09:14 PDT, Fred Wenzel [:wenzel]
morgamic: review+
Details
Database and dev data changes, revision 1 (3.97 KB, patch)
2007-08-08 09:17 PDT, Fred Wenzel [:wenzel]
morgamic: review+
Details | Diff | Splinter Review

Description Xavier 2007-04-06 19:42:30 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 

With add-ons website release 3.0, there is no longer a way to ask for a review deletion, so anyone (including competitors) can post really nasty stuff with lies and bad rate to frighten people...
This is not a duplicate of bug #371854.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Xavier 2007-04-06 19:44:38 PDT
Sorry this is not security related but I've no way to uncheck it now.
Comment 2 Justin Scott [:fligtar] 2007-04-06 21:48:12 PDT
Reviews are automatically moderated now and don't appear until an editor approves them.
Comment 3 Xavier 2007-04-07 01:09:41 PDT
But an editor is unable to know what is true and what is not.

Two days ago, one of my extensions was rated 4 for not being customizable, and more precisely not allowing the user to hide it.
This is clearly a user ignoring the Firefox functionnality to hide/show a tool bar with the context menu.
That gives a false impression on the extension, and there is nothing I can do, which I find really unfair.
Comment 4 Justin Scott [:fligtar] 2007-04-19 17:13:08 PDT
Moving to Public Pages, as the link would be next to Delete on the reviews and the flagging would be on the public side.
Comment 5 Michael Morgan [:morgamic] 2007-06-20 13:51:00 PDT
Will look at reimplementing something resembling the old system, except we will want to know why things are flagged.
Comment 6 Xavier 2007-06-28 02:35:45 PDT
In the old system, it was possible to tell why a comment was flagged. It was very convenient.
Comment 7 Fred Wenzel [:wenzel] 2007-07-24 08:14:42 PDT
We agreed on letting developers reply to reviews (once), in order to allow them to address possibly critical points raised in someone's review.

The reasoning is that reviews are moderated before they are published, anyway. So there should rarely be the case that a review is highly inappropriate. We should then be able to handle these exceptions individually by having the developer email amo-editors.

Usually however, in the average case, the developer should be fine with commenting on reviews to straighten out unclear details in the review.

I have a patch for this in the queue which I will have reviewed in a little while.
Comment 8 Fred Wenzel [:wenzel] 2007-07-24 09:22:07 PDT
Created attachment 273593 [details]
Production DB changes
Comment 9 Fred Wenzel [:wenzel] 2007-07-24 09:30:28 PDT
Created attachment 273594 [details] [diff] [review]
Database and development data changes
Comment 10 Fred Wenzel [:wenzel] 2007-07-24 09:32:02 PDT
Created attachment 273596 [details] [diff] [review]
Changes to the editor pages
Comment 11 Fred Wenzel [:wenzel] 2007-07-24 09:35:23 PDT
Created attachment 273598 [details] [diff] [review]
Frontend (and related) changes
Comment 12 Fred Wenzel [:wenzel] 2007-07-24 09:35:54 PDT
Created attachment 273599 [details] [diff] [review]
L10n additions (en-US only)
Comment 13 Justin Scott [:fligtar] 2007-07-29 02:44:46 PDT
Comment on attachment 273596 [details] [diff] [review]
Changes to the editor pages

Sorry for the delay; looks good!

My only comment (and it's not even about this patch) is that instead of adding the new permissions check in the addon model, you could use AmoComponent->checkOwnership().
Comment 14 Fred Wenzel [:wenzel] 2007-08-02 09:07:55 PDT
Thanks, flig: I will replace the test you mentioned by the one we have already, so we don't carry around duplicate code.
Comment 15 Fred Wenzel [:wenzel] 2007-08-08 09:10:37 PDT
Created attachment 275789 [details] [diff] [review]
Frontend patch, revision 1

This changend frontend patch uses Amo->checkOwnership as opposed to a (redundant) new function, which I removed. Thanks, fligtar.
Comment 16 Fred Wenzel [:wenzel] 2007-08-08 09:14:38 PDT
Created attachment 275790 [details]
Production DB changes, revision 1

Another change to the production DB structure was necessary: The UNIQUE key refusing multiple replies by the same author to the same addon was too restrictive, keeping devs from replying to multiple reviews on their addons.
Comment 17 Fred Wenzel [:wenzel] 2007-08-08 09:17:21 PDT
Created attachment 275791 [details] [diff] [review]
Database and dev data changes, revision 1

The revised dev data patch represents the changes (to be) made to the production database in comment 16.
Comment 18 Fred Wenzel [:wenzel] 2007-08-29 12:26:05 PDT
This is checked in, r6361. (Non-en-US) locale changes are in r6362. There will be website updates going on today. Please reopen if you find any issues with it.
Comment 19 Fred Wenzel [:wenzel] 2007-08-31 16:07:13 PDT
I just had to back out this patch (r6474) because it didn't behave as expected on the staging environment, while on our dev copies it works fine. We will have to further investigate where the point of failure was, but for now we shouldn't have this patch delay other updates being pushed to production.
Comment 20 Fred Wenzel [:wenzel] 2007-09-05 15:35:12 PDT
This is in the trunk (again), r6589. The problem was CakePHP's model cache, as described in http://fredericiana.com/2007/09/05/cakephp-delete-cached-models-on-database-change/ .

It will go online with the next push.

Note You need to log in before you can comment on or make changes to this bug.