Lossless Description Changes via API to Boost Possible Automation Options

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.

 

Kind regards,

Andy

28
10件のコメント
Spot On Innovative Approach Stellar Advice
Avatar

Thank you for sharing your thoughts on Wrike's API, Andreas Wastl! I'll pass your feedback to the Product team. 

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

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Lisa and Lisa K.!

I want to draw your attention to the fact that collecting likes for fixing a serious problem is not entirely fair! 
It is not an improvement. It is a bug and unexpected behavior.
Maybe most of your customers don't use this feature, but it's broken now.
I think you have to exclude it or add some attention tip to the documentation description.

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Alexander Salamatov, thank you for reaching out! 

This is how it's intended to work currently and isn't considered a bug for that reason. We are passing your feedback to our Developers portal team, so thank you for flagging this! 

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

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Lisa!

This is how it's intended to work currently and isn't considered a bug for that reason. 

Who expects this behavior? Developers?
Wherein the API description does it say that if I call the `Modify Tasks' method with the description parameter, I will lose the changes made by users on the UI?

So many emotions, sorry, but we have pain within three years and cannot do anything with it.

1
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Lisa,

I think Alexander and I are among the ones to really like to build up business processes with the API. And we struggle with this. Alexander for 3 years and I for about 1/2. But it stops us also to bring cool ideas to live. If you are telling it is expected behavior. Can you help us to understand for what scenarios the intended behavior is planned to be usable for?

1
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Alexander Salamatov, Andreas Wastl, I'm sorry for the late reply here!

Our current API logic doesn't support simultaneous editing within UI and via API - Lisa K. explained this in this thread as well. At the moment as a workaround, it's possible to schedule time slots for editing via API or make sure to edit the custom fields first and the description afterward when the API updates have synchronized.

We have passed on your feedback to our developers. Your suggestions are great and the ability to use both API and UI to edit tasks would make a handy addition to our features, so our developers will surely take it into consideration. 
 

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

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Lisa, thank you for getting back to us!

Could you explain this workaround a little more? I've updated a custom field by API but the description still outdated.

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Thank you Lisa for driving this forward as you did. We are also have increased likes, so I really think there is a need for API enhancements. As I assume that the API users are way less in this community compared to an average (Admin-)UI-only user this is an incredible achievement. Maybe you guys can take this into account. I hope we will get an improvement this year.

@Anybody who reads this thread and find our ideas helpful, please give us a like so we can reach the necessary threshold to get recognized better and a chance to compete against directly visible end user UI enhancements. 

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

I'm sorry for the late reply here Alexander Salamatov! The workaround can help with the use case that Andreas Wastl described in the post 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!".

So as a workaround, it should be possible to schedule time slots for editing via API or make sure to edit the custom fields first and the description afterward when the API updates have synchronized. 

As I mentioned earlier, the feedback on this thread is passed on to the developers. Thank you again for letting us know your thoughts! 

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

0
コメントアクション Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Lisa,

I just recognize that my reply to your posting was obviously not saved. For whatever reason. 😕

So let me do another one right now. The suggestion to synchronize API updates with user activities is hard to achieve if we would expect a world wide user community. Spare time for one time zone is peak working time for others. Assuming only EU and US it might be possible put taking Asia into account as well it becomes impossible. There is no such slots. We would tell everybody not to do changes at a certain time which will - for one timezone most likely "in the middle of the day" or at least within the business day. I doubt someone would remember not to update a description between 10-11 am, or 2-3 PM or whatever other slot it would be. 

I only see a technical solution as a solution. All other rely on human nature and are candidates to fail. And as we all now Murphy, the situation where entered information is lost might be on a point in time which is critical. So not something we can design a reliable process based on it.

0
コメントアクション Permalink

Folllowing List for Post: Lossless Description Changes via API to Boost Possible Automation Options
[this list is visible for admins and agents only]

トップ
Didn’t find what you were looking for? Write new post