Handling updates

[ysavourel]

How does the workflow handles updates?

For example, can a source asset for a given task be modified when it is in progress? If so how is it indicated?
Or are updates forbidden after a task has started?

[Alino]

you can always update objects with REST api PUT methods. If the objects have children, it doesn't limit you in any way to be able to modify them.

[ysavourel]

Sorry, I probably not formulated the question properly.

Quite often we do get updated source files at the middle of a project. How do we handle this with TAPICC?

I guess the requester has to cancel the existing task associated with the previous version of the given asset and then create a new asset and a new task?

That leads to the question: How do you cancel a task?
You can do a PUT /asset/{parentid}/task/{id} to change the progress property, but setting it directly to canceled is probably not good enough: the backend has to act on such change and that may take time. Should we have a cancel-requested value?

This also makes me think we define the API backward: we define the commands but do not have really a clear description of the interactions those commands are supposed to allow. I know there are a few scenarios specified at https://docs.google.com/document/d/1VbMGH0G9W9gUBS3ZF351K09aKhLdnXYdXVtTxZrGAiE/edit# but they are very high level, while the interactions often require specific sequence of commands.

I can try to come up with some interactions.

[Alino]

I guess the requester has to cancel the existing task associated with the previous version of the given asset and then create a new asset and a new task?

That would be mine thinking as well.

That leads to the question: How do you cancel a task?
You can do a PUT /asset/{parentid}/task/{id} to change the progress property, but setting it directly to canceled is probably not good enough: the backend has to act on such change and that may take time. Should we have a cancel-requested value?

I am not understanding this part, where "setting the progress to "canceled" would not be good enough". The TAPICC backend can implement a hook which will get triggered each time a Task gets updated. In this hook, we can implement any necessary logic which needs to be executed.

I can try to come up with some interactions.

That would be awesome. 👍

[ysavourel]

I am not understanding this part, where "setting the progress to "canceled" would not be good enough". The TAPICC backend can implement a hook which will get triggered each time a Task gets updated. In this hook, we can implement any necessary logic which needs to be executed.

Let's say the customer (so the CMS side) wants to cancel one task. They send a PUT changing the progress for that task to 'canceled'. The TMS side (backend of the TAPICC server) can certainly act when it gets that request (no need for webhook). But cancelling a task if the task has started is a lot more than setting a flag to canceled: It needs to notify whomever is working on that task (e.g. a translator) to stop, change whatever TMS-side data associated with that task, etc. Only when the TMS task is truly canceled the field of the TAPICC 'progress' should be set to canceled. I guess I'm saying that the CMS-side (TAPICC client) should really request a task to be canceled by setting the progress to something like 'cancellation-requested', so the TAPICC server-side can take action and when it's done mark that task as actually canceled'.

[Alino]

I see your point now. But how would we define a Task which is truly 'canceled'?
Would that be if the Task assignee confirms that he has stopped working on it?

If yes, then
an alternative workflow could be for example when a Task progress is set from 'in progress' to 'canceled', this would trigger a webhook, so that the remote system can send a notification to the assignee, saying that the Task has been canceled, and he should not work on it anymore.

[ysavourel]

But how would we define a Task which is truly 'canceled'?
Would that be if the Task assignee confirms that he has stopped working on it?

It would be whenever the TMS system is done with whatever measures it needs to take to cancel the task are done. That may indeed be that the assignee has stopped working on it, but also other things like other status flags specific to the TMS have been changed.

The idea is that we don't know what the TMS system needs to do to cancel a task. Actually it may not be able to cancel it at all for some reason. So until it is actually done, the TAPICC task progress should only indicate that a cancellation has been requested.

[Alino]

ok, makes sense to me.
I am ok with adding new progress option for Task 'cancel-requested'.

I would like to see feedback also from others, especially for your initial question

For example, can a source asset for a given task be modified when it is in progress? If so how is it indicated?
Or are updates forbidden after a task has started?