Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

  •  
     
    story #8352 control who can create tags with patterns
Actions
Summary
git admin
control who can create tags with patterns
I can have official tags handled by integrators and casual tags handled by developers

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

 

Empty
Nouha Terzi (terzino)
Status
Empty
Canceled
Development
  • [ ] Does it involves User Interface? 
  • [ ] Are there any mockups?
  • [ ] Are permissions checked?
  • [ ] Does it need Javascript development?
  • [ ] Does it need a forge upgrade bucket?
  • [ ] Does it need to execute things in system events?
  • [ ] Does it impact project creation (templates)?
  • [ ] Is it exploratory?
Empty
Details
#8352
Manuel Vacelet (vaceletm)
2015-09-16 10:38
2015-08-19 16:29
4703

References
Artifact links
Empty
Referencing story #8352

Artifact Tracker v5

epic #8353 Git fine grain permissions management
Referenced by story #8352

Artifact Tracker v5

story #8354 have visibility on git permissions changes
Display settings

Follow-ups

User avatar
Manuel Vacelet (vaceletm)2015-09-16 10:38
I cancel this story, the parent epic was updated to take this description into account.

The final behaviour will stay the same but we split in differnt stories/steps.
  • Status changed from Ready (stalled) to Canceled
  • Category set to
User avatar
Nouha Terzi (terzino)2015-09-15 15:13

Am I missing something ?

It is Ok, now. Thank you. 

 

Could you proceed with the estimation, please?

User avatar
Manuel Vacelet (vaceletm)2015-09-14 16:04

 think it is missing the @Contributors in RW refs/heads/.* in the example  3 for branchs settings

I don't think so. As you can see, * pattern is only for Developers (in the "mockup") so Contributors shouldn't be allowed to commit in "non dev/* branches"

Am I missing something ?

The sentence [...] and the line here: [...] seems not aligned, no ?

You are right, I fixed the desc.

  • Acceptance criteria
    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
Nouha Terzi (terzino)2015-09-07 17:50

The sentence

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.

and the line here:

 RW refs/tags/.*          = @Developers @Integrators

 

seems not alined, no?

 regards,

Nouha

User avatar
Nouha Terzi (terzino)2015-09-07 17:36

Hello Manuel,

 I think it is missing the @Contributors in RW refs/heads/.* in the example  3 for branchs settings ,

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

isn't it?

User avatar
Manuel Vacelet (vaceletm)2015-09-02 17:23
Denis, Nouha,

After discussion with the team we have a proposal in term of UI / behaviour.

Is that clear enough ?
What do you think ?

Note: the + part is that it brings the management of permissions per branches as well
  • Acceptance criteria
    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
Denis PILAT (denis_pilat)2015-08-25 15:48
ok understood now !
That's sounds fine to me, I'm waiting from business feedback, then I'll give you green light for estimation.
User avatar
Manuel Vacelet (vaceletm)2015-08-25 15:45

Using "project event" was confusing to me in story #8354. I didn't think you were talking about system event managed in Tuleap event queues.

I'm not talking about "system events", I'm talking about the events you can find, as project administrator in Admin > Project History.

So it's "events" that are generated by this development, with parameters (project name, repo Id, owner ...) and in the story #8354 you'll be able to notify when these event are generated, with some details about the projects and the git repo and the owner in the email ?

Yes, it will be generic email like:

---------------------->8----------------------

John Doe did git tag pattern update in project Guinea Pig.

Modified object: arch/x86_64/kernel git repository

  • Old value: refs/tags* developers
  • New value: refs/tags* project_members

---------------------->8----------------------

User avatar
Denis PILAT (denis_pilat)2015-08-25 15:35
Using "project event" was confusing to me in story #8354. I didn't think you were talking about system event managed in Tuleap event queues.

So it's "events" that are generated by this development, with parameters (project name, repo Id, owner ...) and in the story #8354 you'll be able to notify when these event are generated, with some details about the projects and the git repo and the owner in the email ?
User avatar
Manuel Vacelet (vaceletm)2015-08-25 15:09

I'm not sure to understand your follow-up, let me rephrase:

  • With story #8354, there will be 2 events
    • git permissions changed
    • git tag patterns changed
  • Site admin can create an email notification for
    • git permissions changed
    • git tag patterns changed
    • or both

Is that more clear ?

 

User avatar
Denis PILAT (denis_pilat)2015-08-25 11:09
With nofification mechanism in story #8354, can we make sure a dedicated event will be used only when a patern is changed ? Here you are talking about an event entry in the project history, but I need to make sure an unique "site admin event" will be generated, too many dummy alerts will kill the alerting mechanism relevancy.
User avatar
Manuel Vacelet (vaceletm)2015-08-19 17:24
  • Acceptance criteria
    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
  • As a
    -project admin 
    +git admin 
User avatar
Manuel Vacelet (vaceletm)2015-08-19 17:18
  • Acceptance criteria
    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
  • CC list cleared values: None