Trigger/rule for "Versioning"-like own numbering scheme

[nxpet]

Dear all,

today we are using the versioning feature of Integrity, but we only need a version number for our document AND for our content. There is no further need of other versioning features (like traces to versioned items etc.). So for us it would be better to simply work on the live item and add an own version numbering scheme to our items.

The numbering scheme should be "[major].[minor]", like it is used for versioning.

For content (Requirement) the minor-number should be increment by 1 for EACH significant edit. The major-number should be increment (+minor to zero) when the state of the content changes from state "A" to state "B".

The version number for document we would simply add manual as baseline/label.

From my understanding I would need:

- field "My Minor" (integer)

- field "My Major" (integer)

- computed field "My Revision" (shorttext) that joins the fields to "[My Major].[My Minor"]

- 1 trigger that increments "My Minor" + rule that detects significant edits on item type "Requirement"

- 1 trigger that increments "My Major" and sets "My Minor" to zero + rule that detect change of state "A" to "B" on item type "Requirement"

Unfortunately I am not familiar with triggers. Can you help me on that? And how do I detect a "significant edit" since the last increment of the Major.Minor number?

Thanks, Timo

[nxpet]

I took a look at existing trigger scripts and trigger java documentation. The most important part about incrementing I found out by myself already. Trigger scripts for incrementing the minor:

var delta = bsf.lookupBean("imIssueDeltaBean");
minor = parseInt(delta.getOldFieldValue("My Minor"))+1;
delta.setFieldValue("My Minor",minor);

And setting minor to zero is then easy by:

delta.setFieldValue("My Minor",0);

The "My Revision" field computation is: Concat(ToText("My Major"),Text("."),ToText("My Minor"))

For the trigger script I used a rule "Text != Text[New Value]". Adding the other significant edit fields like this would work, although I hope there is a better possiblity to check for significant edits. Especially taking into account, that significant edit field might change in the future and I might forget to change the trigger rule 😉

[awalsh]

I think what you are doing for the rule is the best option. 

Another option is to fire the trigger for every edit to content or document, and check if there is a significant edit using the IssueDeltaBean.isEditSignificant() method.

I've tried comparing the Significant Edit Date and Input Revision Date fields but the rules always show them being the same and don't fire the trigger. 

[nxpet]

Ok, thanks... I think then I will just list all significant changes in the rule. Anyway I am also not 100% happy with the definition of significant edits in Integrity, e.g. the Attachments of a requirement are also significant edits, even if they are not listed in the "Significant Edit Fields" in the Admin Gui. We are using the Attachments just for adding optional background informations and not as main part of the requirement. When I define the rule by myself, I can exclude the Attachments, such that no new revision number is generated.

[awalsh]

If you use a new attachment field rather than the default Attachments field, then adding/removing files from this field will not be a significant edit.

For some reason (I'd say a defect) the default Attachments field is always a significant edit regardless of whether it is in the list of  "Significant Edit Fields".