Closed Bug 376766 Opened 15 years ago Closed 14 years ago

No longer possible to indicate possibly-problematic reviews

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: xavier, Assigned: wenzel)

References

Details

Attachments

(5 files, 3 obsolete files)

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.
Sorry this is not security related but I've no way to uncheck it now.
Version: unspecified → 3.0
Reviews are automatically moderated now and don't appear until an editor approves them.
Group: update-security
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.
Status: UNCONFIRMED → NEW
Component: Developer Pages → Public Pages
Ever confirmed: true
OS: Windows Vista → All
QA Contact: developers → web-ui
Hardware: PC → All
Summary: No longer possible to ask for deletion of offensive review → No longer possible to indicate possibly-problematic reviews
Target Milestone: --- → 3.2
Will look at reimplementing something resembling the old system, except we will want to know why things are flagged.
Assignee: nobody → fwenzel
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.
Status: NEW → ASSIGNED
Attached file Production DB changes (obsolete) —
Attachment #273596 - Flags: review?(fligtar)
Attached patch Frontend (and related) changes (obsolete) — Splinter Review
Depends on: 384797
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().
Attachment #273596 - Flags: review?(fligtar) → review+
Thanks, flig: I will replace the test you mentioned by the one we have already, so we don't carry around duplicate code.
This changend frontend patch uses Amo->checkOwnership as opposed to a (redundant) new function, which I removed. Thanks, fligtar.
Attachment #273598 - Attachment is obsolete: true
Attachment #275789 - Flags: review?(morgamic)
Attachment #273599 - Flags: review?(clouserw)
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.
Attachment #273593 - Attachment is obsolete: true
Attachment #275790 - Flags: review?(morgamic)
The revised dev data patch represents the changes (to be) made to the production database in comment 16.
Attachment #273594 - Attachment is obsolete: true
Attachment #275791 - Flags: review?(morgamic)
Attachment #273599 - Flags: review?(clouserw) → review+
Attachment #275789 - Flags: review?(morgamic) → review+
Attachment #275790 - Flags: review?(morgamic) → review+
Attachment #275791 - Flags: review?(morgamic) → review+
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.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Depends on: 395088
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.