Poll: Anybody using current_user/1 prolog predicate?

248 views
Skip to first unread message

Dave Borowitz

unread,
Oct 14, 2014, 7:59:13 PM10/14/14
to repo-discuss
See https://gerrit-review.googlesource.com/Documentation/prolog-change-facts.html

Using this predicate may produce some surprising results, such as two different users being presented with completely different sets of required labels, or even different submit type. If user A clicks submit it might be Always Merge, but if user B clicks submit it might be Cherry-Pick.

Weird, huh?

I can't think of any compelling use cases for this label, and only the resulting confusion, so I would propose deleting it. But if anybody is successfully using it, I'd be interested to hear about it.

Jon Bettcher

unread,
Oct 14, 2014, 8:45:02 PM10/14/14
to repo-d...@googlegroups.com
Hmm, well I do have some project-specific rules that use current_user/1, but only for submit rules.  A couple of use cases I have seen:

- Only users of a certain group should be able to submit to a certain branch (i.e. release)
- Reviews must have a +2 from a non-author (non-author-code-review), however permit select users override privileges to submit regardless.  Generally looks something like:
  gerrit:current_user(U),
  submit_override(U).

It does create situations where labels may appear differently for different users.  This is fine for my workflow, but I can understand it being odd for others.  I don't currently use current_user with any submit_type rule.

-Jon

Saša Živkov

unread,
Oct 15, 2014, 9:36:20 AM10/15/14
to Dave Borowitz, repo-discuss
We have an example [1] in the prolog cookbook which makes use of the current_user in order
to make the change submittable only by the change owner...

With the "Change Owners" group this requirement can be handled via access permissions...

I am not aware of any other usage of the current_user.

--
--
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.

Saša Živkov

unread,
Oct 15, 2014, 9:37:52 AM10/15/14
to Dave Borowitz, repo-discuss
On Wed, Oct 15, 2014 at 3:36 PM, Saša Živkov <ziv...@gmail.com> wrote:


On Wed, Oct 15, 2014 at 1:58 AM, 'Dave Borowitz' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
See https://gerrit-review.googlesource.com/Documentation/prolog-change-facts.html

Using this predicate may produce some surprising results, such as two different users being presented with completely different sets of required labels, or even different submit type. If user A clicks submit it might be Always Merge, but if user B clicks submit it might be Cherry-Pick.

Weird, huh?

I can't think of any compelling use cases for this label, and only the resulting confusion, so I would propose deleting it. But if anybody is successfully using it, I'd be interested to hear about it.

We have an example [1] in the prolog cookbook which makes use of the current_user in order
to make the change submittable only by the change owner...

With the "Change Owners" group this requirement can be handled via access permissions...

I am not aware of any other usage of the current_user.


Dave Borowitz

unread,
Oct 17, 2014, 11:51:37 AM10/17/14
to Saša Živkov, repo-discuss
Ok, it sounds like there are definitely legitimate use cases for current_user/1 in submit rules.

I amend my proposal to disallow current_user/1 from submit type rules only, but I'll have to look into how we can do this technically in the Prolog environment setup.

Dave Borowitz

unread,
Oct 17, 2014, 12:08:14 PM10/17/14
to Saša Živkov, repo-discuss
Done in https://gerrit-review.googlesource.com/60891 in case anybody wants to comment.

xchan...@google.com

unread,
Nov 21, 2017, 5:20:51 AM11/21/17
to Repo and Gerrit Discussion
Now we come to this discussion again. Could we remove this predicate completely?

The state of this predicate is inconsistent now:
1- In ChangeDate, it's set as the change owner explicitly [3]. Because it's difficult to keep track of
the "current user" in a ChangeData, which is not always tied to a request. 
2- In Mergeable#148, ReviewerJson#131, OutputStreamQuery#257, it's set as the current user of the request.

In the ChangData we are dealing with 'SubmitRecords', which are used used to support the "is:submittable" query. 
If this 'current_user' predicate is used in the prolog rules, the 'submittable' could be variant from user to user.
Recompute this field for every new request sounds bad and it's actually what we are trying to avoid.

So instead of confusing our users, could we just remove this predicate completely?

For the use cases mentioned, they can be achieved by(from hiesel@):

"- Use of the current_user in order to make the change submittable only by the change owner => Use the magic group change owner in ACLs
- Only users of a certain group should be able to submit to a certain branch (i.e. release) => Use ref ACLs
- Reviews must have a +2 from a non-author (non-author-code-review), however permit select users override privileges to submit regardless 

Jonathan Nieder

unread,
Nov 24, 2017, 5:59:22 AM11/24/17
to xchan...@google.com, Repo and Gerrit Discussion
> - Reviews must have a +2 from a non-author (non-author-code-review), however permit select users override privileges to submit regardless
> => IMHO this can also be achieved by checking group membership in an 'override' group and using other facts and ACLs"

How does that work? Do you mean checking such group membership in prolog or somewhere else? I am not seeing any straightforward way to make it work.

In theory any use of current_label could be replaced with a new "submit" label and using commit_label on that label. That's cumbersome because it means submitting takes two steps: set the label and then click submit.

One argument in favor of removing current_user is that as you say, it has not been supported well over the years. That might be enough reason. Moreover, as you say, there's no reasonable way to make it work with is:submittable queries. So I think I'm still in favor of this change, even though it complicates rules like e.g. "only the committer can submit".

Thanks,
Jonathan

вт, 21 нояб. 2017 г. в 2:20, xchangcheng via Repo and Gerrit Discussion <repo-d...@googlegroups.com>:

Changcheng Xiao

unread,
Dec 1, 2017, 6:48:58 PM12/1/17
to Jonathan Nieder, Repo and Gerrit Discussion
Is there any objection for removing this prolog fact?

I have prepared a CL to remove it.


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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Oleksandr Presich

unread,
Oct 15, 2019, 9:22:12 AM10/15/19
to Repo and Gerrit Discussion
Guys, what about following use case - we'd like to restrict 'Submit' rights for a list of files in the repo to group of people, but allow to Submit any other file/path.
Gerrit permission system doesn't allow to put a path regex to apply permissions to, only branch reference.

Could you advise possible solution for such a use case?

I know current_user/1 has been removed removed long time, but I've get used to it in a previous company, and not sure how to apply the same restrictions with new Gerrit versions.

субота, 2 грудня 2017 р. 00:48:58 UTC+1 користувач Changcheng Xiao написав:
To unsubscribe, email repo-d...@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-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Edwin Kempin

unread,
Oct 15, 2019, 9:46:21 AM10/15/19
to Oleksandr Presich, Repo and Gerrit Discussion
On Tue, Oct 15, 2019 at 3:22 PM Oleksandr Presich <presich....@gmail.com> wrote:
Guys, what about following use case - we'd like to restrict 'Submit' rights for a list of files in the repo to group of people, but allow to Submit any other file/path.

You may require an additional label if these files are touched.
Then grant permissions to vote on that label only to that group.

 
Reply all
Reply to author
Forward
0 new messages