Optimal Procedures for Restricting Check-ins

[STG-Kaga]

We want to restrict check-ins on specific paths and only grant check-in permissions when necessary, revoking them afterward.
Are there any optimal procedures for achieving this using only UVC features?

We found this discussion about repository read permissions:

Permissions management

Hi, if you neither allow nor deny the view and read permissions at the server level for a specific group, you can explicitly allow access then for this group for the specific repos you need. Note that the permissions are overlapped. Please check the users are not belonging to multiple groups: Developers, and ALL_USERS. if some user belongs to a group with denied permissions, the denial always prevails. Regards, Carlos.

which suggests that “deny” always takes precedence.

Therefore, for user groups, it has been recommended to leave both “allow” and “deny” unchecked and only explicitly allow read permissions for individual repositories.

In practice, we’ve seen that if a user is part of any group where “deny” is checked, it always takes precedence.

However, we noticed that users who only belong to a user group with CI permissions set to neither “allow” nor “deny” were still able to check in. Could this be happening because their individual CI permissions are set to “allow”?

We also considered the following methods for restricting check-ins, but both are somewhat time-consuming:

1. Add all developers to a user group where CI permissions are set to “deny.” This would require adding new developers to the group every time someone joins.
2. Leave both “allow” and “deny” unchecked for individual CI permissions for each user. This is time-consuming due to the large number of developers. It would be more manageable if there were a way to make these changes in bulk. Unfortunately, the default settings currently have options checked, so each time a new developer joins, we have to configure this manually.

Is there a more efficient way to handle check-in restrictions using UVC?

[rednbrick]

Hi @STG-Kaga ,

If there’s denied permission regardless of whether at a group or individual level, denied permission always outrules the allowed permissions.

If you want the users not to modify for specific items, you can follow the instructions at Plastic SCM version control · Security guide

You can find the instructions on how to use permission in the link above.