Hi there

I have a featured request for the D7 version.

For using revisioning as a ISO system the documents needs to be kept a certain way.
Most of the way revisioning is working takes care of this however I have one request.

When a node gets old and the content no longer needs to be updated the ISO way would be to simply archive the document. This way you still keep track of the old nodes, the history but you also prevent the users for simply use them since normal user don't see them as published.

So a request for some type or archive function/status would be very good.

It means that in stead of publishing a new version you archive it, hence also the current published version get archived (different status).

Best regards

Mathias

Comments

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi Mathias,
Thanks for your suggestion.
I'm trying to understand what you are after.... What is the difference between what you purpose and the already available unpublish function?
Rik

soulis77-SE’s picture

soulis77-SE commented

Hello Rik,

Sorry for the delay in reply but I will try and explain it some more.
A ISO document needs to be handled a certain way to fullfill the requirements.

One of them is that content that no longer is used can't be deleted it has to be archived/stored.
Also the archived content shouldn't be easily accessed for normal users so that they could use the instruction.
- To put it simple content that is archived needs to still be around but hidden from normal users/visitors, only accessible by moderators.

I don't want to display the archived content for normal users and for that I can use status=1 as a rule for the views.

But when I tested the unpublish feature the content went back to draft/unpublished state (status=0).
This meant that with the "Pending revisions" block the content went back to required an action.
However when archiving a content there should be no more actions. If a moderator for any reason want to modify an archived content then he/she needs to put it back in draft.

So with a view for every author where their content in draft (status=0) gives them a place to go for handling their work in process. But the way it is now they also should have seen their 10-50 archived content as work in process.

So my request is a function that places the content in status=2 to separat archived from unpublished/draft.

joevansteen’s picture

joevansteen commented

I would think this would have ramifications well beyond just Revisioning. I like the idea of being able to keep 'out-of-date' archived documents in the database, rather than simply deleting them, which is what I believe is being requested here. However, wouldn't that also mean that all other processes would need to recognize the state of the material as 'archived' and that there are nodes in the database, but for these items there is no truly 'current' nodes, only archived historical nodes.

Views, for one, would be important to ensure that it was capable of supporting such a concept. Don't show the node when showing current content, but show the node to selected parties when doing a time-bound or an audit request.

There could even be some special roles for revisioning and workflow in the process of 'archiving' content. Selecting content for revision where the target of the revision was to 'delete/archive' the content rather than change it, and then have a moderator/editor or an automated scheduler approve the archival action.

Seems like something worthwhile, but probably needs some careful thought about how to accomplish and probably some coordination with core.

Edit: After writing this, I got to thinking about how I would do this (archiving) without this feature. It struck me that with my current approach of using Taxonomy Access, I could easily expand my access vocabulary to include new 'xxxx-archive' terms and accomplish the ISO archive by re-classifying the taxonomy term on old items rather than deleting them. Mathias, you might want to look into something along those lines. And, I would think that the taxonomy term update would be a 'revisioned' event, so there could be moderation using the current Revisioning system as part of the process.

scott.whittaker’s picture

scott.whittaker commented

Correct me if I'm wrong, but using the Revisioning module there are three different states that the revision Status may assume:

* published
* in draft/pending publication
* archived

You can use Views to filter based on these states, so you can create a list of content which only lists content that is set to "in draft/pending publication" as the basis of a moderation queue.

The problem is that if you unpublish a node it's state gets set to "in draft/pending publication" and there is no option to set it to the "archived" state. If you could do that then you could have unpublished content that is not flagged for moderation, which I believe is what soulis77-SE wants. While he seems to be asking for an archived node to remain published, I think that was only because his moderation view filters out published nodes rather than by revisioning status.

There seems to be no action for setting this state, and I suspect that perhaps the three states are really just two states (published and unpublished) where a revision older than the published revision is "archived" and newer than the published revision is "in draft/pending publication". But if there really are 3 distinct states then this issue might be solvable.

I've been working on similar functionality myself and eventually gave up and used the Flag module to set a flag for moderation state.

joevansteen’s picture

joevansteen commented

Scott,
My understanding is that published/unpublished is based on the 'status' attribute of the node table. The documentation for that field says "Boolean indicating whether the node is published (visible to non-administrators)."

That was the reason for my initial comment in #3 above: "this would have ramifications well beyond just Revisioning."

"Archived," I believe is an interpretation more than a state. See comments in module revisioning_api.inc near the top of the module:

* Pending:
 *   - revision with (vid > current_vid) of ANY node
 *     OR single revision of UNPUBLISHED node
 * Current, published:
 *   - revision with (vid == current_vid) of PUBLISHED node
 * Archived:
 *   - all other revisions, i.e.
 *     revision with (vid < current_vid) of ANY node
 *     OR revision with (vid == current_vid) of UNPUBLISHED node
 *
 * Note: these will change when Revisioning is going to store revision states
 * independently from vid number (e.g. in different table).

If revisioning were modified to use it's own "state" variable, this become easy and a solution such as I recommended for my own purposes using TAC become unnecessary. As long as it relies on 'status' there are issues in doing this, or so I think.

rdeboer’s picture

rdeboer
Location Melbourne
commented
Status: Active » Closed (won't fix)

Hi all,
Sorry for coming in late. Looks like everything there is to say on on this topic has already been said. Yes, in Revisioning "archived" is a pseudo-state. A real state would be better, either by introducing a new data base column or by abusing the node "status" field, which core currently uses only for published/not-published.
Due to limit time I currently don't have plans to take this much further.
If anyone wants to offer a patch, I'm happy to accept it.
See also #757110: Save real status (archived / pending) in database, instead of "guessing" it from current revision

Suggest to go down scott.whittaker's path (#4):
"I've been working on similar functionality myself and eventually gave up and used the Flag module to set a flag for moderation state."

Rik