[RTC] Is it possible to exclusively control work item updates by REST API(OSLC)?
Accepted answer
As far as I can tell,
- There is no locking mechanism.
- Regardless of how you implement it, REST or JAVA API, there are only limited options. You can detect a possible conflict e.g. based on the error when saving. In case there is an error, determine if this could be a stale data error. In case it is, refresh/reload the work item redo the modification and try to save again.
- A problem will be detected when saving - note that the Web UI has the same limitations, if a user works on a work item and another user saves this item while they do, there will be a save conflict.
- The Web UI check every now and then and shows a banner that says the work item has been changed - I don't know how that is implemented. I think it is irrelevant for automation, because the likely hood of a save conflict happening should be minimal and it would be possible to reload the item and retry.
- There is no other wonder API I am aware of.
Comments
Thanks Ralph.
However, I do not understand well.
What is “only limited options”?
Are there any articles I can learn?
- I have listed all the options I know about above. I might be missing something, but I don't think so.
- OSLC is a public specification you can search for other opinions: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oslc-core
- I am not aware of anything specific. The Eclipse Lyo provides samples also for RTC: https://github.com/OSLC/lyo-samples
- My experience is here: https://rsjazz.wordpress.com/
Summary, if you run into a racing condition, the tool detects the fact (based on some header information, I think [etag?]) and lets you know. Reread the work item, do the change again and try writing it again.
ETag!!
I understood a little.
Thank you very much.
Acquire that ETag is not changed after the session information and confirm that it matches.
I don't want to lock it if I imagine it would be impossible to unlock.
Let's consider a mechanism to check for updates even a little by checking with ETag.
I learned a lot.
One other answer
Comments
That is no lock, that is a pre-condition that prevents saving a work item under certain conditions.
Thanks Wark!!
But,this is for the control to close the WI, and is a good match for the process that prevents overwriting exclusively.
Thanks Ralph ,follow!!
Exactly,This is a conflict issue.
Can Java API detect conflicts?
I would like to do it with REST API, is it impossible?
As far as I can tell, there is no locking mechanism. Regardless of how you implement it, REST or JAVA API, there are only limited options. You can detect a possible conflict e.g. based on the error. In case there is an error, determine if this could be a stale data error. In case it is, refresh/reload the work item redo the modification and try to save again.
limited options?
Is there a “conflict check” API?
or get "modified Date" and diff?