@tkopecek - could we get this considered for the next milestone?

I'm ok with 1.21. For 1.20 I would need @dgregor's opinion.

We've closed the list of issues to 1.20 so that we can get the release out in January. @dustymabe what is the impact if this waits until 1.21 (April)?

We can wait til April. The impact is that we carry a workaround in Fedora release engineering for longer that allows a broader set of permissions to a group of users than what is needed. This is acceptable for now.

@mohanboddu @dustymabe Do you've more exact idea, how it should look like?
Do you want to still have dist-repo permission to be able to run distRepo against any tag and policy which allows some tags to be distRepoed even without that permission? What values should be input for such policy (tag, user, ...)?

@tkopecek - since I don't know enough about the details to give you a specific answer to your question I'm going to try to answer you with all the contextual information I have about the problem we are trying to solve.

The original ticket where this was discussed is here. As part of the discussion in that ticket we eventually got to the point link where we asked for dist-repo permissions to be granted to the coreos-continuous group to act on certain tags. However, when they tried to implement that they found that there was no way to do it and this ticket was opened.

cc @mohanboddu @kevin

@mohanboddu @dustymabe Do you've more exact idea, how it should look like?
Do you want to still have dist-repo permission to be able to run distRepo against any tag and policy which allows some tags to be distRepoed even without that permission? What values should be input for such policy (tag, user, ...)?

I guess a policy in which a user with a certain type of permission should be able to generate dist-repos on the specified tags in the policy.

In this example, any person who has coreos-continuous permission can generate dist-repos on coreos-pool and fxx-coreos-continuous tags.

As I read it, the request here is: make it easier to grant this access to a group (i.e. easier than granting the permission to each individual user).

Whether or not that involves policy is a design decision that I think warrants discussion.

This really ties in to a number of questions we had about the "granular permissions" feature. We made a small change there, leaving the larger changes for later.

There are a lot of places were folks wanted more complex access controls. I'm not certain we want to add policy hooks for all of them. It might be cleaner to have a policy (or similar) for "implicit permissions". That is, some rule tells Koji that user X has permission Y.

My inclination would be to defer this to a later release pending further discussion.

proposal: PR 2081

with hyperlink: https://pagure.io/koji/pull-request/2081

Commit 164e4bfb fixes this issue

Commit 9ef57c0f fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/1660

Please continue any further discussion there.