No longer possible to indicate possibly-problematic reviews

RESOLVED FIXED in 3.2

Status

addons.mozilla.org Graveyard
Public Pages
RESOLVED FIXED
10 years ago
a year ago

People

(Reporter: Xavier, Assigned: wenzel)

Tracking

Dependency tree / graph

Details

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
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
(Reporter)

Comment 3

10 years ago
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
(Reporter)

Comment 6

10 years ago
In the old system, it was possible to tell why a comment was flagged. It was very convenient.
(Assignee)

Comment 7

10 years ago
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
(Assignee)

Comment 8

10 years ago
Created attachment 273593 [details]
Production DB changes
(Assignee)

Comment 9

10 years ago
Created attachment 273594 [details] [diff] [review]
Database and development data changes
(Assignee)

Comment 10

10 years ago
Created attachment 273596 [details] [diff] [review]
Changes to the editor pages
Attachment #273596 - Flags: review?(fligtar)
(Assignee)

Comment 11

10 years ago
Created attachment 273598 [details] [diff] [review]
Frontend (and related) changes
(Assignee)

Comment 12

10 years ago
Created attachment 273599 [details] [diff] [review]
L10n additions (en-US only)
(Assignee)

Updated

10 years ago
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+
(Assignee)

Comment 14

10 years ago
Thanks, flig: I will replace the test you mentioned by the one we have already, so we don't carry around duplicate code.
(Assignee)

Comment 15

10 years ago
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.
Attachment #273598 - Attachment is obsolete: true
Attachment #275789 - Flags: review?(morgamic)
(Assignee)

Updated

10 years ago
Attachment #273599 - Flags: review?(clouserw)
(Assignee)

Comment 16

10 years ago
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.
Attachment #273593 - Attachment is obsolete: true
Attachment #275790 - Flags: review?(morgamic)
(Assignee)

Comment 17

10 years ago
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.
Attachment #273594 - Attachment is obsolete: true
Attachment #275791 - Flags: review?(morgamic)

Updated

10 years ago
Attachment #273599 - Flags: review?(clouserw) → review+
Attachment #275789 - Flags: review?(morgamic) → review+
Attachment #275790 - Flags: review?(morgamic) → review+
Attachment #275791 - Flags: review?(morgamic) → review+
(Assignee)

Comment 18

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 19

10 years ago
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 → ---
(Assignee)

Comment 20

10 years ago
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
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
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.