User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:18.104.22.168) Gecko/20070309 Firefox/22.214.171.124
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.
Steps to Reproduce:
Sorry this is not security related but I've no way to uncheck it now.
Reviews are automatically moderated now and don't appear until an editor approves them.
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.
Moving to Public Pages, as the link would be next to Delete on the reviews and the flagging would be on the public side.
Will look at reimplementing something resembling the old system, except we will want to know why things are flagged.
In the old system, it was possible to tell why a comment was flagged. It was very convenient.
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.
Created attachment 273593 [details]
Production DB changes
Created attachment 273594 [details] [diff] [review]
Database and development data changes
Created attachment 273596 [details] [diff] [review]
Changes to the editor pages
Created attachment 273598 [details] [diff] [review]
Frontend (and related) changes
Created attachment 273599 [details] [diff] [review]
L10n additions (en-US only)
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().
Thanks, flig: I will replace the test you mentioned by the one we have already, so we don't carry around duplicate code.
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.
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.
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.
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.
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.
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.