How to remove or modify the auto date update changes (trigger)event in task?

[EricTsuei]

How to remove or modify the auto date update changes (trigger)event in task?
I am using tactic 4.5
for example, in an asset's tasks(like 5 tasks),
when you change the first task's start date or end date. seems it will trigger some event to auto-update the other task's start dates.
but some times I don't need this event when the task's status or some column equal some values like this task is locked, please don't change it anymore.
since I already use trigger event to prevent users changes some of the "locked" tasks, but I can't prevent the auto-update other's start date events.
So I need to disable this event or modify it.
but I can't find this event code.
please tell me what I can do.
thanks.

[listy]

You can create your own Task status workflow for particular process and setup your events manually.
Notice there is a "Behave as" in the tasks status nodes, don't enable those if you don't want built-in triggers.

[EricTsuei]

But I have already created my own task status workflow and not using any events.
and I also create my own workflow(process) for asset/shot,, etc stypes.
I not using any triggers for each process.

[listy]

Which widget do You use to change date end?
Can you give steps to reproduce?

[EricTsuei]

just create an asset, then add some tasks for it. then tweak the "bid_start_date", and then will trigger the auto-update the rest of the tasks "bid_start_date". but it does not happen every time, I even don't know the logic here, before seeing the code of this trigger.

[EricTsuei]

please help

[listy]

please help

Hi. I will try to redo your situation when i got some spare time.

[remkonoteboom]

The only internal trigger I know of is that one that will synchronize task data on tasks that have the same parent, process and context. This is how TACTIC manages assigning multiple people to a "task". It treats tasks that have these three properties as identical tasks but are assigned to different people.

For example, if I have a shot, SHOT001 that have a task in the "model" process. If I add another task in the model process, then those tasks are linked unless the "context" column of the process is different.

Note: this was was disabled 4.6 as it proved annoying as multiple tasks in the same process changed dates, as Eric has just witnessed (I believe this is his problem, as he has not mentioned enough information for me to conclude that).

In 4.5, you can stop this from happening by changing the context of the second task to "model2" (or any value other than "model") as per my example.

[EricTsuei]

The only internal trigger I know of is that one that will synchronize task data on tasks that have the same parent, process and context.  This is how TACTIC manages assigning multiple people to a "task".  It treats tasks that have these three properties as identical tasks but are assigned to different people.

For example, if I have a shot, SHOT001 that have a task in the "model" process.  If I add another task in the model process, then those tasks are linked unless the "context" column of the process is different.

Note: this was was disabled 4.6 as it proved annoying as multiple tasks in the same process changed dates, as Eric has just witnessed (I believe this is his problem, as he has not mentioned enough information for me to conclude that).

In 4.5, you can stop this from happening by changing the context of the second task to "model2" (or any value other than "model") as per my example.

yes, I think you are right.
it's not possible to change each task, we do have so many tasks for over 7 projects.
Where is this internal code? maybe I can disable this trigger.

[remkonoteboom]

The code is in src/tactic/command/pipeline_task_trigger.py

411 # DISABLING this ... this is a rather tenuous trigger that attempts to allow for
412 # tasks to be "connected" to each other in a way that makes it look like you have
413 # multiple people assigned to a task. While this may be desireable, the mechanism
414 # used below checks for the same process and context to identify tasks tat are connected .
415 # This is too broad and should be done more explicitly rather than implicitly
416 return

It seems as if a while ago this was backported to 4.5, using a 4.6 commit, but I didn't have it in my 4.5. Syncing it to the latest 4.5 from Github did bring this code in.