Closed Bug 859854 Opened 12 years ago Closed 12 years ago

Approving an article should not trigger a notification to the author of a rejected revision

Categories

(support.mozilla.org :: Knowledge Base Software, task)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: underpass_bugzilla, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0 Build ID: 20130401192816 Steps to reproduce: Contributor1 adds a revision of an article A reviewer rejects his revision Then Contributor2 adds another revision A reviewer states that the second revision is good and approves it Actual results: The message is sent both to Contributor1 and Contributor2, even if Contributor1 has not added anything to the article. Expected results: The credits should be sent only to Contributor2 since only his contribution has been taken into account.
Maybe we should be using the same filter we used in bug 628634 where we add all editors of non-rejected articles to the contributors. So, in this case maybe we should only be emailing authors of non rejected revisions? So if there is an author with an unreviewed revision in between, they will get the email.
Actually, this is working as designed. See bug 685578
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Sorry, rrosario, I don't see the point: if you decide that everyone has contributed to an article, then their names should be visible in the bottom of the page of every article. On the other side, if someone fills an article revision with spam, and hopefully I reject the revision, why should this use be notified?
I think if there is spam, the revision should be deleted. But anyway, I don't really care either way. I am just saying we implemented what was requested and your request conflicts with the original spec. So, I guess Verdi and Topal should chime in :) Thanks.
For me it would be Ok, but I currently do not have the privilege (as locale leader) to delete a revision... Well, I hope Verdi and Topal show up. Thanks :)
(In reply to Simone Lando from comment #5) > For me it would be Ok, but I currently do not have the privilege (as locale > leader) to delete a revision... You probably should! Per-locale permissions is something on our radar so you should have it soon I hope :)
The thing specced out in bug 685578 was about sending comments to editors who's revisions were used in a subsequent revision. The source of this later revision could have been an unreviewed revision or a deferred revision. There can also be unreviewed revisions and deferred revisions in the history that were not used as the source of a later revision. What we do currently is send comments to all of the previous unreviewed or deferred revision editors whether or not they were actually used as the basis of the newly approved revision. What I think Simone is asking is that we exclude sending messages to editors of unreviewed and deferred revisions that were not used as the source of the revision being approved. If so, I agree. I think (just a guess) the problem may be that we can't distinguish exactly what revision(s) were used as the source of the revision being approved. Locale leaders should be able to delete revisions (spam, etc.). If not, it should just be a permission assignment problem that Rosana can fix.
thanks, Michael, it's exactly like this.
Not taking away from Ricky, but I'm pretty sure we can't tell which revision a revision is based on. That leaves the issue of locale leaders not being able to delete a revision. That's bug 720226
You need to log in before you can comment on or make changes to this bug.