stamen / open-redistricting

A collaborative, open legislative redistricting tool, built atop GitHub.
http://openredist.org/
BSD 2-Clause "Simplified" License
25 stars 2 forks source link

Permissions issues #34

Closed ericsoco closed 8 years ago

ericsoco commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

ericsoco commented 8 years ago

Feature implemented! ✔️