fix: lowered user permissions on registration

[gentlementlegen]

Resolves #41
Resolves #47

[ubiquity-os-deployer]

4f62109

db6c470

32b1add

b4f9847

fed9bac

[gentlementlegen]

This is a proposal to fix the permissions requested for newcomers, as requesting full access on public / private repos seems excessive and scary for new users.

It's a bit complicated to solve, since knowing the data related to a user requires that user to be logged in, where scopes have already been requested. So here is a draft proposal on how to handle it:

1. A new user logs in for the first time at work.ubq.fi and gets requested the following

Everything is read-only, and the Org will help us later on determine if that user if part of Ubiquity's Org.

2. We check post login if that user is part of Ubiquity's team. If so, we display a "lock" button next to the user name, like so

When clicked, we get redirected to the GitHub OAuth permission page requesting higher privileges

If allowed, the "lock" button is gone.

If that workflow is satisfactory, I can spend some time on the CSS to make it look better.

[0x4007]

I think it's a great proposal thanks for figuring this out. I am unsure that a lock is the best icon but until I have time to look through icon libraries I am unsure which is better.

Try using Google material design icons I normally stick with those for all of our UIs.

[0x4007]

I think you should also set a time estimate.

[0x4007]

Oh I just realized this is a pull sorry!

[gentlementlegen]

@0x4007 Thanks for the feedback. Seems that Ubiquibot still doesn't like me: #41 (comment)

For the lock icon I actually pulled it out from Material UI icons. Maybe an opened lock would make more sense anyway.
By CSS issue I was referring that the placement of the button is inappropriate right now as it takes too much left and right space with the user name.

[gentlementlegen]

Current looks of the button in the navbar:

[gitcoindev]

Looks good! I also reviewed from my side.

[0x4007]

Resolves #41

Resolves #47

We discourage multiple associated issues in a single pull.

This is so that we can audit changes (git blame) more efficiently if problems are discovered later.

In the future I would branch off and open two pulls separately. This can be done retroactively after all the code is complete as long as you use the git "cherry pick" feature @gentlementlegen

[gentlementlegen]

@0x4007 Yep makes sense, very accidentally fixed two by doing this one. Thought it would not make much sense to have another PR with the same exact code as this one, will keep this in mind and open two different PRs next time.