Org page improvements

[rmunn]

Fixes #881.

• Org page now shows "Leave org" button only to members
• Org page now shows Settings tab only to members or site admins
• Members list on org page hides email/username column if you're not an org admin (or site admin)
• Members list on org page only shows org admins if a non-member is viewing it
• Projects list on org page only shows public projects, or projects you yourself are a member of
  • This rule applies to both members and non-members equally
• Org admins can still see all projects (and site admins too)
• Org admins can click on any org member to see all his details
  • Works like admin dashboard, but restricted to only viewing org members

Screenshots:

Org page members list as seen by non-member (shows only org admins):

Org page members list as seen by org admin (shows all members, but not emails since only site admins can see emails):

Org page members list as seen by site admin (shows emails, also shows all members even though site admin isn't an org member):

[github-actions]

UI unit Tests

11 tests  ±0   11 ✅ ±0   0s ⏱️ ±0s
 3 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit b62400f. ± Comparison against base commit baaa496.

♻️ This comment has been updated with latest results.

[github-actions]

C# Unit Tests

52 tests   52 ✅  5s ⏱️
10 suites   0 💤
 1 files     0 ❌

Results for commit b62400f.

♻️ This comment has been updated with latest results.

[myieye]

There's a lot of tricky stuff in here. Keep it up! 👍

[myieye]

I don't have time to think this through right now, but...I think we likely have a problem here.

The project refresh middleware works by assuming that a user will only query projects that it is a member of.
If there's a mismatch between the JWT and the project being queried, then we refresh.

I'm only just realizing this, so I haven't analyzed wether you've considered this or not, but...I'm guessing the logic's not quite right.
We'll presumably also need to adapt quite a bit for public projects.

I'm guessing the Exception you got was, because your code refreshes the JWT much more often than desired.

[rmunn]

@myieye - Commit ae4c382 has the frontend code we discussed at the meeting, which I'm struggling to get the right Typescript types for.

[rmunn]

I don't have time to think this through right now, but...I think we likely have a problem here.

The project refresh middleware works by assuming that a user will only query projects that it is a member of. If there's a mismatch between the JWT and the project being queried, then we refresh.

Right: this might cause refreshes more often than needed. But it limits itself to one refresh per query, at least. Still, that's more work than truly needed, you're right. I don't have time to rethink this today, though.

[myieye]

@rmunn I got the GQL query working in 084cca1. I just live off of copy/paste 😆

[rmunn]

Rebasing on top of new develop now that #865 has been merged.

Dismissing Tim's review as he's away for three months; will request re-review from Kevin.

[hahn-kev]

@rmunn I've made some changes to how we're returning orgs for permission issues. When querying the org list (default handling) only admins can query projects and members.
The orgById query has special handling so it can return more data, and the expectation is that the data will be filtered in the method based on user permissions, that is still todo for the PR. Keep in mind that the user may not query members or projects, so be sure to handle that case.

Also per Tim's comment, we need to rework the logic of the refresh jwt code as a query returning an org does not mean the user should now have access to it, the way it's setup now I think it'll refresh any time a user visits the org list page.

[rmunn]

The new OrgPermissionTests all pass now. But look at commit 19eabe4, which is a deliberate bug. That change should have caused a test to fail, but it didn't. In order to make this change fail, we'll need a third project in our seeding data, one that is confidential but that the "editor" user is not a member of. Then that test will fail until commit 19eabe4 is reverted, thereby proving that the tests can catch the bug I deliberately introduced in 19eabe4.

[rmunn]

For the third project, it would be useful for it to be an empty project. I suggest we zip up the backend/LexBoxApi/Services/HgEmptyRepo/ directory and put it on Google Drive, then download it the same way we download sena-3.zip and elawa.zip. We would also need to modify deployment/init-repos/hg-deployment-patch.yaml to create the directory for the empty project, and the Taskfile.yml file as well.

Actually, I'm starting to think that this should be tracked as its own issue.

[rmunn]

After #900 was merged, there was (as expected) a merge conflict in Taskfile.yml, so I rebased on top of the new state of develop to fix the conflict.

[rmunn]

Currently I'm seeing a single unit test failure on my machine (as opposed to the three failing tests in the GHA workflow checks): Testing.ApiTests.AuthTests.CanUseBearerAuth fails with a 401 Unauthorized error. The logs show the following:

LexBoxApi.Auth.Requirements.AudienceRequirementHandler[0]
Token does not have the required audience: [(null)] not in LexboxApi
Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2]
Authorization failed. Fail() was explicitly called.
OpenIddict.Validation.OpenIddictValidationDispatcher[0]
The response was successfully returned as a challenge response: {
  "error": "invalid_token",
  "error_description": "The signing key associated to the specified token was not found.",
  "error_uri": "https://documentation.openiddict.com/errors/ID2090"
}.

Parsing the jwt that the test is handling shows "aud": "LexboxApi" in the JWT, so I don't kow why the audience is null by the time it's reaching the AudienceRequirementHandler.

However, the same failure occurs when I run the tests on develop, so this failure is unconnected to this PR. (Which doesn't touch anything related to signing keys for JWT or token audiences, so it would have surprised me if the PR was actually causing the test failure).

[rmunn]

Adding a third test project exposed a bug: if the org manager hovers over a confidential project that he's not a member of, then the GraphQL query for the project page will fail and it will show an error popup. After discussing this with @hahn-kev we decided that we're going to edit the project page query permissions to allow org admins to view projects owned by their org, at which point the error popup will no longer show. So we'll leave this bug in place for now, as we're going to fix it soon in a separate PR.

@hahn-kev, I believe this is ready for a final review now.

[rmunn]

... if the org manager hovers over a confidential project that he's not a member of, then the GraphQL query for the project page will fail ...

This is now tracked in #915, which I will work on next.

[hahn-kev]

I requested a change which actually ends up simplifying some of the code.

[hahn-kev]

looks good to me. There's still an unresolved conversation that requires a change. There's also some failing tests so you should look into those too, they're working on develop, so I'm not sure why they're failing here.