Update description via API

Hi Alexander! Would you mind elaborating a bit, what do you mean by 'partial editing'?

Hi, Pavel

The only way to edit a description through the api is to paste it fully, but if I edited(Regex, Replace, etc) only a portion of the text, the history(Updated description link) will display that I changed the entire text(screenshot above). May be possible to make it display only the diff between the old description and which I put.

Hi Alexander! Thank you for the clarification. I am afraid that this is how description editing is designed, as it's not 'live' as it would happen when you type into it symbol by symbol, but a mass-update via API which in fact re-writes the content as a whole. Would be a good consideration for our product improvement in the field of API though, thank you!

Hi there,
Indeed, the problem was quite serious for our workflow, so it turns out that update the description via API at the time of editing by users. There is no way to understand that a task is being edited and to understand that we are losing data. 😕

Hi there,

We struggle the same way. 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. 

I am happy to discuss any alternatives.

Alexander Salamatov, do you find a good solution for your situation?

Hi, Andreas Wastl

We are still suffering. Our team members keep this pain in mind and use task history to get a lost text 😥.

I think this is a HUGE problem. We have two options (UI and API) to update a task description but can't use them simultaneously.

It sounds good to ask clients to save descriptions and freeze for a second while API does some updating stuff.

Pavel M, please come back. There are no workarounds with this unexpected behavior.

Thanks. Sad to hear you still do not have a solution either. 😟

Hey Andreas Wastl and Alexander Salamatov, thanks a lot for reaching out! I'm now raising Support tickets for you so that our advanced support agents can advise. 

You'll get a notification soon! 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

Hi Lisa,

I actually wrote (see above): 

[...] Your support college explained the reason for me with Wrike using a live editing database and slower/delayed updated backend database. [...]

So I am not sure if your support will have a solution for me. I did not mention that it was advanced support. He also pointed me to this discussion thread... 

Thanks for getting back to me, Andreas Wastl! I was hoping that our advanced support would be able to advise here. 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

Hi there!

Any update about it? 

Some emotion about this bug in our team:

Hi @Alexander Salamatov,

I'm sorry to hear that this is causing difficulty for you. I'll be happy to elaborate on the current functionality we have in place.

Any updates made in the description field are initially cached in the Wrike Live Editor database. They are saved at the backend only after the user stops editing the description in the UI (after 1-2 minutes of no new changes made). In turn, Wrike's API gives access to the backend database only. Therefore, the latest version of the description is expected to be returned with a delay that normally should not exceed ~3 minutes after a user stops editing the description in the UI. With this being said, this time interval may fluctuate depending on the system load. It's important to bear this in mind when using the live editing functionality to prevent any data loss in the future.

Having said that, could you please elaborate on your use-case so that I could suggest any method to minimize the impact of what you're experiencing or pass your feedback to our Product team?

• Am I right in understanding that you'd like several users to edit the description at the same time?
• Could you please share the example of the requests you're using with me and advise on how much time passes between editing description in the UI?

Awaiting your reply!

Hi @...! Thank you for your reply.

Am I right in understanding that you'd like several users to edit the description at the same time?

Several users can edit descriptions well at the same time. But API gets it unsafe if someone edits the description at the moment.

Could you please share the example of the requests you're using with me and advise on how much time passes between editing description in the UI?

1. User editing a task and API update description at the same time. Whoops, the text gets lost. Users have to restore description from the history log, also we losing API corrections...
2. User edited task and go away. One minute later, API updates the description. Nobody knows that we have a problem till return to the task and get terrified.

Please, just reread this thread, messages explain the problem great.
I understand the root of the matter and I understand why this is happening, but there is no way to fix except stop using API to update a description of tasks.
At least you can lock updating through API during Wrike Live Editor database continues doing stuff and throw some exception, then I can retry update through API later.
And once again, this is a HUGE and hidden problem if you using API to update description. We have no chance to control it and do something on the client-side.

I fully agree and support Alexander. It is the non-obvious loss of data a user experience if an API is working with the description values too. Some processes should run as early as possible and not just over night. See my example mentioned above:

"[...]. 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!"

I also like to repeat my idea of having some kind of (self-release) locking for some seconds to ensure API can update the real content for a modification. The short delay of user keystrokes may not even be recognizable at all. At least not disturbing I would imagine.

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.

Hi Alexander Salamatov and Andreas Wastl

Thank you for the detailed feedback.

I understand your concerns and I can see how the lock feature could be of great help for users who would like to use both the UI and API for updating tasks. The idea of API requests that could append text at the end/before the start of the existing description also sounds really interesting!

These features will most certainly require significant research and development. I am passing your feedback to our Product team now. They are always really excited to hear suggestions on how we can improve our platform, so thank you for sharing your insights and feedback here. 

If possible, could you post your request in our Product Feedback forum? Here, users will be able to vote on your suggestions and once this post reaches 60+ upvotes we'll be able to add a status here. 

If you need help with anything else, be sure to let us know.

So I did: https://help.wrike.com/hc/en-us/community/posts/360051304574-Lossless-Description-Changes-via-API-to-Boost-Possible-Automation-Options

• For tasks: https://developers.wrike.com/api/v4/tasks/ (methods GET and PUT)
• For folders and projects: https://developers.wrike.com/api/v4/folders-projects/ (method GET)

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

Hi, Lisa!

Great news, at first glance, this is what we need!
We're urgently updating our work with descriptions in our services to delight the team!

Thanks a lot for sharing!

It works like magic.
But some unexpected behavior occurs:
Two same requests returns different result
GET https://www.wrike.com/api/v4/tasks/IEAAG7C2KQLINEWO

..."description": "<a href=\"https://www.wrike.com/\">Wrike</a><br />",...

GET https://www.wrike.com/api/v4/tasks/IEAAG7C2KQLINEWO?latestDescription

..."description": "<a href=\"https&#x3a;&#x2f;&#x2f;www&#x2e;wrike&#x2e;com&#x2f;\" target=\"_blank\" rel=\"nofollow noreferrer noopener\" data-auto-wrap=\"true\">Wrike</a><br />"...

As you can see second one is unescaped html string and contains some additional attributes for link that doesn't exist in first one. 
Please take a look at this. Thank you.

Hi Alexander Salamatov, thanks for flagging, our developers are already looking into it! 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover