Instead of using open registration, can you invite users instead and immediately add them to spaces so this doesn't happen? Why are you allowing open registration if all registration must be coordinated with an administrator anyway?

This sounds like the expected result to me. Even if they did get verified, they would immediately hit the same "No Access" dialog again.

Why should verifying email address depend on any space view policy?

@epriestley Inviting users could be a good idea, but I want allow "Project administrators" group to do that.

I saw "Can Create (non-bot) Users" policy in People application and thought this would be a good solution, but it seems that policy has no effect or I don't understand how it works. Even if I set "All Users" for that policy, only Administrators have "Create New User" link and User administration section in left sidebar. What am I doing wrong here?

@chad For me that's not expected result. They should be verified no matter access policy or some error message displayed. "No Access" dialog is expected and that's okay.

"Can Create (Non-Bot) Users" is a fake permission for Phacility SAAS disguised as a real permission. You must always have that permission and be an administrator to create users: that is, it can only be used to reduce the set of administrators who have permission to create users. In the Phacility SAAS cluster, we set this permission to "No One".

Can you just make all "Project Administrators" into real administrators? What's the technical reason that "Project Administrators" and "Real Administrators" are distinct groups, if you want "Project Administrators" to be able to invite users?

Oh, I see...so, no luck there...but this would be a great option if it worked the way I initially understood.

I don't want to make all "Project Administrators" into real administrators because they generally aren't technical stuff and are easily confused with various administrative options. I am pretty sure they would go exploring and change some policy or something else.

Is it just possible to fix this email verfication bug so everything works as expected or you don't think this is a bug?

Is it possible to disable email verification or force verify email validation for current users? I really see no other option...

I don't really consider this behavior a bug, because this (users registering into zero spaces) isn't really a supported workflow. The menu rendering is less ambiguously a bug, but I'd likely fix it by just hiding the menu in this state, and that won't address your issue. And it doesn't cause any problems unless you get into this questionable state in the first place, so cleaning it up is difficult to prioritize.

Your workflow looks like this, right?

• Users register, but can't do anything with their accounts.
• Separately, users email a project administrator to get access (they know to do this via some out-of-band channel?).
• The project administrator grants them access to projects or directly to spaces.
• The project administrator emails them back to let them know they can continue.

This isn't a workflow we want to support in a first-class way because it's pretty clumsy. A version of this workflow we'd be more open to supporting might look more like this, per above:

• Project administrators invite users and add them to the right spaces/projects at the same time, so things are already set up by the time they log in.

This is better for users and for administrators (fewer steps for everyone), and doesn't put users into the "no access to spaces" state. Some changes we might consider to support this workflow:

• Provide a real "Can Create Users" permission or a narrower "Can Invite Users" permission.
• Allow you to immediately add new accounts to projects during the invite/create workflows.
• Allow you to lock or restrict workflows you have material concerns about (like application policy/config).
• If the text on the "no access to spaces" dialog made you think that this is a supported workflow which we expect users to encounter during registration, we could consider changing it to make it more clear that this state is an error state.

But these are difficult to prioritize because they would essentially impact only one install (yours) today.

Another supportable workflow might be:

• When users log in for the first time, they get access to into a common/sandbox space which doesn't have anything interesting, but allows them to set up their accounts and guides them toward requesting greater access.

I'm not sure what the technical barriers to implementing this workflow are in your environment.

Is it possible to disable email verification

No, and I don't plan to provide any options to do this, at least not without first seeing stronger use cases impacting a wider range of installs and workflows.

force verify email validation for current users

• You can force-verify an email with bin/auth verify <email>
• If a user clicks an email invite link to register, their email is automatically verified.
• If a user registers with an OAuth provider that has the "Trust Email Addresses" flag checked, their email is automatically verified.

I am pretty sure they would go exploring and change some policy or something else.

What specific policy changes are you concerned that they'll make? The only policy changes that administrators naturally get access to that non-administrators don't have are are application policies. Just like normal users, administrators are still bound by policy controls, and can not edit anything they couldn't otherwise edit as normal users, unless the policy for editing it is "Administrators".

Administrators also get access to Config, but they normally can't do much damage there since all the major stuff is locked to the CLI anyway.

In T12421#216121, @epriestley wrote:

Your workflow looks like this, right?

• Users register, but can't do anything with their accounts.
• Separately, users email a project administrator to get access (they know to do this via some out-of-band channel?).
• The project administrator grants them access to projects or directly to spaces.
• The project administrator emails them back to let them know they can continue.

Yes, more or less, something like this.

A version of this workflow we'd be more open to supporting might look more like this, per above:

• Project administrators invite users and add them to the right spaces/projects at the same time, so things are already set up by the time they log in.

This is better for users and for administrators (fewer steps for everyone), and doesn't put users into the "no access to spaces" state. Some changes we might consider to support this workflow:

• Provide a real "Can Create Users" permission or a narrower "Can Invite Users" permission.
• Allow you to immediately add new accounts to projects during the invite/create workflows.
• Allow you to lock or restrict workflows you have material concerns about (like application policy/config).
• If the text on the "no access to spaces" dialog made you think that this is a supported workflow which we expect users to encounter during registration, we could consider changing it to make it more clear that this state is an error state.

But these are difficult to prioritize because they would essentially impact only one install (yours) today.

This might be acceptable, especially with, as you say real "Can Create Users" permission or a narrower "Can Invite Users" permission. This is something I would really like to see because it would solve all my problems at once and simplify workflow dramatically, and I wouldn't have to give Admin rights to random users just to invite other users.

Another supportable workflow might be:

• When users log in for the first time, they get access to into a common/sandbox space which doesn't have anything interesting, but allows them to set up their accounts and guides them toward requesting greater access.

I'm not sure what the technical barriers to implementing this workflow are in your environment.

I think this approach would confuse new users because they would try to start doing something right away and I would need to explain them to wait until we put them in appropriate space.

I really like the idea putting them in space during / right after user creation.

---

Is it possible to disable email verification

No, and I don't plan to provide any options to do this, at least not without first seeing stronger use cases impacting a wider range of installs and workflows.

force verify email validation for current users

• You can force-verify an email with bin/auth verify <email>
• If a user clicks an email invite link to register, their email is automatically verified.
• If a user registers with an OAuth provider that has the "Trust Email Addresses" flag checked, their email is automatically verified.

Thanks, but where can I see user email addresses? After users are approved, there is no email address displayed anywhere. I feel this should be in the user list (in the People app). I tried bin/accountadmin, bin/people and conduit but without success...

Just noticed one more quirky thing about users with no view policy for any space. They can't log out and they get one more "No Access to Spaces" message in the modal. Just like email verification, I don't understand why log out should depend on space view policy.