versioning policy

I'm trying to implement a default versioning policy as follows:

  1. On initial document creation - set the version to 1.0
  2. Thereafter - increment the minor version number (1.1, 1.2, …)

I have tried various combinations of:

...
<policy id="test" increment="MINOR" order="11">
    <initialState major="1" minor="0" />
</policy>
...

I've tried before/after, multiple policies, etc. Looking at the Framework code - it looks like what I'm trying to do isn't supported because of how the policies are applied before and after. I'm therefore planning to implement this with a filter class but it seemed better - if possible - to do it just with a contribution. If I'm missing something, guidance is appreciated. Thanks.

0 votes

1 answers

131 views

ANSWER



Hi Eric,

Your example looks good and should work to initialize the versioning state to 1.0 and then increment by minor after every update (if and only if document has dirty properties). What does not work in your case ?

0 votes



Thank you. After initial document creation the version is always "1.1". Here's what I see:

AbstractSession.createDocument
  getVersioningService().doPostCreate
    StandardVersioningService.setInitialVersion
        ... version gets set to 1.0 here
  getVersioningService().doAutomaticVersioning
    if (currentDocument.isCheckedOut()) {
       currentDocument.checkIn(...);
       ... version gets incremented here

In other words the call to session.createDocument always invokes both the initial state code path, and the version increment code path. The only way the version increment code path would not be executed is if the document is checked in at that point but - that's inside the framework. Scanning through the unit tests in GitHub for the text "<initialState" - I don't see any unit tests with a contribution specifying both initial state and increment and so it seems like this isn't how the feature was intended to be used… I've experimented with some other configurations for the contribution but so far no luck…

07/25/2018

Hi,

This is the expected engine behavior with your contribution. Initial state and your rule is well taken into account: 1.0 as initial state then a versioning after, so 1.1. Note that initial state of 1.0 isn't backup by a version. In this case, you have your live document and a 1.1 version (representing document state at creation).

If you want to disable the first versioning on creation, you can achieve that by adding a filter to your policy, contributions will look like this:

  &lt;extension target=&quot;org.nuxeo.ecm.core.versioning.VersioningService&quot; point=&quot;policies&quot;&gt;
    &lt;policy id=&quot;test&quot; increment=&quot;MINOR&quot; order=&quot;11&quot;&gt;
      &lt;filter-id&gt;disable-on-creation&lt;/filter-id&gt;
    &lt;/policy&gt;
  &lt;/extension&gt;

  &lt;extension target=&quot;org.nuxeo.ecm.core.versioning.VersioningService&quot; point=&quot;filters&quot;&gt;
    &lt;filter id=&quot;disable-on-creation&quot;&gt;
      &lt;condition&gt;#{previousDocument != null}&lt;/condition&gt; &lt;!-- filter won&apos;t match on document creation, policy will be discarded --&gt;
    &lt;/filter&gt;
  &lt;/extension&gt;

With these, you won't have any version representing document state just after creation. First version will be document after the first update.

Does it fit you need ?

07/26/2018

I see. Thank you for responding. This gives me what I need. Thanks.
07/27/2018