I wasn’t sure which section to post this in, so here it is.
We created a Shot Task Template a few months ago with 11 Tasks related to Pipeline Steps, and then generated a number of Shot entries for a Project using that Template.
Today, we added a 12th Task to that same Template.
How do we get the Shots previously generated under that Template to be aware of this new 12th Task that should be available to them under that “same”-but-now-updated Template?
When I try to add this 12th Task to a Shot’s Tasks, it doesn’t show up as an option.
Great question. Updating an additional Task created in a Task Template to entities the Template is already linked to is possible, but it’s just a little hidden. (Whew! That was a mouthful.)
NOTE: the following functionality has changed after the 8.17.0.5743 release. Please see the solved response for details.
Once you’ve added the new Task to the Task Template, just head to your Task Template page > right-click on the Task Template you added the Task to > and then select “Update Entities with New Tasks”
Also note that this updates are only additive. So let’s say you delete a Task in a Task Template already linked to entities, and run the same update. In this case, the deleted Task will not be deleted from those entities. Only additions will be applied.
Be sure to check out some more information on this, along with other Task Template functionality in our Admin Guide here.
sorry to revive this thread but one of my TDs had a strange issue this week.
He added some Tasks to a Task Template and wanted to apply them to the previously generated Assets (this capture shows the 22/09/20 as the last update date, but he did some changes before, on 18/09/20):
He used the “Update Entities with New Tasks” as you show us just above Shayna, waited for it to apply - so far so good.
As you may have noticed on the project he is in charge of we use a secondary status field called work status.
Once the update applied on all his Assets he checked if the new Tasks were there and O_O all the old Tasks work status were put back to wtg!
Meanwhile, the usual basic status was not touched.
When looking at the event log we can clearly see the updates going on, and the work_status being put back to wtg. I am a bit puzzled bit the “unassign/reassign Task Template” at the beginning too, but ok.
Then my question is: would it be possible to discriminate between the elements that were changed on the Task Template and the others, then apply only the former?
Hi @François_Touvet, Sorry about that! In 8.15, we made an unintentional update to the “Update Entities with New Tasks” functionality and it seems you’ve been effected by it. We’re working on getting this fixed up, and I’ve linked up the dev ticket to our thread here so that I can let you know once the intended functionality is back.
In the meantime, note that “Update Entities with New Tasks” will update existing tasks with metadata specified in your task template—like the work_status field you experienced this with. It will also potentially update other data specified in the template (like duration and bid information if you have that filled in).
Do you have an understanding on how you can change those statuses back to their previous state, by referencing the event log?
I’ll let you know as soon as this gets fixed, and apologize for the inconvenience in the meantime!
Heads up - there’s been a bit of a delay in some sites getting to 8.17.0.5743 (the release with the fix) due to an incident. We hope to have this fixed up soon and deployed to all sites.
Heads-up that “Update Entities with New Tasks” has been replaced with “Reapply to project”, and a new, more robust dialogue has been added to show exactly what will be updated with a nifty project selector:
yes we saw that update coming with great pleasure, thanks a lot !
We still have an issue with our secondary status field though
When you say:
Statuses are never overwritten
Are you talking about the native sg_status_list field only, or any field with type ‘status_list’ ?
If the former, could it be possible to extend this rule so updates would stop overwriting other statuses fields?
Or even better: let the user decide which fields are to be updated with the Task Template changes.
Oh no — sorry about that! I’m pretty sure it’s meant for all status list type fields. Let me do some testing to try and reproduce, and I’ll discuss with the team. Stay tuned!
I discussed with the team and we’re going to try and get this fixed up asap. Currently, we’re just not overwriting the sg_status_list on Task which you discovered, but we’re not accounting for custom status list fields on Tasks. The intended behavior is to exclude any status list type field on task from being overwritten, so that’s what we’ll be fixing. Sorry about getting hit by this twice! And thank you for reporting this right away. I’ll let you know as soon as there is more news.
This time, I’d give it a quick test prior to updating all your tasks. If you have a test project, that would be the perfect place to make sure it runs smoothly on before updating anything big.
A bunch of Shots in a new Project (e.g. ‘ProjZ’) were assigned a Task Template from a previous Project (e.g. ‘ProjA’) accidentally, as there wasn’t a specific Shot Task Template for the new Project at the time production started.
We’ve created a new ProjZ_Shot_Task_Template, which is a duplicate of the ProjA_Shot_Task_Template, with 2 new Tasks added and 1 Task removed. Otherwise, the 2 Templates are identical, existing Task names are the same.
When I switch a Shot from the ProjA Template to the ProjZ Template, SG reports that there are a bunch of Tasks previously applied to the Shot from the ProjA Template that don’t exist in the ProjZ Template, then goes on to list a bunch of Tasks that do exist in both Templates as candidates to Trash.
The only Task we want to Trash when we switch Templates on Shots in ProjZ is the 1 removed one from the ProjZ Template, and if we only Trash that one we end up with doubles of all the rest.
Any clues as to what’s causing this unwanted behaviour? Solutions?
Edited to add: Only other note is that there has been previous activity on existing Tasks in the ProjZ Shots, but they’re still matching Tasks, only their attributes’ values have changed (e.g. ‘Assigned To’, ‘Status’, etc.).
When you duplicate Task Template, the new TT will have new tasks created (different ids) even if the tasks are identical in values (e.g. name).
So when you switch Task Templates, ALL the tasks will be added. So you will have Task X (From ProjA Template, id=1) and also Task X (from ProjZ Template, id=2). For the system, these are different tasks and it offers you an option to delete Task X of ProjA Template.
This is good to know. Initially, it is odd that a “duplicate” of a Task Template would create new Tasks that are identical but for their ID numbers, as I would expect that the Tasks within a Task Template duplicate would be identical, e.g. that both source and duplicate Templates would be using TaskX id=1, though thinking about it I can see how that could potentially create issues in other scenarios, e.g. a change to a “shared” Task in one TT affecting it in all TTs that contain it.
Is there any way you can add an option to “Reapply to project…” but keep all of the existing values for Duration, etc. instead of resetting them to blank if they’re blank in the template task?
We just added a bunch of tasks to our shot task template, then when we had to write a custom script to reapply it because a bunch of the data (e.g. duration) on existing tasks would get blown away if we used ‘Reapply to Project’ button.
Desired Workflow:
we add a bunch of tasks to the task template.
we remove a bunch of tasks we no longer need from the task template.
we click the ‘Reapply To Project’ button.
there’s a checkbox to ‘Keep Existing Name, Step, Duration, etc…’ instead of deleting them.
When we click ‘Reapply Task Template’ button it adds new tasks/removes deleted tasks, but keeps ALL of the existing data on all other tasks.
:
— sorry about that! I’m pretty sure it’s meant for all status list type fields. Let me do some testing to try and reproduce, and I’ll discuss with the team. Stay tuned!