Relationship between Gerrit Submit and Rebase permissions

[Matthew Webber]

I'm reworking our existing Gerrit (2.15.1) permissions, and I have hit a problem.

Goals:

• Developers should be able to "Submit" their own changes (subject to Verified and Code-Review), but not those of other developers.
  
• Developers should be able to "Rebase" their own changes through the web UI, but not those of other developers (they can still rebase locally and push up a new patch set for someone else's change).
  

Steps:

1. Give developers "Submit" permission on refs/heads/* - this is needed for them to submit through the web UI.
2. This seems to give them permission to submit other people's changes also. It looks like you can restrict the Submit permission to only some refs, but not to the change owner only.
   
3. Make sure there are no extra "Rebase" permissions.
   
4. Developers can still rebase other's changes through the web UI.
5. According to the documentation, "The change owner and submitters can always rebase changes in the web UI (even without having the Rebase access right assigned)."
   

Problem! If you want people to be able to submit their own changes, it looks like they will as a consequence be able to use the web UI to rebase other people's changes

Have I misread, or misunderstood, how this works? Is there a way to do this?

Thanks

Matthew

[David Pursehouse]

This should be as simple as allowing submit for the Change Owner virtual group.

I.e.

[access "refs/heads/*]

   submit = group Change Owner

 

Thanks

Matthew

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Webber]

On Tuesday, 1 May 2018 00:43:36 UTC+1, David Pursehouse wrote:

This should be as simple as allowing submit for the Change Owner virtual group

Doh! Of course. Thanks, I had completely forgotten about Change Owner.

Here's a variant which I can't figure out:

• Developers should be able to "Submit" all changes (subject to Verified and Code-Review), not just their own
  
• Developers should NOT be able to "Rebase" other people's changes through the web UI (they can still rebase locally and push up a new patch set for someone else's change).
  

It looks like as soon as I give someone the ability to "Submit" a change, they then have the ability to "Rebase" that change.

From the docs:

The change owner and submitters can always rebase changes in the web UI (even without having the Rebase access right assigned).

It's not clear to me why that should be - is there any way around it?

[Matthias Sohn]

I don't understand why you want to disallow developers to rebase other people's changes in the UI

but allow them to do the same via local rebase 

[Matthew Webber]

On Tuesday, 1 May 2018 11:19:15 UTC+1, Matthias Sohn wrote:

I don't understand why you want to disallow developers to rebase other people's changes in the UI

but allow them to do the same via local rebase 

I personally am not particularly interested in that, but it's a distinction that Gerrit makes.

From the Access Controls documentation on Rebase (https://gerrit-review.googlesource.com/Documentation/access-control.html#category_rebase)

Rebase
This category permits users to rebase changes via the web UI by pushing the Rebase Change button.

The change owner and submitters can always rebase changes in the web UI (even without having the Rebase access right assigned).

Users without this access right who are able to upload new patch sets can still do the rebase locally and upload the rebased commit as a new patch set.

We've had a few cases recently where people have rebased someone else's change (because they like a linear history I think), and messed things up because they did not think about other changes in the relation chain.

Blocking a one-click rebase of someone else's change would reduce the incidence of this, I think.

It's a minor issue only, but when I started at looking at the access rules, I can across what to me seemed strange - how Submit also gave you access to the (seemingly unrelated) Rebase.

Thanks

Matthew

[David Pursehouse]

On Tue, 1 May 2018, 19:39 Matthew Webber, <mat...@unsolvable.org> wrote:

On Tuesday, 1 May 2018 11:19:15 UTC+1, Matthias Sohn wrote:

I don't understand why you want to disallow developers to rebase other people's changes in the UI

but allow them to do the same via local rebase 

I personally am not particularly interested in that, but it's a distinction that Gerrit makes.

From the Access Controls documentation on Rebase (https://gerrit-review.googlesource.com/Documentation/access-control.html#category_rebase)

Rebase
This category permits users to rebase changes via the web UI by pushing the Rebase Change button.

The change owner and submitters can always rebase changes in the web UI (even without having the Rebase access right assigned).

Users without this access right who are able to upload new patch sets can still do the rebase locally and upload the rebased commit as a new patch set.

We've had a few cases recently where people have rebased someone else's change (because they like a linear history I think), and messed things up because they did not think about other changes in the relation chain.

Blocking a one-click rebase of someone else's change would reduce the incidence of this, I think.

FWIW the reason that the rebase permission was implemented was to prevent drive-by rebases being done by new users randomly clicking around on the UI. 

It's a minor issue only, but when I started at looking at the access rules, I can across what to me seemed strange - how Submit also gave you access to the (seemingly unrelated) Rebase.

Thanks

Matthew