tokens-studio
Collaborators with Read only github permissions cannot sync with a repo that has multiple .json token files
Closing this, feel free to reopen if the GitHub provided way of defining permissions doesn't suffice.
Originally posted by @six7 in https://github.com/six7/figma-tokens/issues/1070#issuecomment-1193082353
Reopening related issue....
Ok, so I have created a second collaborator in our github repo with their role set to Read permissions as you have suggested. They are able to authenticate through the plugin's github integration to the branch but are NOT able to pull the token sets down. We have currently 3 .json files there. None are pulled when a pull request is made.
Based on the documentation it look like multi-file sync requires a Pro license.
Does sync'ing require a Pro license for those that only need Read access to multiple .json files?
FYI... just tested removing my Pro license and was able to still pull multiple .json files from github. This issue appears to be specific to Read Github user roles only.
@six7 FYI... we also tested changing the Github role to Read/Write privs today. With Read/Write privs these individuals were able to pull multiple .json files down from the remote Github without the Pro license too.
So in summary... GitHub repo Read roles currently cannot pull through the latest plugin version as we had hoped and you had suggested in #1070.
Your help here is much appreciated.
We hopefully fixed this in 114 as we discovered an issue that caused the behaviour you outlined. Let me know if that fixed it for you 🙏
@six7 I just tested 115 this AM with another person who’s role was set with Read privs. They can now pull multiple .json token files from a Github repo, which is great. Thank you for the #1118 fix.
I did run into what may be a related issue though. Read roles cannot set specific token as Source which breaks another token set.
Is this related to the Github privs?
Ideally those with Read privs pull token sets down and any Source mapping that the owners have set up are remembered and automatically applied for those with Read only privs. As a fallback though it would be acceptable if the Read roles have to enable Treat as Source on sets that require it based on how they were created. Thoughts?