[Task]: Reviewer actions and user notifications inventory #15068
Comments
wagnerand
added
needs:info
repository:addons-server
|
@ioanarusiczki Is this something you or your team can help us with? |
|
@wagnerand yes we will take care of QA work on this. |
|
That's still in progress but you can check the emails I attached in the urls below ( if you open an attachment from testrail, you must click full resolution to make content readable). I've done 2 examples for theme escalated because emails should be the same as for extensions reported for add-on policies , there is not point for me to go in circles. addon is reported for add-on policies scenario 1,2,3,4 Scenario 1 https://mozilla.testrail.io/index.php?/cases/view/2766682 theme report from Cinder is escalated to amo I've noticed this afternoon that when content is disabled from Cinder, emails sent to authors no longer have the last paragraph with the appeals url -> this is only on -dev (on -stage it's still as before). email sent for a theme disabled from Cinder on dev
email sent for a theme disabled from rev tools on dev
|
|
Thanks. I am not sure I follow all the scenarios. Andrew created an overview just last week, maybe this helps with the testing? It's unclear to which high-level scenarios we are testing for each of the test scenarios. I have not looked at the actual emails yet.
This looks like we deny an abuse report. This can be either done via Resolve jobs -> Approve or with one of the dedicated approval actions.
Looks like abuse-report deny because not enough info or developer feedback. This looks clear.
This appears to be the Grant variant of scenario 1, with a force-disable action. What about a rejection of versions?
This looks like accepting an abuse report and choosing Rejections (mentioned in scenario 2). The appeal case of the author is unclear to me. What is the relation to the new version? The new version can be ok or not ok, and also the appeal for the old version(s) can be granted or denied independently.
How is this different two the first part of scenario 2? Is it just about denying the appeal here, where it was a grant in 2? I'll stop here, all in all it's very difficult for me to understand the scenarios, to see if we covered everything and what the expected emails should be compared to the ones we are actually sending. Can we expand the scenario description and create an overview of all the different scenarios? Thank you. |
|
I tried gathering some examples focusing on the emails sent and the comments done by reviewers in the past 2 weeks, that was the main focus. Ofc there could be many other aspects to focus on when it comes to abuse reports testing. I looked at the guidance , this will help for a few actions that I did not try or focus too much along the year such as approve multiple versions and confirm approval. What I tested with was Approve (as approve an addon version) and the Approve from Resolve reports section (yeah, confusing a bit, there are many ways to get the same email). Making checks on reporting a guid for an unlisted version not installed I see no problems so far and same emails are sent with what's already in my examples above. My main focus since January was on listed approved versions. The unlisted versions were later resolved as how it should behave The only thing I do not understand is at Developer Appeal Grant -> I never unrejected versions first before approving a new version (not sure why that is required).
If by high level scenarios you mean #15074 then this has been quite recently introduced and it only covers the Cinder reports. We're at #15085 for now (in progress).
The answer is yes, this scenario can be done with reject or force disable from rev tools but I did not have the time these weeks to try so many scenarios and make notes. Reason why I used reject at scenario 3 which is how scenario 2 would continue when the developer sends the appeal and decision taken by the reviewer is to reinstate content. Scenario 2 Content not taken down, reporter appeals, we change the decision and disable. The content goes down, the author can appeal (the only time an appeal decision can be appealed)
All I know (from qa point of view) is that techicaly when Reject is used to take content down then you need a new version for approval to reinstate content. Has been done with #9496 after discussions that unreject wouldn't work #9471.
It is not, the difference is that scenario 2 includes that the report is first denied (with approve actions, as already described at scenario1), reporter sends the appeal and the second time it's granted -> this will generate a new email which is sent to the reporter (that the initial decision was incorrect), this email is not present with scenarios 1,3 or 4. What I try to say is that going through these scenarios even if I did not use all possible reviewer actions with each, the emails are pretty much what I've already added in these test cases. I think you should take a look, there is a small difference in content between versions rejected versus addon disabled (the emails sent to authors when content is disabled) which is expected, I've verified this a while ago and repeatedly all year round when doing regression testing. |
Description
With DSA, there have been some changes to which party is informed when with what information. The reviewer tools indicate for many actions whether a notification email is sent or not, but it is not clear if this is still accurate. Also, it is unclear to reviewers if the review comments are included in the email or not.
Before making any changes, we want to get an inventory of the current state.
Acceptance Criteria
Milestones/checkpoints
Checks
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: