Allow org admins to create guest users #1373
Conversation
C# Unit Tests104 tests +1 104 ✅ +1 5s ⏱️ ±0s Results for commit 4001568. ± Comparison against base commit a8d082f. This pull request removes 1 and adds 2 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
|
@rmunn I just pushed this. What do you think?
I'd be inclined to always (i.e. it's not optional) add new users to the org, because:
If the admin desperately doesn't want them to be in the org, they can remove them after. |
|
@myieye - Looks good. I fixed a lint error and a compiler error, and increased the contrast (the text-success color wasn't standing out well on a light background, see below) but otherwise I like that idea. Before the change, light BG:
After the change, light BG:
|
|
Ran out of time tonight to add the guest user to the org automatically; will add that code tomorrow morning. Then this will be ready for re-review. |
| if (!await CanCreateGuestUserInProject(projectId)) throw new UnauthorizedAccessException(); | ||
| } | ||
|
|
||
| public bool CanCreateGuestUserInAnyProject() |
There was a problem hiding this comment.
I don't quite understand these method names. "AnyProject" sounds more powerful than "InProject", but to have the "AnyProject" permission you just have to be a manager in any org, whereas in "InProject" check requires you to be a manager in a specific org. Perhaps "AnyProject" should require you to be a system admin?
| </ul> | ||
| </Dropdown> | ||
| </div> | ||
| <CreateUserModal handleSubmit={createGuestUserByAdmin} on:submitted={(e) => onUserCreated(e.detail)} bind:this={createUserModal}/> |
There was a problem hiding this comment.
Presumably, we can write a function around createGuestUserByAdmin to add the org to the payload.
| LoggedInContext loggedInContext, | ||
| CreateGuestUserByAdminInput input, | ||
| LexBoxDbContext dbContext, | ||
| IEmailService emailService | ||
| ) | ||
| { | ||
| using var createGuestUserActivity = LexBoxActivitySource.Get().StartActivity("CreateGuestUser"); | ||
| permissionService.AssertCanCreateGuestUserInAnyProject(); |
There was a problem hiding this comment.
Assuming we
- change the "AnyProject" check to restrict it to system admins
- Extend this mutation to accept an org ID to add the new user to (which I think makes sense)
Then...
If org-ID is specificed we need to make sure the current user is a manager of that org.
Fixes #1268.
This adds the same "Create User" button, with the same dialog, to the org page that is on the admin dashboard, if the currently logged-in user has the right to manage the org (i.e., is an org admin).
It goes to the same "Create User" dialog as the one on the admin page (not screenshotted because this PR makes no changes to it), and has the same effect (if no email provided, creates guest user with "CreatedById" set to the org admin).
One possible improvement, which I have not yet made, would be that if an org admin creates a guest user, that user is automatically added to the currently-viewed org. (With, perhaps, a checkbox to turn that off, in the rare case where an org admin might be wanting to add a guest user NOT associated with any org — but the default should be on).
@myieye - Your thoughts on UI would be welcome. For example, should we change the name of this button when it's on the org page? I feel like having "Add Member", "Bulk Add Members", and "Create User" buttons all one after the other end up being a little much and has the potential for user confusion. But as I'm writing this, it's kind of late in the day and I'm having trouble thinking of what the alternative might be. I'll probably have better ideas tomorrow morning, though.