Hi (this is a summary of my postings/ideas from the tread: https://help.wrike.com/hc/en-us/community/posts/360000758169-Update-description-via-API)
We have an automation in mind which takes values from custom fields and builds a part of the description based on it. This is currently done with WebHooks immediately after the edit of the custom field. Very nice from the user experience as long as the user first edits the custom fields and then the description. If the user edits the description first and then the custom fields all the user changes got lost!
Your support college explained the reason for me with Wrike using a live editing database and slower/delayed updated backend database.
This makes our kind of update impossible as long as we cannot synchronize our API update, lock the record (and enforce a refresh of the backend database) to allow an update of the consistent data or find the point in time were no user has modified it long enough that the API sees all the changes of the user. The updates should happen as soon as possible and not only overnight.
So our hope and suggestion for your developers is to provide and API for description changes only. If I assume that changes of descriptions are very likely possible in just a few seconds it would be absolutely enough to have something like such:
- GetAndLockDescription(ElementID, AutoreleaseSeconds)
- PutAndUnlockDescription(ElementID, Description)
During the lock-phase
- User are blocked from further editing
- The returned description from the Get call is up to date and contains all user data
- Our program code has a certain time for its operations until the system automatically unlocks the record
- As soon as the processing is done a Put call can update the description and immediately release the lock
After AutoreleaseSeconds is reached or the explicit use of the Put function
- The Lock is released independent of a missing Put call (this avoids any locked elements where processing is too slow or even buggy)
- Any further call to the Put function results in an error (like it would if no Get was used at all)
- User are able to go on with changes on the description
As I wrote above the average changes is just very small as parts of it can be prepared outside prior to the locking phase. So the remaining processing time is more or less just the calls, transfers and update of the description.
The use case I outlined is just one of potential. I could also imagine to have information from other systems which should be visualized within descriptions and which would currently result in destroying user input done in parallel. The trust of users to such a system will potentially be low or even get lost. So we are limited in actually doing such.
It could also help if there is an API which allows a kind of "search (with regex) and replace" or "append text at the end/before the start of the existing description". Both would need to do the changes with the real content.
Currently API is just good for reading information out of the description but not really for writing to it.