Is it possible to lock/unlock requirements via the REST API in DNG?
Is it possible to lock a requirement, or set of requirements (given their IDs or itemIds) in Doors NG 5.0.x via the REST/OSLC API?
The client wishes to lock a set of requirements (within the traceability tree) before generating a RPE report. They want to lock these requirements to ensure that no changes are made to the requirement hierarchy while the report is being generated.
Thanks,
Sudheer
The client wishes to lock a set of requirements (within the traceability tree) before generating a RPE report. They want to lock these requirements to ensure that no changes are made to the requirement hierarchy while the report is being generated.
Thanks,
Sudheer
2 answers
While it is possible to do it while HTTP calls, I doubt that the API is published. And strictly speaking, such calls are not OSLC since OSLC RM 2.0 specification says nothing about "locks". The RM reportable REST API does not address locks either.
Comments
Hi Donald,
How can I find the HTTP calls to lock/unlock requirements?
Alternatively, is there another way to ensure that requirements are not modified while executing a report, or at the very least being able to flag them (e.g. by reporting on suspicion status for the requirement)?
Regards,
Sudheer
It's HTTP calls, so if you do some HTTP tracing, you will find it out. As for "locking requirements for reports", I think we are looking at the feature of reports based on baselines, but I cannot recall whether such feature exists.
There is no public API for locking and unlocking resources.
If you want to be sure that the data did not change while you are generating a report then reporting on baselined data is probably the way forward. Alternatively you could always read the etag for each resource (available on a GET of the resource via the public API) and compare that before and after the report is generated
If you want to be sure that the data did not change while you are generating a report then reporting on baselined data is probably the way forward. Alternatively you could always read the etag for each resource (available on a GET of the resource via the public API) and compare that before and after the report is generated