Skip to content
This repository has been archived by the owner on Sep 18, 2024. It is now read-only.

Permissions issues #34

Closed
ericsoco opened this issue Sep 19, 2016 · 6 comments
Closed

Permissions issues #34

ericsoco opened this issue Sep 19, 2016 · 6 comments
Assignees

Comments

@ericsoco
Copy link
Contributor

The intended permissions are as follows:

  1. Any member of open-redist can create a new project.
  2. Anyone can create a new proposal.

However, I ran into some last-minute permissions issues trying to make these things possible:

  1. It's not enough for a user to be a member of open-redist; the member must publicize his/her membership via open-redist's people page.

I ran into problems with the endpoint for checking all members (whether public or not) 302 redirecting and breaking the preflight request; instead, we use the endpoint for public members and therefore require public membership to create a project.

I'm not sure how to fix this problem; I expected the all-members API request to work, especially if the requester is a member of the org. But it does not.

  1. In order to create a proposal, a user must be an owner of open-redist. I believe this is due to the flow used to create a proposal:
  • first, a branch is created on the repo;
  • then, the PR is issued from that.

If the user is not an org owner / repo admin, the user has no rights to create a branch directly on the project repo; instead, a pull request (proposal) can only be made from a fork. The fix to this is most likely to programmatically (via the API) create a fork and issue the PR from that, instead of creating a branch directly on the repo.

@waldoj
Copy link

waldoj commented Sep 20, 2016

Uuuugggghhhhhhh. Somebody needing to be a contributor to the repo in order to make a pull request is grim. That's a bar for participation that's so high as to rule out nearly anybody from outside the organization from being able to make proposals.

What is the reason that we can't do anything with pull requests from an individual's GitHub account? I'm afraid I don't follow that.

@ericsoco
Copy link
Contributor Author

We can do that. I just have to rewrite the proposal creation flow to do so.
Will make it a priority.

Sorry this didn't come up sooner -- I've been testing mostly as an open-redist member and the API flows can be byzantine when you factor in Git, GitHub, and OAuth scopes. There are many paths to each of the features here, and I chose the wrong one apparently >.<

@ericsoco
Copy link
Contributor Author

I should amend the previous comment to say "I think we can do that."

My primary concern is around revisions to proposals. Not sure how that will work across repos. Have to figure it out.

@ericsoco
Copy link
Contributor Author

Ok, the particularly egregious problem (no. 2 above) is now fixed -- proposals happen via a fork on the viewer's GH account. I think the requirement that a user be a public member of open-redist in order to create a project is ok, but @waldoj I'd like to hear your thoughts.

@waldoj
Copy link

waldoj commented Sep 21, 2016

I think it's just fine. Better than fine—I think it's preferable. Let's call this a feature, not a bug. :)

@ericsoco
Copy link
Contributor Author

Feature implemented! ✔️

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants