reopen closed content without creating a new version

[Clemens Robbenhaar]

Kit asked in the "request for approval" issue
if one could change the implementeation of reopening
content objects without creating a new version.

Actually this should be a simple fix,
but I have not resolved this within the issue and
will not manage to do it this week, thus I put
a separate issue here for it may not be forgotten.

prio "wish", as I guess its not important for
the end user, just annoying ...

[Martijn Faassen (faassen)]

What's the status on this one? I think there have been some
UI changes that might actually do something like this
by now. If so I'd like to close the issue. Clemens, Kit?

[Kit Blake (kitblake)]

This is working in the head, and the shortcut code is in
tab_status_approve.py

I notice it contributes to version bloat by creating a
duplicate copy of the closed content.

Setting to resolved,

[Clemens Robbenhaar (crobbenhaar)]

kit blake writes:
 > I notice it contributes to version bloat by creating a
 > duplicate copy of the closed content.

 ... and this is all the issue has been about: reopen a closed
content should _not_ create the new version, but it still does.

 this has been a featurelet left unimplemented from the
request-for-approval changes. if it is assumed to be too unimportant
I will go and resolve this again ...

[Kit Blake (kitblake)]

It works, very nice. Clemens, could you do the same for the Status screen
(VersionedContent tab_status) tab_status_approve? Thanks.

[Clemens Robbenhaar (crobbenhaar)]

Hi Kit:
 > It works, very nice. Clemens, could you do the same for the Status screen
 > (VersionedContent tab_status) tab_status_approve? Thanks.

 Huh, I did not relalized I have changed something ;-)
I will see what I can do anyway. have to solve some problem with my cvs
before doing so ...

[Clemens Robbenhaar (crobbenhaar)]

Ah, now I understand Kit's mail: he has fixed this for the content status tab,
and this needs to be migrated to the containers tab.
 I will do so now.

[Clemens Robbenhaar (crobbenhaar)]

Er, I cannot really reproduce the "reopen closed version" feature;
if I try to do this, I get an error message:

  " There is no unapproved version to approve. "

and the content stays closed.

Actually I feel this feature would have needed an additional method
in the "Versioning.py" which I cannot find so far. I guess implementing
this looks like an involved issue, if I look at the very involved
looking code of this class ...

[Martijn Faassen (faassen)]

What's the status on this one? Should I defer this one to Silva 0.9.3, or
can't I as it sounds like parts of this is already implemented in some
screens (but then Clemens says it doesn't work, so I don't really understand
what's going on here :).

[Jan-Wijbrand Kolman (jw-infrae)]

Maybe I can make this issue a bit more clear:

Use-case: There's a closed version of a document, and the editor want to reopen
it for editing or approval. He wants to do so, without having to create a new
version of this document first.

Currently it is not possible to change the 'closed' status of a version.
However, a while ago (actually, a long time ago), I implemented this request by
shortcutting the workflow in the approval python scripts used by the publish
tabs (the "tab_status" for Containers): when approval is requested for a closed
version, a new version is created and approved in one go.

Kit thought that this was new behaviour, done by Clemens.

This behaviour is not implemented in the Status screen ("tab_status" for single
VersionContent objects) though, which is what Kit asked Clemens to do in msg2487
- and where the confusion began ;)

I did work on this siutation, and it needs testing. I asked Kit to test this,
since I think he's knows best what should do what and how.

[Kit Blake (kitblake)]

It half works. Meaning, it is possible to publish closed content in
one click, but - underwater - the workflow still makes a needless
new version. So for the Editors it works, for the sysadmins it
doesn't. Deferring to 093.

[Martijn Faassen (faassen)]

I'm confused -- the workflow *should* make a new version if closed
content is being re-opened. Anything else is far less traceable and
more confusing.

[Kit Blake (kitblake)]

Content gets closed and re-published - without any editing - all the time (just
copy a folder with published documents and paste). Why do we automatically make
a new version? (So we can do a diff ;) This contributes to the Version Bloat.

For traceablility of such actions - ummm, how can I trace that? :)

[Martijn Faassen (faassen)]

Content does not get published at all when pasted; it gets closed.
This moves the version along in the workflow from published->closed.

Currently the workflow functions in a way that whenever a new
version is published, this is a new copy. There are no exceptions;
new published versions are always new copies.

What is proposed here seems to be the following.

   closed -> editable

Presumably authors can also do this.

This should definitely cause the creation of a new version. It should
not reuse the closed version, as this is part of the history, which
would otherwise be torn apart.

Right now traceability is at least there in primitive form for Silva managers;
you can go to the management screen of a folder and see the older versions.
We are planning to expose this in a UI in the future. If a closed version
can suddenly be revived *without copying* the history would be affected,
as you would either take something away from publication history (bad) or be able
to change history (worse).

The right thing to do is to create a new version. The way sysadmins are
helped is a script that periodically removes old versions, as listed
in other issues.

A situation that could be helped is actually the copying and paste case --
perhaps Kit means this. In the copy & paste situation, we might actually
only create objects with an editable version only, starting on a clean slate,
instead of the current case where we copy all older versions.

We also seem to be talking about another case:

   closed -> published (if no other published version already there)

this would in fact be possible iwthout screwing up the history too
much. You could see this as content that was 'temporarily' closed
and then republished. But anything that goes through the approval
stage again should create a new copy, as authors may 'unapprove' content.

[Kit Blake (kitblake)]

> We also seem to be talking about another case:
> closed -> published (if no other published version already there)

This is the case I was talking about. If content is temporarily closed, going:
  published -> closed -> published
then we're simplifying the process (there's no need to create new editable
versions that don't get edited, but immediately approved/published) and thus
we're not unecessarily contributing to version bloat.

[Guido Wesdorp (guido-infrae)]

So if I understand it correctly the following issues are discussed here:

1. Version Bloat - if some object is closed and re-opened later on, a new
version is created. This can be annoying, but seems to be the most logical
behaviour and the problem in this matter is not so much that a new version gets
created, but that there's no way to manage old versions. This issue is discussed
in 355 and should currently be fixed.

2. Closed -> public (or closed -> approved) should not create a new version - it
seems JW has already implemented this but it's gone again now. JW, can you find
out why it is gone and reimplement it/switch it back on? Perhaps you can also
take a look at implementing it in tab_status for single docs.

[Martijn Faassen (faassen)]

This ends with a question for JW. JW, could you look into this? By all means
move to 0.9.4 if desired, I think.

[Jan-Wijbrand Kolman (jw-infrae)]

This issue is utterly confusing. I think what we can do is:

  "A closed version can be re-published, if there's no other
   approved or public version. And if the user is an Editor."

I made a new issue for the "Copy & paste copies all version objects too" problem
(issue670).

[Martijn Faassen (faassen)]

Deferring this issue then, doesn't seem to be release critical.

[Martijn Faassen (faassen)]

passing on to 0.9.4

[Andy Altepeter (aaltepet)]

This is actually implemented now that there is version management in the status tab.