Filter help: Show tasks "finalled" this week


I’d like to be able to know which tasks have had their status changed (to “final”) each week.

I’m aware I can use the Task History widget to see a graph of change of status over time - but that does not clearly tell me which tasks have changed in a given week. I suppose I could add a field called “Date of Last Status Change” and keep that updated everytime the status is changed but I’d consider that a last resort. The information is already there inside the status field history but it seems it cannot be accessed by filters or grouping. It would be great if I could group by the “Date Updated” of the status field rather than just the “Date Updated” of the entity. Do you have any other suggestions?



Setting up a filter like this on the Tasks page should do the trick I think:

(My title & specs don’t match, but you get the idea - your options for “in a calendar week” can be current, previous, etc.)


Hi Jessica

Thanks for this. The problem with that is that any update to Task will cause the Date Updated to update. Eg if the task is reassigned or a new field is added or whatever then it will show up as “Finalled this week”.

That’s why I was interested in knowing when the field itself was updated. Thinking about it more though, even that would be fragile since shotgun only records field history for a limited number of months. I’m starting to think the only way out is to add and maintain “Date Status Updated” or “Date of Final” field…


We have similar requirements – needing to know specifically when certain things have happened, and being able to generate reports on time-bases. Ultimately what we did was create a new CustomEntity called a “Week”. This was chosen because it was the desired measurement frequency. (You could do a CustomEntity called a “Day” if your frequency is faster, or “Fortnight” or “Month” if slower, etc.) Then we have a script that creates the Week entities for a project based on the start and end shooting dates, plus some time at the front for pre-prod and some time at the end for post. Then, we run an event daemon plugin that looks for the interesting events, like in this case {'Shotgun_Task_Change': ['sg_status_change']} to final. When that plugin catches such an event, it calculates the calendar week corresponding to that date, sg.find_one's the Week entity corresponding to that date, and stamps that Week entity into a single-entity field we added to the Tasks table called Week Approved. In that way you can then do queries and query fields on the Week entities, they work in filters, etc etc. You could have all kinds of single-entity Week fields for other interesting events and stamp those with that event daemon too.


Hi Tony

Using a “Week” entity sounds pretty interesting. I don’t fully understand what advantage it has over a date field though? With a date field, you could still use filters to grab Tasks approved in a given week (after date-x, before date-y), or use grouping to group by day/week/month etc. Using a Week entity I’m not sure how you could get all Tasks approved before a given date for example.


Hi @luke,

One best practice that we follow is to update the End Date of the task to the current day as soon as the task is approved.
This helps us graph or list the shots approved each week.

But, I know that this is prone to human error.
Is that why you’re looking to filter by the date that the Status field was updated?

One workaround, is to have an event demon update the End Date field each time that a Status is updated to Final.
I know that this is a potential rabbit hole and you might not be comfortable taking this approach, but just wanted to put it out there as an option.


Hi @Govind_Kalburgi

I ended up writing an event plugin for this. The production team wanted a field “Date First Finalled” to record the date that the task went into a final status for the first time. Basically the trigger just sets this field to the date that the Shotgun_Task_Change event was created (so long as the field does not already have a value). I guess it’s pretty similar concept to the “End Date” but for that specific use case