Vincent, Christophe: I think I've got a better idea of what he's asking, because (if indeed I do understand it) it's an issue I've faced before. Many modifications of a document may pass before a review approves one revision as an official "version". Just as individual commits do not make a release of a source tree, individual edits to a document are not approved as official versions, but instead are packaged into a release with an independent namespace. So I think you've got it right from one point of view, but I'd approach the problem differently: The XWiki versioning records what it should record, which is "what changed the last time the document was edited; who did it; when they did it". That information is important, and it should certainly be kept. The versioning that Christophe needs says "what changed *since the last approved version*; who approved *this version*; when they *approved* it; plus an explanation of the reasons for, and/or a characterization of, the changes". In summary, XWiki's versioning records the results of individual *edits*; Christophe's need is a record of *approved versions*. They are similar in nature, but not identical; the real discriminant here is that they the result from different actions: changing the document versus sealing the final result of all changes since the last version and giving it an incremented version number. Thus, my approach would not require changing XWiki's internals at all, but instead, adding objects to your versioned pages. For those permitted to "validate" (I'm guessing that this refers to the act of reviewing and approving) a document, the view template could include a form that populated an object of a new class (I'll call mine VersionApprovalClass) which will contain all of the information about the validated version. The information that can be gained from the document itself, such as the last author and date, will not be in the object itself but inferred from the document's current XWiki version available as $doc.version. Also, if the date of the approval is required (as distinct from the timestamp of the approved XWiki version), it should be included as well. That may not be strictly necessary, since the addition of the object also revs the document, but I don't think it's a straightforward process to find which revision of a document added an object. Of all this information, only the comments field (and possibly the "official" version number, depending on how it is determined) need to be entered by the user. Thus, when a validator reviews a document, [s]he will be view a completed document version, then, if appropriate, will enter a version comment (and the new version number if it's not automatically determined) and submit the form. To find an validated version of a document, a link could be added to the view template to display document history, in a similar fashion to the XWiki history template, but instead of listing the document's own history you would list the validated versions, displaying document information and offering diffs only among the specific versions that were validated. To see how to add objects to a document, look at the comments.vm templates; to create a new XWiki class, use the document XWiki.XWikiClasses. brain[sic]

-----Original Message----- From: Vincent Massol [mailto:[email protected]] Sent: Tuesday, April 03, 2007 12:08 PM To: [email protected] Subject: Re: [xwiki-users] [Proposal] A system to manually manage the state of the wiki page (version, redactor, comment, validation, ...)

Hi Christophe,

Does your email means you're proposing to implement this? (I'm referring to the "Proposal" in the subject line)

Also you did not describe how to implement what you suggest. Could you be more specific?

If I understand your email, you're suggesting to decouple document state from document storage. For example, document's content could still be managed using XWikiHibernateStorage but document's states could be managed by, say some custom tool. Hmm.... I'm not entirely convinced. I think it'll raise several issues, one of which is distributed transactions. Another one is performances.

To implement your use case you could also intercept document save using the XWiki Notification Service and save your own document state as you want it.

Not sure exactly what you're looking for with your email...

Thanks -Vincent

On Apr 3, 2007, at 6:42 PM, Christophe Koehl wrote:

...

Hello the xwiki community,

We use Xwiki for a couple of years now as a tool for managing our IT projects. During the redaction of the main project documents, we have a strong need of versionning management - not the xwiki system, but our own one. To be clear, when a wiki page is written some information can be included in it : * Document version * Name of the redactor * Date of the modification * Name of validator * Comment

In fact, the xwiki system contains almost all the components, but those information are updated each time a modification is being done, even when the document is a draft and has not be validated. For example, the xwiki version number is automatically incremented whereas the real document version number is still the same.

So it can very very useful to integrate a system which can be able to manage manually the different state of the document.

Regards

Christophe Koehl

From - Mon .org/wws