Revisioning takes over all "Edit" in all content

Hi charos,

"It would be great if Revisioning could be applied to selected Content Types and not take over other functions."

This is definitely the intent of the Revisioning module. When you go to Content management>>Content types and click the edit link and then on the next page Workflow setting, you can switch OFF the creation of new revisions for that content type by unticking the bottom options and ticking "Published". This way there will always be a single copy (no matter how often you save it) and it will never go into moderation.

The Revisioning module will still intercept the "Edit" function (it has to in order to get permissions and grants to work in an orderly fashion). But what we could do perhaps, is saving the user a couple of clicks by directing them straight to the Edit page (the one you get when Revisioning is uninstalled) to let the user edit the current (i.e. latest) revision (i..e they won't be given the choice to pick a revision).
In particular, when there's only a single revision, then the intermediate step of selecting a revision is a bit superfluous!
Is this what you're after?

Agreed. Should not hi-jack the edit links by default.
But it would be practical to be able to force it to do that on a per-content-type basis, though.

Further on this:
- in several cases it would be practical to be able to enforce revisions being made (many reasons for this, just to secure content from user mistakes, so we can find back older versions easily and be sure not to loose anything), but still exclude certain content types from taking par t of moderation... That is; enforce saving revisions for content type c and e, leaving them out of moderation workflow, but still have revision control on content type a,b and d WITH moderation...

I think this suggest a per-content-type setting that specifies if this module should bring the actual content type into moderation workflow or not. This needs to be flexible, like a tick mark that appears in the content type settings when the revision tick mark is checked, letting us specify how it should be have.

Then, if a content type is set to enforce revisions, but if that content type is NOT set to take part of moderation by this module (the "appearing tick mark" mentioned above), then this module will leave it as if no revision was made or as if this module was not enabled, actually. For other content types that is set to use this module, this module will then take charge of those posts both whenever new revisions is made, and also on content types that is set to NOT enforce/suggest new revisions, but when a user is actually choosing to make a revision anyway manually, then this module comes into play there as well...

I think this is achievable by two tick marks in the contenty type settings page.

I realise I might have to re-write this explanation, not very well formulated, but no time now, posting it and waiting for response...

Hi Daniel,
I may not understand you correctly, but as I was trying to explain in #1, I think Revisioning already does what you and charos request.
The two tick-boxes that can be checked on a per content type basis exist and can be found under Content Management>>Content types>>Workflow settings. They're called Create new revision and New revisions (to go) in moderation.

As far as the hi-jacking by Revisioning goes... I believe this will have to remain (in some form), but as explained above, we can make it so that the hi-jacking behaviour is virtually indistinguishable from the original behaviour when the above tick-boxes aren't checked.

.... or am I missing something?
Rik

Hm, I have gotten a bit ahead of myself here, as I am actually just browsing the issue queue to make up my mind whether it seems mature enough and interesting enough to start testing this module... So I have not even installed it yet. Sorry about those too-specific comments if I wasted anyone's time.

Clearly requiring a look at the module before becoming this specific. I took perhaps too much for granted related to the information in the original post, and totally forgot that I havent had a look at it yet, heh.
Will give this a try and report back here.

"we can make it so that the hi-jacking behaviour is virtually indistinguishable from the original behaviour when the above tick-boxes aren't checked."

I agree with this statement.

Subscribing.

"As far as the hi-jacking by Revisioning goes... I believe this will have to remain (in some form), but as explained above, we can make it so that the hi-jacking behaviour is virtually indistinguishable from the original behaviour when the above tick-boxes aren't checked."

My problem is that I continue to see "Unpublish this revision" links on nodes whose content types still have "Create new revision" and "New revisions (to go) in moderation" disabled. This has the affect of letting users who do not have proper edit permissions for certain content types still be able to click the "unpublish" link on those nodes, which (for my application) is just as undesirable as users editing the node content when they are not supposed to.

Also, I have the content access module installed, and I have explicitly used it to uncheck any edit privileges on content types not requiring moderation. Furthermore, I've given the content access module higher priority (-10) on those content types that should not be in moderation, yet still users without relevant edit permissions can see "Unpublish this revision" links on nodes of these content types, and they can click on the links and unpublish the nodes.

It really seems to be a problem that the "unpublish revisions" permission given by the Revisioning module supersedes any other node access permissions.

Unless I'm doing something wrong.

Hi westbywest,
You have a point!
I have some new ideas to improve this area.
Will get back.
Rik

subscribing

Subscribing - it would be great if Revisioning made itself invisible for content types where it is not used.

First cut to alleviate this is available in development snapshot(s) of 11-Jun-09 or later.
Please don't forget to also upgrade Module Grants and to visit Site building>>Modules to activate the changes.

I just upgraded to the 11-Jun-09 dev versions of both modules. For some reason, my test user has the ability to unpublish the current revision even though none of my roles are assigned that permission in the system.

Oh, nevermind. User error. I was using user 1.

I would also like to use Revisioning only on select content types, which was requested in the original post. I just installed the latest dev version 6x-2x for the first time, and am finding this to not be an option. Am I missing something? This was somewhat of a deal breaker for me to forgo using Revisioning. I think it has the potential for what I want though.

Hi brasath,
Have you followed the instruction in comment #1?
What's the specific issue you have?
Rik

The problem with #1 in my case, is that I want to have revisions (the original method not revisioning) in other content types and this doesn't seem to be an option. Revisioning still takes control of the revisioning of ALL content, from what I remember when I had this module installed. Correct? I also want users to be able to start a content type unpublished, also not using revisioning.

Agreeing with #17.

So brisath and Daniel,
You're saying that what is described in #4 doesn't work for you in the latest official release (or development snapshots)?

From what I remember when I had revisioning installed, what I relayed in #17 was the case and #4 did not have any information that resolved the issue. I can't double check this now since I do not have the time to re-install revisioning. It would have to be something I examine in a few months when I may want to try using it again. Hopefully the issue is not a problem for me then.

subscribe, I confirm all this.

Even if we have "create revisions" button uncheck for a content type, Revisions still appear on nodes.

If authenticated users have pemission to see revisions, they will see revisions on all the pages of the entire website.

I can comfirm #21

Ok, guys... I had another shot at trying to reproduce this using the Jan 2010 releases of Module Grants (6.x-3.2) and Revisioning (6.x-3.1), but couldn't.

Maybe the latest duo of releases fixed the issue, or I am still misunderstanding you.
This issue goes straight to the core of what Revisioning is about, so let me elaborate one more time on what should (and I believe does) happen:

The situation:
We have two content-types, let's use Page and Story as concrete examples. We're happy for revisions to be created for both types but want Revisioning to apply to Pages only, not to Stories.

To set this up, as an admin, for each of these two content-types we go to Content Management>>Content types>> edit >> Workflow settings. We tick Create new revision for both, but tick New revision in draft, pending moderation only for Page.
We typically untick Published, but you don't have to.

For each of the two types we now go Create content.
On the same page, if you're an admin, you can tick or untick Published and save.
Edit and save a few more times to create some revisions for each of the two nodes.

No log out as admin and log in as a user with the 'access content', 'view permissions', 'publish revisions' and 'unpubish current revision' permissions, but not the 'administer nodes' permission.
Navigate to node/1234/revisions (where 1234 is the node number), i.e. the "Revisions" tab.
The above user, who has the 'unpublish current revision' permission will now:
* NOT see the 'Unpublish current revision' link for a Story and
* see the 'Unpublish current revision' link for a Page (provided it's currently published)

Similarly when this user then clicks on a revision (its modification date), the publish/unpublish links will NOT be visible for content of type Story, but they will be for a Page.

Naturally, when you untick Create new revision after you have created revisions, existing revisions will remain visible under the node/1234/revisions tab. However any subsequent saves will not create any additional revisions.

Do we agree this is how it should work?
If you don't consider the issue fixed, please re-open with a clear description of where this isn't working for you.

re-opening.

sorry @RdeBoer you are completely missing the point of this.

revisioning should be enabled for specific node types, if not enabled, it should do NOTHING on that type. Not sure why this is not obvious what is meant in initial post as it is std way that most Drupal node modules work.

enabling this module should by default do nothing. it certainly should not remove ALL Edit tabs in the entire site.

Revisioning should then simply have an "enable Revisioning" checkbox (that's it) under the Workflow section for each content type. Then, if this is enabled, and user goes back to edit this node type, it would have the options that are supported by this module. Some modules have a more complex (in code, but less complex from a UI perspective) UI where checking/unchecking that initial checkbox; shows/hides the other options - but don't this is required.

the theory in code then is that before doing anything like removing edit tab, adding other tabs, blocking access, etc.. you first check node type against list of types that revisioning is enabled for.

i might look at doing a patch for this if anyone is still interested; but likely will check out other similar modules first. this one seems to fit the bill pretty well; but unusable as it is now. 40 different node types and only 2 need revisioning applied; even if i could get edit tab back (which i don't think solution in #23 will do); dont really want to go through all the types that just got broken by this module to fix.

so basically this: http://screencast.com/t/I0XcjdGAgg when disabled
and this: http://screencast.com/t/QIu8N58RUxb when enabled

and then in your access/page callback's simply test if enabled before doing anything - i tried this very quickly but your menu_alter is a bit odd i think as even though i force a return of TRUE for your callback for node/%node/edit is seems to be ignored. would need to go through it in more detail.

@liquidcms:
Thanks for your critique.
For now I'm just confirming that I've seen this and that I will reply more elaborately soon.
Can I just double-check we're talking D6 here, not D7?
Rik

yes, D6. thanks.

i have now looked at a couple other similar modules and so far not much that seems as close as yours. i have one more to look at "Save as draft" (i think) but have recommended to my client that they get me to "fix" this one as it seems the best out of the bunch. i could submit a patch for what i have so far; which is simply the changes above to the node type edit form.

as i said, i looked briefly at the menu alters that would need to be changed but they didnt make too much sense at first glance, plus i think a few other places in your code where a "if (not enabled content type) ignore" line would need to be added.

if you have an idea of what would be involved in supporting this, i would certainly prefer to pay you to do it than do it myself.. :)

@liquidcms, #25
I believe you are overstating the symptoms and the issue.
It is certainly not Revisioning's intent to "remove ALL Edit tabs in the entire site". Can you please show us reproduceable test case for this?

As for the lecture re "Enable Revisioning" box, thanks for the screenshots. Effectively Revisioning has that checkbox, but it's called "New revision in draft, pending moderation". This sets a flag associated with the content type that is then checked in various places in the code so that only the enabled content types are affected. That's the intent anyway and I'll admit that the D7 version of Revisioning does a better job at it then D6.

I'm happy to have a look at tightening this up for D6, especially if you're willing to donate.

Rik

With end-of-life approaching for D6, I don't think much will happen in this area.