Shotgun Desktop not loading correct pipeline configuration for some users

Pipeline Integrations
1

Hello,

I’ve hit a pretty sticky issue here. I have a pipeline configuration that uses an uploaded config to override a Primary config for a specific project. This has been working fine with the exception of one user. When looking at the tk-desktop.log file I see the following warning when using Shotgun Desktop with their account.

2020-07-30 10:56:14,395 [   DEBUG] Our plugin id 'basic.desktop' matches pattern 'basic.*'
2020-07-30 10:56:14,398 [ WARNING] Pipeline configuration {'plugin_ids': 'basic.*', 'code': 'Primary', 'users': [], 'mac_path': None, 'project': {'type': 'Project', 'id': 559, 'name': '###########'}, 'descriptor': None, 'uploaded_config': None, 'windows_path': None, 'type': 'PipelineConfiguration', 'id': 397, 'linux_path': None} does not define a valid access location. Details: Pipeline Configuration 397 does not have a descriptor uri or uploaded config specified.

Logged into any other account on the same machine the override config is detected as shown below.

2020-07-30 11:12:35,407 [   DEBUG] Primary match: {'plugin_ids': 'basic.*', 'code': 'Primary', 'users': [], 'config_descriptor': >, 'mac_path': None, 'project': {'type': 'Project', 'id': 559, 'name': '##########'}, 'descriptor': None, 'uploaded_config': {'name': 'shotgun_config-20.4.2.zip', 'url': 'https://...', 'content_type': 'application/zip', 'type': 'Attachment', 'id': 9992, 'link_type': 'upload'}, 'windows_path': None, 'type': 'PipelineConfiguration', 'id': 397, 'linux_path': None}
2020-07-30 11:12:35,407 [    INFO] 'Primary' pipeline configuration '397' for project '559' overrides 'Primary' pipeline configuration '233' for site.

The permissions group for the affected user is Artist. Other users with the same permissions group are not experiencing the issue.

I feel like I must be missing something pivotal here! Any ideas?

Things I’ve tried:

  • Shotgun Desktop v1.5.7 and v1.5.8.
  • Using another Machine with the same account
  • Unregistering folders for the project
  • Deleting bundle_cache and our site configurations from the users appdata folder.
2 Likes
2

Correction - I’ve realized that this is not affecting only 1 user but also a test user with the same permissions group. It’s unclear to me why these users seem unable to read the uploaded_config field of the pipeline configuration entity even though they do have permissions to see it.

image
image695×24 1.44 KB

image
image665×507 9.08 KB

3

Annnnd, fixing this was as simple as uploading the zip of the config again.

2 Likes
4

Hi Dan –

Sorry you had to go this one alone, but I’m glad you got yourself unstuck. I might have suggested checking the permissions on a File entity (the attachment field is actually linked to File), but if reuploading did the trick, then it just sounds like a very weird glitch. Let us know if it crops up again!

1 Like
5

I am also experiencing the same problem with two users with Artist permissions. They are unable to use a sandbox they’ve been assigned to. They get a warning in tk-desktop.log which is the same as Dan_Bradham. I checked the entity permissions for PipelineConfiguration and File and the Artist users have the same permissions as other users who are able to access the sandbox config. I’ll try the re-upload (hit it harder?) and see if that helps…

6

Thought I’d share something I’ve run into before along these lines…

I often have a custom page to display PipelineConfigurations across multiple projects. When setting up a new config, I was duplicating the PipelineConfiguration in Shotgun, uploading a new zipped config to the Uploaded Config field, and then re-assigning the Project on the PipelineConfiguration.

For example

  • Duplicate PipelineConfiguration primary on Project Foo
  • so now I also have PipelineConfiguration primary (Copy) on Project Foo in Shotgun.
  • Upload zipped config to primary (Copy)
  • Update the Project on primary (Copy) to Project Bar
  • Update the name primary (Copy) to primary on my new config on Project Bar

The problem with this is that when I uploaded the zipped config to my duplicated PipelineConfiguration, it was still associated with Project Foo. This means the Attachment that gets created for the zipped config is also associated with Project Foo.

So I now have a PipelineConfiguration for Project Bar with an Uploaded Config containing an Attachment linked to Project Foo.

For Artists that have specific project permissions, this caused them to not be able to view the uploaded config if they did’t have access to Project Foo. Re-uploading the config will solve it which is what makes me think you may be running into the same issue.

Changing the order of operations (assigning the new Project to your PipelineConfiguration before uploading the zipped config) will also solve this.

Kind of annoying and difficult to debug when it’s happening. The more you know! :rainbow:

cheers,
kp

7

Thanks, KP - I’ll pass this along to the other Devs at THR3D! Re-uploading did the trick in this case, also.

Rich