Path permission and merges have critical flaw

Unity Services
,
1

Hi,

I’m encountering a critical issue with path permissions in Plastic SCM, and I’m hoping to get some guidance here.

Scenario Overview

We have a Unity project with the following file structure:

Assets/Textures/background.png
Assets/Core/CoreSystem.cs

Our team consists of two members:

  • John: Programmer and administrator.
  • Dale: Artist.

Permissions Setup

We want Dale to have check-in permissions only for art assets, specifically anything under the Assets/Textures/ directory. To enforce this, we’ve set up path permissions in Plastic SCM so that Dale cannot modify or check in changes to code files like CoreSystem.cs under Assets/Core/.

The Issue in Detail

  1. Branch Workflows

    • Dale is working on his own branch: main/task-new-background.
    • John commits a critical fix to CoreSystem.cs in the main branch.

  2. Need for Updates

    • Dale needs the latest changes from the main branch to continue his work, as the game won’t run properly without John’s fix.

  3. Attempting to Merge

    • Dale attempts to merge the main branch into his branch (main/task-new-background) to get the latest updates.
    • The merge includes the changes to CoreSystem.cs made by John.

  4. Encountering Errors

    • There are no merge conflicts.
    • When Dale tries to check in the merge result, Plastic SCM throws an error:
      You don't have permission to check in changes under Assets/Core/
    • Dale cannot complete the merge because he lacks check-in permissions for Assets/Core/CoreSystem.cs.

Understanding the Problem

  • Dale isn’t trying to modify CoreSystem.cs; he’s only trying to incorporate the latest changes from the main branch.
  • Due to the path permissions, any merge that includes updates to restricted files blocks Dale from checking in, even if he hasn’t made changes to those files himself.
  • This issue prevents team members with restricted permissions from keeping their branches up to date with the main branch, hindering collaboration and workflow.

Why This Is Critical

  • We have multiple team members with different roles and permissions (artists, testers, programmers).
  • We need to restrict certain users from modifying core code files to maintain code integrity.
  • However, the current permission setup disrupts the workflow by preventing necessary merges.

Questions

  1. Is there a way to allow users to merge changes from the main branch without granting them check-in permissions for restricted paths?

    • Essentially, can users like Dale merge updates that include changes to restricted files, as long as they don’t modify those files themselves?

  2. Are we misconfiguring our permissions or missing a feature in Plastic SCM that accommodates this scenario?

  3. What is the recommended workflow in Plastic SCM for teams with role-based path permissions to ensure smooth collaboration?

Has anyone faced a similar issue with path permissions in Plastic SCM? How did you resolve it?

2

Thanks for the complete explanation and details. Let me also cc @mathiasahrens (Senior PM for Version Control) for visibility on this.

I don’t think there is a good workaround to support this behavior at the moment. If we would allow you to checkin all the changes happening via merge, you also open a dangerous door.

I guess you already know that you can also manage the path permissions per branch. You could potentially enable the checkin permissions in the task branch and deny them in the main branch for this user. This way, if they checkin some changes in this path in the task branch, they won’t be able to merge these changes to main.

1 Like
3

Thanks for the reply, Carlos!

Unfortunately, the solution you proposed doesn’t quite fit with how our setup works. No one can push directly to the main branch—everything has to go through code review and a merge.

Each dev works on their own branch, and while they can’t commit directly to main, they can still accidentally modify files they shouldn’t and check them in into their respective branch, either due to inexperience or by mistake when working on too many things at once.

This way, if they check in some changes in this path in the task branch, they won’t be able to merge these changes to main.

That’s the tricky part—only admins can merge branches into main (and they have all permissions), but the modified files still get through during the code review process.
When “protected” files are already changed, we have to either manually remove the changes or revert them, which is tough because Plastic doesn’t seem to have a smooth way of doing this (at least not that I’m aware of).

This is why I brought up the issue. Our setup is pretty standard in the industry, and merging/permissions like this can be a big headache.

I noticed that Plastic already tracks which files are part of the merge (since unchecking a merge file prevents check-in), so maybe there’s a potential solution there? Just thinking out loud! :sweat_smile: But I understand this is quite complex topic to tackle.