Submitted by : simon at: 2005-09-09T18:04:25+00:00 (15 years ago)
Name :
Category : Severity : Status :
Optional subject :  
Optional comment :

property change --simon, Fri, 09 Sep 2005 18:04:43 -0700 reply

Name: '#1157 after reverting changes, last edited time is not restart' => '#1157 after reverting changes, last edited time is not reset'

was unsure, but is on my list now! --betabug, Fri, 02 Mar 2007 11:26:15 +0000 reply

After Frank had submitted the same thing in a dupe ([#1293 revert "last edited date" handling]?) I was unsure what the desired behaviour should be. Now that I see that simon submitted the same Issue, I take it as a sign that the consensus is to revert the "last edited time" too. Shouldn't be too hard, so hopefully we'll have it in the next release (not 0.59).

patch is in darcs now --betabug, Tue, 13 Mar 2007 20:11:51 +0000 reply

Status: open => closed

just a oneliner...

update --simon, Sat, 07 Apr 2007 18:51:08 +0000 reply

See also #1293 and #1324. We just did some code review on #zwiki and I've clarified the revert docstring as follows:

Revert to the state of the specified revision.

Copies a bunch of attributes from the old page object, and even
renames and reparents if needed.  Very useful for cleaning spam.
We do this corrective edit instead of a simple ZODB undo because:
it is more reliable (no failures due to transaction dependencies),
it reverts page renames and reparents, it sends a mailout, and it
records the reverter as last editor.  Note we currently do restore
the last edit time from the earlier revision, though. This may
seem a bit counterintuitive, but it's a practical measure so that
you don't end up losing a lot of useful last edit time info from
spam incidents (cf issues #1157, #1293, #1324).

So the current behaviour is what's intended, better ideas welcome. Discussion:

(11:13:38) sm: it seems with #1157 after reverting changes, last edited time is not reset, I was expecting revert to restore the old last edit time

(11:14:11) sm: since then I enhanced revert, and decided it was more useful to save the new last editor (== the reverter) and last edit time, to know what's really going on (11:14:29) sm: and I could have closed 1157 (11:15:32) sm: but I didn't.. then frank reported #1293 revert "last edited date" handling, not knowing the intended behaviour (11:15:33) betabug: well, that's why I asked a couple of times before fixing 1157 (11:15:43) betabug: I wasn't sure what was the intended behaviour (11:17:01) sm: and I didn't hear/understand the discussion on 1293 (11:17:25) sm: and #1324 Revert doesn't reset username is more of the same misunderstanding (11:17:56) sm: and, meanwhile you changed the behaviour for 1157 (11:17:58) sm: I get it (11:18:30) sm: so now that my intention for revert is clear - do you agree ? (11:18:30) betabug: you were pretty busy at the time (11:18:42) betabug: and both oppinions on what should happen have their points (11:19:31) betabug: frank doesn't want a trace of the spammers, you'd prefer to know something had happened (11:19:56) sm: yes (11:20:15) sm: you can still remove the traces by doing a ZMI history undo (11:20:24) sm: zwiki revert is more like a corrective edit (11:20:55) sm: [though it]? does allow a spammer to mess up the last edit dates of a bunch of pages (11:21:12) betabug: so spam reverts should use zope history undo really? (11:21:25) sm: I don't think so.. they did, before (11:21:37) sm: and there were problems with that (11:21:52) sm: you didn't get a mailout when spam was reverted, for one (11:22:30) sm: also, it wasn't reliable (11:22:45) sm: and, you couldn't revert a rename (11:23:11) ***betabug can imagine (11:23:23) betabug: now, how do we solve this dilemma? (11:23:23) sm: not reliable = sometimes a zope history revert fails due to conflicts or whatever (11:28:03) sm: so right now, last edit time is preserved across a spam/revert incident, but last editor isn't (11:28:31) sm: which is good for preserving issue times but a bit counter intuitive (11:37:05) sm: betabug: but maybe it's a practical compromise ?

new proposal --simon, Sat, 07 Apr 2007 19:08:36 +0000 reply

Ok, how about this instead: revert will revert both last editor and last edit time, the mailout (if any) will appear to be "from" the reverter, and the log note will say "reverted by (reverter)".

This means that a spam+revert incident won't show up in recent changes; the only way to know it happened is if you watch mailouts, or if you browse the diffs of an affected page and see "reverted by". A spam incident that hasn't been reverted will still show up in recent changes of course.

This seems probably best, but I'll hold off a couple of days for more discussion.

... --simon, Sat, 07 Apr 2007 19:13:08 +0000 reply

Severity: normal => minor Status: closed => open

update --EmmaLaurijssens, Sun, 08 Apr 2007 10:33:59 +0000 reply

> betabug: frank doesn't want a trace of the spammers, you'd prefer to know something had happened

No, I think we agree on this one. It was just that after reverting the first spam wave, I noticed that my name was shown as last editor. As Simon explained, to me this was quite counterintuitive.

If this is desired behaviour, you may be able to talk me into believing this is the best solution ;)

new proposal --simon, Fri, 27 Apr 2007 01:08:12 +0000 reply

I've tried this (restoring last editor and last edit time) with the new history implementation (#47 permanent revisions and better history/diff browsing), and it seems weird, I think because there are two cases:

  1. Normal editing - user makes a mistake, or finds an earlier version is better, so reverts that version. We want to record this edit in the page history, so we save a new page revision, last editor, edit time etc.
  2. Spam repair - spammer hits many pages. Users revert each spam edit one by one, or (better) manager reverts all the spam edits en masse. We don't want all this mess in the page history, so we do not record a page revision, instead we should remove page revisions created by the spammer. Last editors & last edit times will be as they were before the spam.

new proposal --simon, Fri, 27 Apr 2007 01:25:30 +0000 reply

So we could have:

And perhaps these should have more distinct names.

It's arguable whether removing history entirely is a good idea. For example, notes that MW lets you set a flag to avoid disturbing recent changes, but all events remain recorded in the page history. I think we don't want spammer/vandal content and urls left cluttering up our edit history and being indexed by search engines, though.

new proposal --EmmaLaurijssens, Fri, 27 Apr 2007 07:58:57 +0000 reply

> urls left cluttering up our edit history and being indexed by search engines, though.

The latter is the issue here. I think your proposal is what I'd like to see, no revisions disappear without manage access, and even then only in special cases.

... --simon, Fri, 04 May 2007 13:19:51 -0700 reply

Name: '#1157 after reverting changes, last edited time is not reset' => '#1157 sensible history and last edit time handling with revert'

Renaming this.

The last discussion calls for the ability to expunge junk edits from history. The current revert implementation (in the diffform, or the revertEditsEverywhereBy method) does not do this. Can those be removed manually from the revisions folder when necessary ?

removable history --simon, Fri, 04 May 2007 19:54:03 -0700 reply

They could not.. I am rewriting the revision handling to allow this.

done --simon, Mon, 07 May 2007 23:45:51 -0700 reply

Status: open => closed

revertEditsBy and revertEditsEverywhereBy have been replaced with history-wiping expunge, expungeEditsBy, expungeEditsEverywhereBy methods. These require manage properties permission.