[Osr-101] Re: [Yulup] Re: Implementing a very simplified workflow

[Michael Wechner]

Josias Thöny wrote:

> Michael Wechner wrote:
>
>> Josias Thöny wrote:
>>
>>> Andreas Wuest wrote:
>>
>>
>>
>> <snip/>
>>
>>>
>>> Couldn't we say that only the newest revision could be published?
>>> It would simplify things and make workflow independent from 
>>> versioning in the protocol.
>>> Do you think this would significantly impair the flexibility?
>>
>>
>>
>> I think people want to (re-)publish old versions, because new 
>> versions might not be so good
>> and I am afraid this is quite often the case (shit happens ;-)
>
>
> Yes, but in most cases people would probably edit the old version 
> before re-publishing it, so a new version would be created anyway.


I guess so too, but there is also quite often the case that one 
discovers an error on the published page and just wants to re-publish a 
previous version.

>
>>
>> Of course one could use "Revert To  OLD_VERSION" in order to make an 
>> older version the current version and allow
>> publishing the most recent version, but this kind of destroys the 
>> history.
>
>
> I wouldn't say it's destroying the history, it's just creating a new 
> version which is equal to an old version.


agreed, "destroy" might a bit a too strong word, but I would still say 
it's kind of "misleading"

>
>
>> So I think if a CMS supports versions, then the Neutron protocol 
>> should allow publishing every version.
>
>
> I don't see any fundamental problems with this approach, I just have 
> the feeling that it's a bit complicated...
>
> For example, if an old version is submitted to review, the reviewer 
> has to be informed about which version he has to review. Otherwise he 
> will assume having to review the newest version.


very good point. We definitely need to emphasize this somehow

>
> But I also found something positive, imagine the following situation:
> When a page is live, it still can be edited (which will create a new 
> version), and this version may be published without manually 
> deactivating the old live version. So a live page can be re-published 
> if it has been modified.
> The question is how this works with the two different workflow 
> concepts (global vs. version based):


I think this is especially useful for Wikis

>
> - With the global workflow this is not easy to solve. It requires 
> either two different live states, or storing an additional variable 
> (is_live, as it's done in lenya)
>
> - With the version-based workflow it shouldn't be a problem. 
> Publishing just has to automatically deactivate the other live version.


In the case of Yanel I think one could implement this by creating a node 
property "live-version" and then update this property when a specific 
version is being published

>
> So that would be a real advantage of the version-based workflow.
>
> Another point is delete/restore, which one might also consider as 
> workflow operations. There could be a state "TRASH" with transitions 
> "delete" and "restore". Now this doesn't make much sense if it works 
> on individual versions.
> But maybe delete/restore does not have to be implemented into the 
> workflow.
>
> Any comments on these points?


expire/delete would be probably rather on a "global" level

>
> Furthermore I found some minor issues in the spec:
> (see http://neutron.wyona.org/amendments/versions.html)
>
> - maybe the "from" attribute of a transition is not necessary, since 
> only transitions which apply to the current state are listed.


agreed

>
> - should "status" be renamed to "state"? maybe a native English 
> speaking person could comment on this.


please see my other email

>
> - it mentions the date format has to be iso-8601, but the workflow 
> example actually uses a different format.


need to fix that. Thanks for pointing this out.

Cheers

Michi

>
>
> josias
>
>>
>> If a CMS doesn't support versions, then only this "recent version" 
>> can be published.
>>
>> Make sense?
>>
>> Cheers
>>
>> Michi
>>
>>>
>>> Josias
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Yulup mailing list
>>> Yulup at wyona.org
>>> http://wyona.com/cgi-bin/mailman/listinfo/yulup
>>>
>>
>>
>
>
> _______________________________________________
> Yulup mailing list
> Yulup at wyona.org
> http://wyona.com/cgi-bin/mailman/listinfo/yulup
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner at wyona.com                        michi at apache.org
+41 44 272 91 61