Cannot access sandbox

[mcking65]

In GitHub, I have tried revoking oauth and reauthorizing the app, and still can't access the sandbox.

I get the message:

You are not yet registered to participate! Let us know you want to help by opening an issue on GitHub.

[ccanash]

I will ask the team to review this @mcking65

[mcking65]

@ccanash
what is outlook for resolution?

[howard-e]

@mcking65 we've looked at the database attached to this environment and haven't found a reason as to why it won't allow your login to be reflected as an admin like it did before. Your user account and permissions are present, but I have 3 additional solutions to propose, with your help:

1. I've most recently added you to another GitHub team which is an point of development env access, so I'd request for you to revoke your Sandbox access and try logging in again by doing the following:

   • Navigate to https://github.com/settings/applications
   • Revoke ARIA-AT App Sandbox
   • Try to log in to the https://aria-at-app-sandbox.bocoup.com/, and check if you're now logged in as an admin.

2. Using the fake login instructions located at docs/local-development.md, namely:

   • Another way to log in as either a tester or admin, useful for quick testing and not requiring editing testers.txt or membership within any GitHub organizations or teams, is described below.
     • Sign out and return to the home page.
     • Add ?fakeRole=admin to the URL bar and press enter. Alternatively use ?fakeRole=tester to log in as a tester only or ?fakeRole= to preview logging in without a role.
     • Follow the sign in steps as normal.
     • After signing in, your selected role will be used for the duration of your session.
     • This functionality is available in development environments where the ALLOW_FAKE_ROLE environment variable is "true".

3. If all else fails, mirroring what's on sandbox to the staging environment when cases like this arise for your convenience may be okay. What's on sandbox will eventually be moved to the staging environment either way. Currently, what's on staging, of note is the following:

   • Application incorrectly marking results as conflicts #651
   • Add Test Plans to the Test Queue: Plan version dropdown shows commits that do not include a change in the chosen test plan #579
   • Sandbox includes additional changes related to issue 648 (and all other updates)

[mcking65]

@howard-e

After method 1, I still get the same message:

You are not yet registered to participate! Let us know you want to help by opening an issue on GitHub.

Note that when I execute the sign in link the first time, I get the authorization prompt. After I authorize, I get the above message and the sign in link still appears in the nav bar. I tried reloading and refreshing cache, and then executing the sign in link again. The screen just reloads. Normally after sign in, I expect to see a sign out link in place of the sign in link. Executing sign in is apparently not signing me in.

Using method 2, I loaded the url:
https://aria-at-app-sandbox.bocoup.com/?fakeRole=admin

Then I activated the sign in link, which loaded the page:
https://aria-at-app-sandbox.bocoup.com/signup-instructions

This is the page with the above message saying I am not registered to participate.

I navigated to other pages, and I still do not have any admin functions and cannot reach the candidate tests page.

I have tried both methods in Chrome and Firefox on Windows and in Chrome on my macbook.

I suppose you could push to staging. That is going to add overhead and limit how quickly I can provide feedback.

This is confusing because I have previously been able to access the sandbox.

[ccanash]

HI @mcking65 while we work on a solution we will continue to update staging so that you can check PRs

[mcking65]

thank you, thank you!!

[mcking65]

I verified this morning that James can access the sandbox. This is apparently account related. I could raise an issue with GitHub, but it seems like I would need more information ... some kind of log of what is happening. Does anyone know how to get that?

[howard-e]

@mcking65 following up on this thread with possible solutions.

I went ahead with mocking several users and their auth and found that you're no longer a part of a required Bocoup-related team for sandbox admin access, which I imagine may have been an organizational move. I'm not an admin of that team so I can't add you to verify that thought, and I also can't confirm if you were a part of that team (but you had to be, given you previously confirmed having access, and with how the environment variables are used in that auth flow)

Additional thoughts based on that:

• It now makes sense on why you were redirected to the /signup-instructions screen as well, because you're not a part of the testers.txt so no role could be applied for you to login and use the fakeRole instructions.
• aria-at-app-staging team controls the admin staging access and James had previously noted through email, that Isa couldn't access staging as an admin (because she isn't included in that team, but James is). Isa could login on sandbox (because they're included in testers.txt) and use the fakeRole functionality to become an admin so this is clearer to me now.

Some possible solutions for this issue:

1. A newly created, separate team for sandbox access and ensure relevant maintainers are assigned and can update those users (as well as staging and the admin team)
2. Make sure all possible admins are a part of testers.txt (even though the comment in the file suggests otherwise) so that they'll always be able to log in and direct them to the fakeRole instructions when wanting elevated sandbox permissions.
3. Doing away with the GitHub team-checking logic. The app's method of authorization is somewhat "bloated", with general access coming through public txts. That's then compounded with separate access being controlled in GitHub teams. Is there an argument here to explicitly define admins in an admins.txt file, just like testers and vendors? That would make it easier to have consistent access permissions across the environments, as well as still being able to do overrides on the sandbox environment.

Following internal discussion, point 3 is our preference. Is there any privacy reasons or otherwise why we shouldn't make this change?

[mcking65]

Hurray, since I responded to the invite to the bocoup org, I can now access sandbox!

Per our discussion during our meeting last week, the decision to use github teams was in part to re-use the github UI for managing permissions. We need UI that enables us to manage permissions that take effect immediately. The current situation where we have to go through the back-end to update a txt file is not sustainable.

[ccanash]

Hi @mcking65 , what would be the priority for us to work on a UI to manage permissions? I have created #856