376766 - No longer possible to indicate possibly-problematic reviews

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Xavier]

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]

Sorry this is not security related but I've no way to uncheck it now.

Comment 2

[Justin Scott [:fligtar]]

Reviews are automatically moderated now and don't appear until an editor approves them.

Comment 3

[Xavier]

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]]

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]]

Will look at reimplementing something resembling the old system, except we will want to know why things are flagged.

Comment 6

[Xavier]

In the old system, it was possible to tell why a comment was flagged. It was very convenient.

Comment 7

[Fred Wenzel [:wenzel]]

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]]

Attachment: Production DB changes

Comment 9

[Fred Wenzel [:wenzel]]

Attachment: Database and development data changes

Comment 10

[Fred Wenzel [:wenzel]]

Attachment: Changes to the editor pages

Comment 11

[Fred Wenzel [:wenzel]]

Attachment: Frontend (and related) changes

Comment 12

[Fred Wenzel [:wenzel]]

Attachment: L10n additions (en-US only)

Comment 13

[Justin Scott [:fligtar]]

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]]

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]]

Attachment: 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]]

Attachment: 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]]

Attachment: 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]]

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]]

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]]

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.