Document History

[Gersbacher]

Is there a customer solution for automatic created document history? Otherwise, how do other companies handle modification of work item in documents?

Desired functionality:

- Each change of a work item shall be committed by the user
- Automatically create a list of changed work items including the reason of change

Reason: After document is released for the first time, there are modifications required in a document for a new software release. Therefore work items of type "Change Request" are created. The work items in the document are modified, new items are created or removed. The reviewer shall now only check the modifications in the document and shall allocate each change to original request.

The important functionality we required: The author of the document shall be forced to commit the change.

Note: Polarion tracked following user demand "DEMAND-1450 : Option to manually input commit comments without relying on Polarion's function"

[NickEntin]

Hi,

while Polarion doesn't allow you to comment save operation in documents, you may create a baseline each time, you made a significant change of the document, this will appear in the document history with different color and name could be used as the comment.

Option 2 will be that you set-up a workflow for the items in the documents - e.g. all your released items are in state "published". The items are read-only in this state. Whenever you want to modify any item you'll put it in state "draft". When you're ready with modifications, you want to put them back into "published" state (and consequentially make them read-only), and transition draft->published requires a comment or approval for the item.

Best regards,
Nick

[martins]

Hello,

we also had some discussions with Polarion about this topic:

All modifications in released documents should be commited to a changerequest (similar to changes in the source code).
We like to have a traceability between changes in Documents and the changerequests that caused the change.

Up to now we haven't found a satisfying solution.
Because this is currently not possible in Polarion we are not able to use the Polarion Documents as intended.
We are still forced to document our design in Word or Excel documents and commit them to our source code repository.
In this way we can assure that all modifications to a document are linked to a changerequest (checked by a SVN hook script).

@Nick: Your suggestions don't solve the problem. IMHO documentation needs to be treated in the same way as software, which means:

• It must be possible that multiple developers work on the same source file / document and commit their changes to a concurrent version control system (like SVN).
• It's not acceptable to "unlock" and "lock" a piece of documentation every time you want to change it (as you suggested). For Software this isn't accepted neither.
• Every time a developer commits a set of changes in source files he's forced to enter a reasonable log message, including an ID for a valid change request. Same procedure is required for changes in documents!

Kind regards

Martin

[Salmolin]

Hello

Is there any news about this topic?

Thanks and regards

[jriimala]

Hi,

My solution for adding change history (semi automatic..) to document is to have customized fields for change description, release and version. These are filled by author of the document via document properties. Naturally via document workflow document status is also updated as document is progressing.

Currently can read revisions with date and author and update those to table. Don't know how to read document revision specific details like change, release and version and status field values (can read current revision details, but not from all document revisions). Working example would be appreciated, also anything what can accelerate my progress within this ex how to read revision document custom fields in general. Naturally end of the day don't want all revisions listed to table, as only those matter which version number has been increased and change field has been updated. By having all then document would be quite large


Best Regards, Jouni