•  
      epic #8353 Git fine grain permissions management
    Summary
    Git fine grain permissions management
    Empty

    Git tag & branches permissions management

    (elaboration of this can be seen in story #8352)

    At repository level

    On "Permission" tab, git admin can decide to use either the default, repository wide, permission settings (current mode) or to activate the "per tags/branches" setting described bellow.

    Regarding following proposal please note that:


    Example 1: default setup

    • Read to Contributors
    • Write to Developers
    • Rewind to nobody
    Read
    ====
    
    Select the user groups allow to read: Contributors
    
    Write
    =====
    
    Branches
    --------
    
    Pattern |   Write    | Rewind |
    --------|------------|--------|
       *    | Developers |   -    |
       
    Tags
    ----
    
    Pattern |   Write    | Rewind |
    --------|------------|--------|
       *    | Developers |   -    |
    
    Corresponding gitolite:
    
    repo mozilla/thunderbird
     R                        = @Contributors
     RW refs/heads/.*         = @Developers
     RW refs/tags/.*          = @Developers

    Example 2: 'official' tags to Integrators

    Read
    ====
    
    Select the user groups allow to read: Contributors
    
    Write
    =====
    
    Branches
    --------
    
    Pattern |   Write    | Rewind |
    --------|------------|--------|
       *    | Developers |   -    |
       
    Tags
    ----
    
      Pattern   |   Write     | Rewind |
    ------------|-------------|--------|
     official/* | Integrators |   -    |
          *     | Developers  |   -    |


    Corresponding gitolite conf

    repo mozilla/thunderbird
     R                        = @Contributors
     RW refs/heads/.*         = @Developers
     RW refs/tags/official/.* = @Integrators
     -  refs/tags/official/.* = @all
     RW refs/tags/.*          = @Developers

    Example 3: 'dev' branches are authorized to Contributors

    Read
    ====
    
    Select the user groups allow to read: Contributors
    
    Write
    =====
    
    Branches
    --------
    
    Pattern |   Write                  | Rewind |
    --------|--------------------------|--------|
      dev/* | Contributors, Developers |        |
       *    | Developers               |   -    |
    
    Tags
    ----
    
      Pattern   |   Write     | Rewind |
    ------------|-------------|--------|
     official/* | Integrators |   -    |
          *     | Developers  |   -    |

    Corresponding gitolite conf

    repo mozilla/thunderbird
     R = @Contributors
     RW refs/heads/dev/.*     = @Contributors @Developers
     -  refs/heads/dev/.*     = @all
     RW refs/heads/.*         = @Developers
     RW refs/tags/official/.* = @Integrators
     -  refs/tags/official/.* = @all
     RW refs/tags/.*          = @Developers
    

    Post notes

    • We are likely to propose a "group based UI" (like it's done in tracker field permissions) because sometimes you just want to know what a group can do
    • Permissions are always explicit, in example n°3 even if developers have access to refs/heads/.* they must be explicitly declared for refs/heads/dev/.*
      • Consequence, for example n°2 and n°3, integrators can only create official tags, they are note allowed to commit in any branch or to create any tag. If we want to grant them this, we need to declare them.

    Tracability & auditability

    An event is added in project history when the pattern or associated group change

    At project level

    • git admin can define a default pattern rule that will apply to all newly create repository
    • this default value is only used at repository creation
      • if pattern become refts/tags/REF/* after a while, repository already created must be updated manually
    • this value is inherited at project creation
      • so If I defined a pattern ref in my main template, all projects will have it by default (unless git admin explicitly change it

    Site admin have a fine grain control on git permissions

    Overall strategy

    In Tuleap ways of doing things, project administrators have 100% control and can change everything in their project.

    Hence, adding a fine grain control by site administrator only of git tag pattern at project level is against Tuleap rules.

    So we propose below an alternative:

    • project and git admin can modify patterns
    • but site administrator can be notified of such changes

    Site admin notification

    In site administration, I can select one of several project event (ex: git_permissions_update, git_tag_update) and associate email addresses.

    As soon as one project modify a git permission or a git tag pattern, configured emails will be notified.

     

    Progress
    Empty
    Empty
    Closed
    Details
    #8353
    Manuel Vacelet (vaceletm)
    2018-07-17 10:52
    2015-08-19 16:30
    Attachments
    Empty
    References

    Follow-ups

    User avatar
    Import top level description from story #8354

    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes