Feature Proposal: Improved UI for copying topic content incl meta into new revision

Or: how to fight spamming with ease.

Motivation

With edit settings and forms the old view raw -> copy -> edit new -> paste -> save is not adequate.

MeredithLesly reported Bugs:Item1966 with this text

I finally got around to asking how to revert a topic, having felt like I must be missing something obvious. What I was told (in irc) was that you view the previous version, copy and paste, then save. If true, this is not only a UI horror but insufficient to boot, since none of the meta-data will be reverted! It's obviously too late to deal with this for 4.0.2, but it should be addressed ASAP.

Her request was misunderstood as a request to revert like we have with cmd=delRev. But after a discussion on IRC it became clear that this was not really the issue.

When we look at TWiki Beijing and Cairo a topic consists of two parts (seen from the user - not as the data representation behind the scenes).

• Topic text
• Form fields

With Twiki 4 we now have 3 parts

• Topic text
• Form fields
• Settings

And when you look at a form with 10 fields that some has been goofed up by accident or simple regret reverting for the normal user now means these steps. we assume that the form data was altered as well. For example a twiki application (like our bugs web - I have similar application here at Motorola) that contains mainly info in form text area fields.

• View previous version
• Click raw view
• Copy all text
• View current version
• Edit new version
• Paste the the old text into the new topic
• Save

A little difficult yes. But doable. You would think this is it but no it is not. That only copied the topic text. The form data is still the old values.

Here is the most efficient current method for doing the next steps.

• Open a new browser window.
• In the original browser window with the new version hit edit.
• Navigate to the previous version of the topic
• Copy first field of the form of the old topic version.
• Paste the into the first field of the form of the new topic version
• Copy 2nd field of the form of the old topic version.
• Paste the into the 2nd field of the form of the new topic version
• Copy 3rd field of the form of the old topic version.
• Paste the into the 3rd field of the form of the new topic version
• Copy 4tf field of the form of the old topic version.
• Paste the into the 4th field of the form of the new topic version
• Copy 5tf field of the form of the old topic version.
• Paste the into the 5th field of the form of the new topic version
• Copy 6tf field of the form of the old topic version.
• Paste the into the 6th field of the form of the new topic version
• Copy 7tf field of the form of the old topic version.
• Paste the into the 7th field of the form of the new topic version
• Copy 8tf field of the form of the old topic version.
• Paste the into the 8th field of the form of the new topic version
• Copy 9tf field of the form of the old topic version.
• Paste the into the 9th field of the form of the new topic version
• Copy 10tf field of the form of the old topic version.
• Paste the into the 10th field of the form of the new topic version
• Save the new topic

Are we done? Probably. But what if someone altered the settings of the topic?

How do I see what it was before? You cannot as a normal user. There is no user interface for viewing old settings. The real experts will learn to use ?raw=debug. Then you see the meta data. And from that you can - as a real expert - code something that looks like...

META:PREFERENCE{name="VIEW_TEMPLATE" title="VIEW_TEMPLATE" type="Local" value="UserView"}

back into a ' * Set SOMETHING = Somevalue.' in Edit Setting.

So Meredith has a valid point.

What we do not want!!

• Users cannot and should never be able to delete any revisions.
• Users cannot and should never be able to alter any revisions except the current version within the {ReplaceIfEditedAgainWithin}period.

So the feature that should be considered is a way that the normal user can create a new version of a topic which is a copy of a previous version.

And such a function should be an entry in the More Topic Actions.

Extra to consider

And once we have created such an entry - it could be made universal so that you can copy the contents from any revision of any topic to a new revision of the current topic. And the default topic name in the UI would be the current topic.

Extra Extra

And what if you have an ALLOWTOPICCHANGE in the settings? Then you copy that also!. The feature could have some fields to check for, copy form and copy settings. And if the two fields are not checked the form data and the settings from the current version of the topic are maintained unaltered in the new revision.

-- Contributors: KennethLavrsen, MeredithLesly

Specification

• Get the revision number
• Get the text and meta of that revision
• Go to edit screen
• User clicks save

Implementation

• In the More screen, add section "Restore topic"
• Clicking the "Restore" button will call Manage::manage with action parameter restoreRevision and additional parameter revision
• After checking access permissions, Manage calls edit with

     $session->{cgiQuery}->param(-name => 'action', -value => '');
     TWiki::UI::Edit::edit( $session );
  

• The rev parameter is passed to edit. Currently edit's call to readTopic ignores the revision. We just need to read the rev parameter and feed it to readTopic to get the text and meta from that revision.
  • Prevent ORIGINALREV to get defined because we do not want a merge in save.
• The rev also needs to be passed to readTopic in Save::buildNewTopic
• Edit template: we cannot be sure that the checkbox is in the template, so we need to force the revision in that case.
  • To that end we pass forcenewrevision from edit to preview: <input type="hidden" name="forcenewrevision" value="%URLPARAM{"forcenewrevision"}%" />
• Do the same for the preview template

-- ArthurClemens - 02 May 2007

Discussion

-- KennethLavrsen - 28 Mar 2006

That sounds like a sensibe enhancement. Can be done in the more screen, in a similar way to reparenting a topic:

• Go to more screen
• In "Restore previous revision" section:
  • Enter revision number to restore (previous rev is default)
  • Hit "Edit" to edit the topic with the content/meta-data of the selected rev number
• Make optional changes & hit "Save"

-- PeterThoeny - 28 Mar 2006

See also the wireframe in BetterMore:

-- ArthurClemens - 28 Mar 2006

I think Peter's proposal that a restore submissions leaves you with the new topic in edit mode. There are two reasons. First it gives the user an extra chance to regret now he sees the actual topic text. And 2nd it is probably the idea to modify somewhat the topic text after the restore. If not you just hit save.

-- KennethLavrsen - 29 Mar 2006

I'd like to point out that while it's technically a feature request, most wikis do have version revert. See wiki under wikipedia to see that the author there seems to think that it goes without saying.

-- MeredithLesly - 30 Mar 2006

Wikipedia would not work if rolling back would take too much time. Vandalism occurs on a daily basis there.

-- ArthurClemens - 30 Mar 2006

Another important enhancement that has fallen off the radar.

Also, note that even raw=debug doesn't work in all cases, because not all META content can be added directly; e.g. content that was added by a plugin.

-- MeredithLesly - 30 May 2006

There's subtle differences in terminology .. wonder what works the best ..

• "revert"
• "restore"
• "re-actualize"
• "make (current|master|head)"
• "bring to front"
• etc

(I know revert is already established SCM terminology).

Anyway, I think this kind of link should be directly accessible from diff views, as this is where the overview of revisions is best.

-- SteffenPoulsen - 06 Jun 2006

Whatever it's called, the label should be as non-geeky as possible. This is, after all, for admins (primarily, possible exclusively. Of the above choices, Restore sounds best to me.

And, yes, you're right. It needs to be done while viewing diffs or history, since otherwise how are the user supposed to know which version he wants restored?

-- MeredithLesly - 06 Jun 2006

Bounce. This came up again at Support.EasyWayToRevertTopics.

-- PeterThoeny - 05 Dec 2006

This was something that I first ran into using TWiki3, and after looking at the code, it seems like a moderate to simple task, as after checking for permissions, it would just be a getTopic( oldversion ) then a saveTopic with the old versions data (meta, text, etc.).

Not that I am volunteering, I was just really surprised that revert wasn't there. Just my two cents, but I would like the revert to be on at least 'More topic actions' page, similar to the above picture. Makes sense to have it on the diffs page as well.

-- EricHanson - 05 Dec 2006

The drawing was from BetterMore. We still do not have a proper solution for form/meta/preferences fields, unless these values are copied along with the restore action.

-- ArthurClemens - 05 Dec 2006

Another related useful enhancement: Add a "revert" or "bring to front" link to every revision in the rdiff screen, that results in the edit mode with that version's content. This allows admins to quickly revert vandalism; there is a confirmation step that reduces accidental actions.

-- PeterThoeny - 27 Mar 2007

Arthur added this to TWikiFeature04x02 but who is the driver. You cannot get a proposal accepted if there is noone committed to implement it.

-- KennethLavrsen - 08 Apr 2007

I am prepared to drive this. I might even give a try at implementing.

-- ArthurClemens - 22 Apr 2007

Cool. I am sure you will not meet any resistance to adding this feature.

Will you implement it like proposed above - and so that you end in edit mode with the reverted version and have to click save before the revert actually happens? I think that gives a good way to both

• check you got the right version before you hit the save button
• gives a chance to regret if what you clicked was not what you wanted to do.
• gives a chance to quickly update the topic before saving.

-- KennethLavrsen - 22 Apr 2007

Cool, thanks Arthur!

-- PeterThoeny - 24 Apr 2007

Implemented.

-- ArthurClemens - 03 May 2007

Great! I just tried it out, it works nicely.

Suggestion for better usability: In rdiff, add a restore link to every revision heading, except the top rev. Example:

The restore link could have a nice ballon help: "Restore will copy this revision to the top. You will be able to review the topic text before saving it to a new revision."

-- PeterThoeny - 08 May 2007

Is this on track for a particular release?

-- DrewStevenson - 22 Aug 2007

This - except for Peter's suggestion - will be in TWiki 4.2.

-- ArthurClemens - 22 Aug 2007

Some usability concerns: how about restoreRevision does not an edit but a save afterwards? A user might not want to edit the restored version. In the end he asked for a "restore", that is to go back to exactly the selected version. He will hit save in most cases probably.

-- MichaelDaum - 23 Aug 2007

Just saving would be my preference as well. I think that most times you just want to go to the previous version verbatim without any change. And an extra edit will be stored in the same revision anyway.

-- ArthurClemens - 23 Aug 2007

I'm for saving as well. I never edited a previous version before I finally restored it.

-- CarloSchulz - 23 Aug 2007

There is at least one good reason for keeping the flow as is - the user gets a chance to choose the status of the "Force new revision" flag before saving (i.e. allows him to keep the changes he did in HEAD-1).

There is something we might want to consider before release. This feature does not intelligently handle attached files to the topic or their metadata. That means if you are running an installation with

$TWiki::cfg{AutoAttachPubFiles} = 0;

(which is the default for a new installation), you will loose your pointers to files attached at a later revision than the one you are restoring from. Of course the same is true the other way around (if a file was deleted at a later revision than the one restored, there will be a pointer in the saved topic to a non-existing file).

So, what could we do about this?

• Ask/warn the user to set $TWiki::cfg{AutoAttachPubFiles} to 1 or he faces the consequences?
• Run the login that the setting would have done for 1 (one) and one save only?
• Ignore the problem for now? We do have a lot of topics with attached files at our place .. but we are also running with $TWiki::cfg{AutoAttachPubFiles} enabled.

I think I would prefer a warning, pointing to configure to let the user/admin enable the autoattach feature if disabled. But I'm happy to let anyone with a view on usability decide.

The autoattach feature handles both added and deleted files, just to clarify (has "autodelete" also).

-- SteffenPoulsen - 23 Aug 2007

Good point. Strictly speaking, restoring a previous version would mean to revert what happend in the meantime - including attachments. However undeleting attachments clearly goes beyond what twiki can do (easily). For that reason I'd propose to exclude attachment meta information from the restore process all together, that is keeping all attachment meta information as is and only restore text, topicinfo and formfield data.

On saving versus editing after restoring: I'd really expect the restore process to generate a new revision distinct from HEAD, that is always have an implicit "force new revision" during restore.

-- MichaelDaum - 24 Aug 2007

It does create a new revision.

-- ArthurClemens - 24 Aug 2007

I agree that TWiki should default to create a new revision by default (which is also the current default behaviour).

But it is definitely a possibility to uncheck the flag and have TWiki save into the revision you have been editing previously. This currently has the sideeffect that TOPICINFO is written as was, so even though the topic is saved as r1.8, %META:TOPICINFO% can say:

%M ETA:TOPICINFO{author="SteffenPoulsen" date="1187966563" format="1.1" reprev="1.5" version="1.5"}% 

Of course this does mean that version 8 will not accessible from the userinterface until the next save that bumps the revision happens (you won't be able to directly diff r1.7 and r1.8, only r1.5 and r1.4) - so this is not the recommended approach.

Leaving the "Force new revision" in place provides the optimal user experience, yet unchecking it is a possibility.

I like the idea of leaving the attachment metadata in place between revisions, not sure what effort is needed to implement this, though.

-- SteffenPoulsen - 24 Aug 2007

I also agree with the idea of leaving the attachment metadata in place between revisions. This would be best.

-- KeithHelfrich - 24 Aug 2007

In the Motivation section of this topic it is asserted:

"* Users cannot and should never be able to delete any revisions."

I can certainly understand this sentiment. However, we wish to introduce Twiki into a school environment where students may be allowed to make revisions to the content.

The school administrators would prefer that Twiki updates be sequestered until they are moderated. This seems technically not feasible.

If inappropriate content cannot be removed from the view of students, then we will probably not be allowed to give students permission to make updates.

We are talking about more than just "bad" language. Legal guidelines require that the privacy of students be protected. The inappropriate content could be as innocent as a student phone number.

-- DavidEgolf - 21 Jan 2008

David, What you need is complex.

The ISO plugin I wrote some time ago, does half this, in that it (by default) only shows the last authorised version of a topic.

BUT

What you are needing, is for some random number of people to make some random number of edits to a topic, and then at some later stage, a moderator comes along and merges them all.

That is difficult, and not a particulatly common need that significantly reduces the collaboration aspect of the wiki (thus suggesting that a wiki is not the right solution for your problem set).

If you are interested in persuing an implementation - please say so - It would certainly be an interesting experiment, but I think that while it is technically feasible, I don't think a non-collaborative collaboration tool would acheive much.

-- SvenDowideit - 23 Jan 2008

Sven,

Actually, even though it may be needed, I am not asking for a system which would require merging content. We have some team members that think that moderating updates to the wiki pages will be the only acceptable method. However, for the reasons you have stated regarding the complexity of the merges, I do not think that to be feasible.

I just want the moderator to be able to eliminate objectionable content when it was required by law. This hopefully should not occur too often.

In cases where privacy is the issue, discarding some intermediate updates may be the result and people would just have to live with it.

Your ISO plugin may meet our requirements. Do you think it might be possible to make the plugin effective on a group membership basis? EX: Teachers; i.e., administrators can see all versions, while students are restricted to use of the plugin and, therefore, see only the latest version.

That could be very useful.

Thank you,

-- DavidEgolf - 24 Jan 2008

The problem is editing will always happen on the latest revision. Thus you either only get one edit, and then wait til the moderator, or all editors would be able to see the latest unmoderated version when editing.

A Wiki is not like a forum, where you can hide changes from other posters... (even there, timleyness of information is more important)

I'd suggest that a Wiki or Forum that is moderated by delaying each post until its been OK'd is pretty much setting itself up for failure.

The more standard approach is that moderators 'eliminate objectionable content' when it actually happens, rather than setting themselves up as the doormen that are the limiting factor.

-- SvenDowideit - 24 Jan 2008

Sven,

Please notice from my previous posts that I am not suggesting that moderating a wiki makes sense. However, 'eliminating objectionable content' is currently not possible since all revisions are still visible in the history.

You mentioned that you had an ISO plugin which would limit visibility to the history. Is this plugin available? We could set it up so that the students would only see the latest revision so that once content is deleted it would be visible only to those with "history" capable skins; i.e. not students.

-- DavidEgolf - 04 Feb 2008

Isn't it possible to restrict view of history (rdiff) to admins?

-- ArthurClemens - 04 Feb 2008

ah, ok, David, thats a good point - there are a couple of approaches, including using rcs's commands to remove the revision from history altogether.

Arthur's suggestion is however the smiplest thing that could work Here on TWiki.org the rdiff script is restricted to logged in users - you could use apache authentication settings to further lock it down to just admins.

-- SvenDowideit - 05 Feb 2008