Hi there!
Over the years there often have been requests to make Drupal more wiki like. Numerous filters have been written and discarded to create wiki-style link possibilities.
A second important feature of wikis is there treatment of revisions. Drupal's revision system just got a major overhaul and is now more suited for wiki like usage. There is however some confusion about how we should treat access to the revisions. I've written a patch (http://drupal.org/node/30098 , read the whole issue) and would like to get some feedback on it.
To test the patch you need to have a working installation of Drupal CVS and you should be able to patch a file. Apply the last patch from the mentioned issue to node.module and look at both the permissions page and create revisions for a few of your nodes.
On the user permissions page, you will find two sets of new permissions: "view revisions for node_type" and "revert revisions for node_type". Grant those permissions as you see fit. and navigate to the revisions page of your nodes as a user with all or a part of those permissions. Do you think the revisions screen is helpfull and working according to your expectations?
Please give feedback! Add feedback specific to the implementation to the mentioned issue and more general comments as comments to this forum topic.
If there is demand I can upload a prepatched node.module file.
Comments
prepatched node.module file
I'd be glad to test it, but I don't know how patch works. So the file would be great or at least the command line instruction for patching the file :)
I've uploaded a patches
I've uploaded a patches node.module file to the issue.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Thanks!
Will try it tomorrow/tomorrow night and post back.
revision permissions
Just tried your latest patched module (node_2.module) with a fresh install of cvs as of today. It looks like I have to give users administer node permissions before they can then use the individual edit and revert permissions. This seems weird since it looked like from the discussion on the issue listed above that that might not be the case.
Also, one thing I'm not sure I like is the way set active works. It would make more sense to me that set active would create a new version, dated with the date of activation, to clearly preserve the flow of the document's construction and versioning. This is the behavior when an older version is edited; a new copy is created. I can see the thinking that there has been no changes to the document over the old version. But when we think of the document as the sum of it's drafts, there is a change of state which I believe should be preserved. Is there any reason not to?
Last, I think there would be usabilty advantages in having the access control descriptions match the actual action in revisions.
Thanks a lot for testing
Thanks a lot for testing this!
That should not be the case. Can you give me an example where the view and revert permissions fail?
Before the revisions patch "revert" would actually create a new revision. Somebody didn't like it and I changed it to the current system. Not sure which is better.
Also, you cannot direct edit old revisions, only the current one.
Don't get this, can you elaborate?
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Just downloaded the patch and new cvs
and am just getting started on testing it -- the one thing I noticed is that in the "access control" page, it offers the ability to set permissions for
$typeinstead of the specific content types available on the site -- it's a small, cosmetic thing, and now I'll get down to testing functionality.This screenshot shows what I'm talking about more clearly.
-------
http://www.funnymonkey.com
Tools for Teachers
-------
http://www.funnymonkey.com
That probably explains why
That probably explains why Charlie says the permsions don't work. Will upload a fix later.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
saw the same.
Yes. I'm seeing the same thing. I just figured that was just a display element you hadn't gotten to yet :)
one more thing
I'll hold off on trying it again until you load a fix.
Is fixed. -- Drupal
Is fixed.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
reversions
"That should not be the case. Can you give me an example where the view and revert permissions fail?"
I'll give it a test in a little while and get back :)
"Before the revisions patch "revert" would actually create a new revision. Somebody didn't like it and I changed it to the current system. Not sure which is better."
Say I have four drafts of a community-authored doc already. We revert back to draft 2 under the current system. That is in effect draft 5. But once we do an edit and save, the system will no longer indicate the state change. It'll be unclear that draft 2 was also the fifth draft in the sequence of the way that the draft progressed. I'm curious what the arguments to the contrary are.
"Also, you cannot direct edit old revisions, only the current one."
Ahhh...I see what you mean. However, when viewing the previous version, an admin does get an edit tab even though it brings up the current version for editing. Perhaps this should be disabled when viewing an older version?
As far as matching the access controls with the action in revision,
"view revisions for $type" works well since it matches the regular Drupal terminology in the revision listing. However, "revert" for the access control and "set active" for the action in the revision listing might cause slight confusion. Perhaps revert for both or set active for both (I like revert if we have real reversions :)
Revert = new revision
I also think that revert should create a new revision instead of magically setting a previous revision as the "active" revision.
For one thing, this is how every wiki I've seen works. It's what most wiki users will expect.
Also, as cel4145 points out, the sequence of revisions makes a lot more sense this way. Consider this sequence:
1) Revert to a previous version
2) Make some changes
3) Diff those latest changes
If reverting doesn't create a new revision, how will diffing work? What will the latest version be diffed against? One of these must happen:
a) The diff results are meaningless, because the latest revision is diffed against a completely unrelated version, or
b) For each revision, Drupal must keep track of which revision it was based on, e.g. "the current revision is version 7, which is an edit based on version 3".
(a) is unacceptable, and (b) seems like adding a whole new level of complexity. It seems simpler and better to follow standard wiki practice so that reverting to a previous version creates a new revision that duplicates that old version.
Ok, I've reintroduced the
Ok, I've reintroduced the "new revision on revert" policy.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services