Hi there!
When working with the workfiles2 app, the work files shown doesnt display the latest artist/user that modified that file after saving or versioning up, instead it shows “Unknown”. Ive checked any potential setting or fields missing on the sg web browser and there was no difference in any file with the name of the person or not. Ive checked all through my sg repo code and nothing refers to it (the hooks, etc…). Ive been looking through the main sg code based in app_store with potentially trying to find the source of where the “modified_by” value is being set, but it seems very daunting as it is situated all over the place.
Although, some of the work files do in fact have the latest modified by an artist/user but it seems very uncommon within our workspace.
Could this potentially be a systems issue? Or does something need to be configured that I haven’t noticed about.
Cheers and thank you, Anthony
Hey Anthony,
This isn’t supported out of the box on windows; only linux/osx. You can probably add something to a hook to get it working on windows, but it most likely will come at a performance cost.
1 Like
Hi Patrick,
So this issue still happens on the linux machines - again its very uncommon to see the names but for some reason they just do not show up for the working files. They do however show the names on publishes, but this is a given as the publish data requires the name of the publisher while there is no mention of any requirements needed for working file info.
Would I perhaps be missing where this hook/feature lies within SG for this? I can’t seem to locate it as I have looked all around.
My mistake, you need to fork the app; it’s not related to the hooks.
See this method : def get_file_last_modified_user(self, path):
if sgtk.util.is_windows(): # TODO: add windows support..
If it’s failing in Linux, it might be that the last modification was by a windows user, which might not map to a linux user.
1 Like
Sorry I didn’t get to clarify that, the linux work files are strictly linux only and not related to any work done from windows.
Hi @Anthony_P & @Patrick,
I am looking into this issue further. @Anthony_P does the unix account name match the ShotGrid HumanUser login field?
Thanks!
1 Like
Hey @rob-aitchison, @Ricardo_Musch thanks for getting back to me.
So looking back at the login field for the user, the unix account name hasn’t matched that field. This should then theoretically work if I make sure to fix the login field to the exact name for the user on their linux machine, but looking through the function in user_cache.py that @Patrick mentioned above, sg_user = self._app.shotgun.find_one( "HumanUser", [["login", "is", login_name]], self._sg_fields) is returning None.
This is because for some reason for the _app attribute self._app = sgtk.platform.current_bundle() “current bundle” doesn’t seem to function with the find and find_one api calls, even calling it locally within a shotgun environment. However, if I swap it out with sgtk.platform.current_engine(), The Engine class seems to work perfectly with the ‘find’ calls.
It would be good to know if sgtk.platform.current_bundle() ever had the functionality to be able to call the find method in the first place, even though it seems to be one of its methods in the Application class that current bundle returns.
Much appreciated 
It’s not self._app.find_one, it’s self._app.shotgun.find_one
Also, if you don’t want to edit your linux usernames, you can probably see the potential to change this “find” call so it’s filter uses a different field; eg instead of login, ‘is’ you could use ‘sg_linux_username’, ‘is’. You would need to add this field to the humanuser entity though.
This also adds additional admin in terms of setting up users… so it’s not recommended! Just a pointer!
1 Like
I should have explained, I meant self._app.shotgun.find_one which is representing current_bundle().shotgun, which doesn’t seem to work.
Yeah I see the discrepancy issue, there might be a way to link the AD username to the specific shotgrid HumanUsers field. Will need to see what works best for ensuring two identical fields.
Ok what does current_bundle actually return then?
self._app = sgtk.platform.current_bundle() returns <Sgtk App 0x25e68b1ad08: tk-multi-workfiles2, engine: <Sgtk Engine 0x25e634a2488: tk-maya, env: asset_step>>
sgtk.platform.current_engine() returns <Sgtk Engine 0x25e634a2488: tk-maya, env: asset_step>
This was achieved on Windows, trying to explicitly return current_bundle() on Linux was constantly freezing for me.
I just did some more testing and now in fact it seems to return normally, allowing me to call find with current_bundle().shotgun. And the identical login field also seems to be functioning properly with a test run, but this was done by hard-coding my users login field into the find command, as changing the login field seems to break your users SG desktop unsurprisingly.
I could have sworn yesterday as I was troubleshooting, the current_bundle().shotgun.find_one method just never returned any existing IDs within our SG database at all (this was on windows, not sure if it was fine for Linux or not)…
EDIT: Even hard-coding simple find SG IDs and my proper user name still didnt return anything from the testing I did yesterday just to clarify the confusion.
print(sgtk.platform.current_bundle()) File "/home/anthony/.shotgun/stage23/p584c430.basic.desktop/cfg/install/core/python/tank/platform/util.py", line 171, in current_bundle return _get_current_bundle() File "/home/anthony/.shotgun/stage23/p584c430.basic.desktop/cfg/install/core/python/tank/platform/util.py", line 57, in _get_current_bundle "import_framework could not determine the calling module layout! " TankCurrentModuleNotFoundError: import_framework could not determine the calling module layout! You can only use this method on items imported using the import_module() method!
When attempting to print current_bundle() in a SG app on Linux
I think you need to put that print statement in the app. current_bundle doesn’t resolve outside a calling application as far as I can tell.
1 Like
You can only use sgtk.platform.current_bundle() from within an App or Engine.
It will resolve to whatever app or engine it’s currently run from.
I have tried running current_bundle() in both the workfiles2 app and also within one of the hooks. This would work on Windows but only fail on Linux.
Thank you all for the updates in this conversation!
We have logged the additional issue reported here regarding the current_bundle() call.
The Unknown user investigation is continuing and ongoing.
1 Like
