Allow Assignment of Issues to Users with READ access level

[kTitan]

• Gitea version (or commit ref): e87c540
• Git version: 2.17.1
• Operating system: Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

It should be possible to assign issues to people with "read" access.
Currently the users with "read" access rights to a private repo are not shown in the Assignees Dropdown.
But the People can for example send pull requests to the repo. In my opinion it would be logical, if this users can also have issues assigned.

Also Github does have this permission for the "read" access level.
As a reference please look here:
https://help.github.com/articles/repository-permission-levels-for-an-organization/
Line: Have an issue assigned to them

Screenshots

[stevegt]

Does anyone know of a workaround for this? I'd be okay with allowing assignment to any registered user on any repo regardless of collaborator status, for instance. Don't see any way to do that though.

[lunny]

What's permission is reasonable? For a public repository, writers to code and collaborators could be as assigners. For a private repository, readers, writers to code and collaborators could be as assigners.

[kTitan]

That sounds good for me.
In my case the most important part is, that readers of a private repos can become assignees of issues (and of course they still need the permission to create PR)

[lunny]

@kTitan we need a PR to do that.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[stevegt]

Re-opening because still needed afaik.

[davidsvantesson]

I think the required access shall be a setting, at least in app.ini (later on maybe per organization or repo).

To be assignable to an issue or pull request the user shall at least have read access to that unit (doesn't make sense to be assigned to something you can't read).
If you are assigned to an issue/pr you shall be able to make comments in it, even if you only have read access to other issues (comment from @guillep2k)

What options should there be for which are assignable? Some ideas:

• Read access to the issue/pr
• Write access to the issue/pr
• Read access to the issue/pr and write access to some other unit (code or pr?)
• Write access to the issue/pr OR read access when repo admin assign
• Read access but only repo admin can assign

We should make a good consideration which alternatives are really reasonable to avoid complexity in the code.

[guillep2k]

What options should there be for which are assignable? Some ideas:

I think that anyone with read access is a potential assignee. For private repos this is not a problem. The problem of course are public repos, with potentially hundreds of users and more. In this case I'd use the collaborator permission. Since a collaborator can have either read, write or admin access, I can add @mike to my repo as a collaborator with read access or more (he already can read the code, since my repo is public); then I can assign him for any issue/pr.

Summary:

• Private repos: anyone with explicit read/write access to that issue or pr.
• Public repos: anyone with explicit read/write .... oh, it's the same! 😁

I think it makes sense to assign people to issues even if they have no access to code. For example, to gather more information about the problem from a client. It's not the same for PRs, for which they should have at least read access to code (they might be in charge of fact checking, etc.).

Whether you are authorized to assign others to anything is a different matter, and it should be discussed separately. For starters, I think of the following scenarios:

• In public access sites, I can assign anyone to an issue/PR of mine to force him/her to get my SPAM; they wouldn't be able to unassign themselves.
• In an organization, the assignment action might be reserved to certain people only. This kind of granularity means extra work, so a simple set of checkboxes like "admins only/admins and writers" could be a good start.

[davidsvantesson]

So we could potentially have three options:

• write access
• read access
• public access

The last one could be limited to anyone previously contributing or otherwise interacting with the repo.
Regarding PRs, I don't know if it makes sense at all to have access to PRs but not code. But that should be up to the users. I don't think we shall complicate it here, if you have read or write access to PRs you can also be assigned.

If we increase the number of possible assignable I think we should also fix #6978.

[guillep2k]

We should keep in mind that if someone has no access to code, having access to a PR will expose parts or all of the code to them.

[davidsvantesson]

Yes, should make be a warning in the settings. But that is why I don't think we need to consider that case so much when it comes to assignable.

[andre161292]

Any progress on this one?

[a1012112796]

Hmm, It's really a problem. Please have a look again , Thanks.This issue is stale ... @guillep2k
In my opion, Assign means a special permission. that means user who is assigned can do all things for this issue or pr which author can do.
for problem about who can be assigned, I think all user with read permission can be assigned. may be can use same solution with #10756 or use contributors after we released this feature: #847

[guillep2k]

@a1012112796 It's more complicated than that. What if I assign a PR to @john, who is in the development team, but later @john gets removed from all teams. Should @john still be considered to have special permissions on the PR? Should he have access to code?

[j123b567]

@guillep2k there are two major and completely distict problems

• ability to assign somebody to the issue he can already see and comment (this seems trivial from my point of view), If he don't have access to the code, he also don't have acces to PRs so he can't be assigned to them.

• handle cases what to do if you change someons access rights or team membership - this is hard and needs to be discussed and defined and is probably long run, but anyway, it should be implemented despite the result of this issue - it should be completely different issue

We are doing the workaround, that we temporally add the tester to developers team, assign him the issue and remove him from developers tema. So he is assigned, but he don't see the code, which is what we want. But it went impractical so we leave him in developers group. Which is impractical for him, because he see more than he is interested.

[guillep2k]

I agree that we could allow specific users to be assigned to issues they would not be normally able to access. It's easier to implement, but it should be explicit (e.g. this user was specifically allowed to see "this issue"), so code that adds/removes permissions on a greater level doesn't remove them inadvertently. Again, PRs are a different beast (and IMHO make a little less of sense).

In the meantime, depending on your use case, maybe you could set up a separate repository for the issues alone. Your real developers can link PRs from the real repo to close issues on the proxy repo. That's supported.

[stevegt]

tl;dr: At the moment, without the ability to assign issues to non-collaborators, a typical group using gitea converges by trial and error toward a monorepo usage pattern, with everyone in the group having write access to the monorepo, bypassing most of gitea's permissioning system. Unless the repo owner knows to set up protected branches, everyone in the group winds up being able to push directly to any branch in the monorepo, bypassing PRs. With two years on this bug's clock now, I'd suggest we fix it in the simplest way that might possibly work: Let any user in gitea's database be assigned to an issue, with a config file boolean to enable the new code path.

In other words, I would consider this issue closed if we support this single use case:

• Carol assigns a public repo issue to Alice.
  • Allow Alice to be any user in the gitea database.
• Alice forks main/repo, creating alice/repo.
• Alice fixes the issue and pushes the change to alice/repo.
• Alice creates a PR in main/repo.
  • If the repo is public, Alice is already able to create this PR even if she is not a collaborator, right? My own testing seems to say yes. Am I missing something?

Without this one change, gitea makes a fork/PR workflow hard to encourage, because you can't assign bugs to people, so you can't encourage them to fork, so you can't encourage them to send you a PR.

I agree with @j123b567 that any other bugs this change creates, security or otherwise, need to be handled as separate gitea issues. I can live with Alice not being able to comment on the issue that's been assigned to her -- at worst that communications happens out-of-band. I can even live with Carol making the mistake of assigning a bug to Alice when Alice doesn't even have read access to the repo. Let fixing these things be separate issues and separate code changes, even if that means refactoring -- preventing regression during that refactoring is what drone is for.

In the meantime, we're already using workarounds that are far worse in terms of both security and workflow: In our own case locally, we first wound up putting all issues into a single general/issues repository that everyone has write access to, similar to what @guillep2k suggests; every time we add someone to gitea we have to remember to add them to that repo. More recently, in order to get the issues and code into the same repo again, we've begun migrating all of our code into general/issues, and we've renamed it general/core -- it's now our monorepo. We've wound up making everyone in gitea's database a collaborator with write access to a monorepo in order to get around this bug.

In our local case, I've given up on advocating branching or PRs completely at this point, and we're now just committing everything to master in the monorepo -- we instead have the release workflow deal with migrating from master to test and prod branches, and leave master a cesspool. Yes, this could be made better by making master a protected branch, and we may yet do that, but that wasn't obvious as things grew organically, and it's not going to be obvious to other new gitea owners either. The normal usage pattern for new gitea owners is to try to assign a bug, then horse things around until the desired assignee finally shows up in the dropdown list. This usually means opening permissions up more than they would otherwise feel comfortable doing.

[guillep2k]

@6543 is there a way of assigning a user to an issue via API? I couldn't find any.

AFAICT from browsing the code a little, the only thing preventing the assignment of a user with read-only access to the issue is that the assign box is search only; i.e. it doesn't allow the input of a specific user name, and the search results only include users with write permissions to prevent the list from becoming too big on public repos with thousands of registered users. I can't seem to find the specific PR ATM, but I recall reviewing one where this limitation was discussed. Otherwise the system should currently allow any user with read access to be assigned to an issue.

[mrsdizzie]

You can't normally let anybody with read access be assigned or else you can spam any random user with notifications. I create 1000 public issues with spam content, assign @guillep2k to all of them, send you 1000 emails, etc... (I know theres other ways to spam people too, but still)

The criteria Github uses is:

Up to 10 people, anyone who has commented on the issue or pull request, anyone with write permissions to the repository, and organization members with read permissions to the repository.

If the menu contained people meeting that criteria I'd think those will cover many cases and would be a good starting point.

[guillep2k]

@mrsdizzie Sigh, you're right. However on private instances (e.g. corporate) rules can be bended. Or maybe we could allow users to assign themselves? @stevegt what is exactly that assignment gives you in your case? Notifications? User <---> issue matching? ... ?

[mrsdizzie]

I think implementing the basic rules above before doing anything else will solve a majority of cases and can think on more edge cases after as it comes up. I suspect "any org member with read access" will cover most of those cases above. For anything more Gitea would need more fine grained 'role' type groups that don't really exist (yet)

[6543]

@guillep2k yes the EditIssue Api can change assignees

[stevegt]

tl;dr

@guillep2k We need to be able to use assignments to get people aimed in the right direction for what they need to work on, after which they use the normal github-style fork->fix->PR workflow. None of that should need write access to the master copy of a repo. Like most orgs using gitea, we have an internal gitea instance -- not public, so no spam risk. A config variable to enable read-only assignments would do the job.

Details and background:

We use oauth for logins into gitea. Everyone, once set up with oauth, has read-only access to all repos by default. We use multiple gitea orgs and multiple repos to categorize projects. In our case, the users are often interns -- less experienced, high turnover. Having to add and then later remove each intern as a member of each org/repo doesn't scale well.

We also try to train and encourage interns to contribute to open-source projects. But if we have to give them write access in order to get them to work on an internal project, then we're giving them an unrealistic experience relative to what they'll see as an open source contributor. We could use restricted branches to prevent pushing to master, but that's also not representative of fork->fix->PR. It would also have to be done on each repo, so again it doesn't scale.

[songmeo]

tl;dr

We need this feature to follow Github Fork and Pull Model - the assignees aren't necessary to have write access but rather fork the repository, make changes and create pull requests. From Github documentation:

This model is popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.

[6543]

Did #14262 close this issue too?

[PaulBol]

Did #14262 close this issue too?

Not as far as I can tell. For a public repository I can only assign a collaborator that has at least write permission. Collaborators with read permission do not show up in the "Assign users" list.

From the discussion so far my understanding is that there is no workaround at the moment. Please let me know if I missed it.