615566 - Rollback mechanism for articles

Status: RESOLVED WONTFIX

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

Description

[Kadir Topal [:atopal]]

In the history view the article marked as 'current' can't be deleted. It should be deletable, and the last approved article should become the current one. 

I'm sure there are implications that have to be handled, when this is implemented. I don't have the time right now to think too hard about it, but first things that come to mind:

* notification of localizers
* taking into consideration the level, minor, major, major2
* what if there are were unapproved revisions between the current and the last approved one?

Comment 1

[James Socol [:jsocol, :james]]

This is by design. Why is someone approving a revision that needs to be purged?

Comment 2

[Kadir Topal [:atopal]]

Is there a reason why we decided to do that by design? I can't remember any more. Actually there should always be a way to recover from mistakes, especially if they are only a click away.

Comment 3

[James Socol [:jsocol, :james]]

Because of all the considerations you listed in comment 0 and more. Deleting the current revision makes a much bigger mess than creating and approving another revision then deleting the one you shouldn't have approved.

Comment 4

[Kadir Topal [:atopal]]

Hmm, yeah, I think I remember the discussion we had about that. But it looks strange on the actual site, like we forgot to handle that case, and people will be confused. Maybe we could call it rollback and it would do what you just described automatically in the background?

Comment 5

[James Socol [:jsocol, :james]]

We could automate this:

* Create new revision identical to last approved (or any approved, really).
* Approve it. (The person doing this would be the reviewer of record.)
* ???

Where ??? is something from this set:
* delete the old one.
* mark the old one as unreviewed.
* mark the old one as rejected.
* nothing.

Of those for, I like "nothing," because then it's deletable if that's what you want to do, but we don't force it or have any unexpected and unrecoverable side effects.

Comment 6

[Kadir Topal [:atopal]]

Yeah, I'm also leaning towards nothing.

That leaves the issue of notifications, and here is where it get's really messy:

1. We need to decide what the level of the edit is, and what we will base the decision on. (probably the same level the to be rolled back revision had?)
2. Who should get a notification?
3. What happens to localized pages? What if the revision to be rolled back was a major change, putting localized pages out of date? How do we decide, whether to remove the note, or leave it there because an earlier revision had already marked the localization out of date?

Any thoughts?

Comment 7

[James Socol [:jsocol, :james]]

I'd tend to just use all the notifications we normally do for new revisions.

As for leaving articles out of date, that's based on the existence of a newer, approved, English revision of a certain severity. We could let the person rolling back update the severity of the new revision, but even if we don't here's roughly what happens:

History after rollback
rev 1 -- (translated to de:rev 1, for example)
rev 2 -- (no longer current)
rev 3 -- (== rev 1)

If someone then deletes rev 2, and rev 2 was a higher severity, there is now no article of higher severity, so de isn't marked out of date anymore. If it _isn't_ deleted, then de is marked out of date.

Comment 8

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

arbitrarily :-) closing this complicated bug that we'll never implement LOL