I was hoping to provide clearer ui integration for some events using the ‘set_session_uuid’ functionality in a Shotgun api instance. However I’m not seeing any results on the webpage it’s been triggered from. I tried this in both Chrome and Firefox, with no discernable results.
I’m curious if I could get a better explanation of how session_uuid works. Am I limited to updating the item that triggered the change? I’m driving status changes across tasks and entities.
In past studios, I was seeing much more direct results from this, even without the session UUID. I’m not sure if something has changed in how updates via api work or something related to our studio’s Shotgun setup, or even differences in how web/network setup/security is handled.
Anyway, I’m looking for some deeper information on how session_uuid works and how to get the best results from it.
I’m going to go into the details of how our Web UI data update mechanism works and hopefully you’ll find answers to your questions. If not, feel free to share more about the design of your tool and maybe that can drive the conversation.
Some background
When you create or update a record in Shotgun’s web UI, we start what we call our news loader. This does not start automatically when you load a page, it only activates when you create or update a record. The news loader is a poller with an exponential falloff that stops when the pause between two fetches is more than 3 minutes. During this approximately 8.5 minute time period, the news loader will try to fetch updates 12 times or so.
If no updates are found during the news loader’s activity, it will stop. If activity is found, it will update records and you’ll see green blips on the screen which signal your new data. Finding activity will not accelerate the news loader but will stop it from slowing down for one cycle. This all means that if the news loader has never started because there wasn’t a record creation or update or if the news loader has already stopped, you won’t see any data updates. This also implies that an Action Menu Item invocation won’t automatically start the news loader as it is not necessarily a creation or update operation on a record.
News items are EventLogEntry records tagged with the same session UUID as your browser session. The session UUID is provided per browser tab. This means that editing in one tab won’t be reflected in another tab showing the same data as they have different session UUIDs. Also, because this is EventLogEntry based, if you can’t see this entity type because of permissions or if a script you’ve written isn’t generating EventLogEntries you won’t see updates.
Best Practices and Quick Notes
Make sure your users can see EventLogEntries - check all permissions. This should be the default.
Make sure your scripts that are editing data are generating EventLogEntries otherwise the news loader will have nothing to find. This is the Generate Events checkbox on Scripts which should be checked by default.
Only the user with the tab that matches the editing script’s UUID will see updates
The Shotgun Event Daemon by default takes the session UUID of the event being processed and initializes your plugin’s connection object with it (here and here).
When programming an Action Menu Item it is your responsibility to set the session UUID from the payload on your connection via the set_session_uuidmethod.
AMIs can be configured to start the poller or not. Check the Poll for Data Updates on your AMI if you want it to start the news loader when invoked.
Please let me know if you have any follow-up questions.
I know this is an old thread but I had a follow up question if that is okay.
I have an AMI configured to Poll for Data Updates. It is also configured to Open in Modal. The AMI is hooked up to hit a Javascript backend. So I am using the shotgun rest API to make my updates into Shotgun and setting the session_uuid as stated here. My question is, once I trigger the AMI, my modal overlays the window. In the background, should I be able to see those green flashes indicating that the field has been updated? I do see that the field is updated once I exit the modal and the entire page refreshes. If not, what benefit does setting the session_uuid do for me in this scenario with the AMI?
If you’re using a modal, I think the Poll for Data Updates is kind of useless because the modal blocks the page “underneath” and the page will be completely reloaded after the modal disappears. I don’t think you’d really have a different user experience if you disabled Poll for Data Updates.
Poll for Data Updates is more useful at times where the AMI is routing the processing to a local script via a custom protocol or some HTTP endpoint without using modal.
All things considered, I personally write my frameworks such that session_uuid is set regardless. Then, if I choose to enable Poll for Data Updates or not I don’t need to worry about the code.