Skip to content
This repository has been archived by the owner on May 19, 2020. It is now read-only.

Adjust copy explaining org users #1200

Merged
merged 2 commits into from Aug 23, 2017
Merged

Conversation

el-mapache
Copy link
Contributor

@el-mapache el-mapache commented Aug 23, 2017

  • Let managers know that users with no roles continue to exist in the
    organization

screen shot 2017-08-23 at 10 11 31 am

* Let managers know that users with no roles continue to exist in the
organization
@el-mapache
Copy link
Contributor Author

Is this copy approaching what we want? The section is already a bit wordy and I'm hesitant to add multiple paragraphs explaining the difference in command-line generated user lists and the one visible on the dashboard.

@femmebot
Copy link
Contributor

@suprenant (or someone who has a better understanding of the product than I do) explain to me why users with no roles remain listed — including former employees? Seems like we need to provide the rationale (succinctly!) rather than defend why the UI behaves in a way that contradicts user expectations. Also, shouldn't the message (and the list) only be displayed to those who have the appropriate roles/permissions to add/assign/remove?

@suprenant
Copy link
Contributor

@el-mapache I think this is close, and – yeah – we don't want it to be too wordy. What do you think of this?

Organization Managers can change these roles. For details about these roles, see Cloud Foundry roles and permissions. For more information about inviting users and assigning roles, see Managing Teammates. Removing all roles does not remove a user from an organization. Users with no roles will remain in the organization until you remove them, but they will be unable to perform any actions.

@suprenant
Copy link
Contributor

@femmebot I believe there's a compliance reason that we don't automatically delete users even if they have no roles, and users do inherit an org role if they are added to a space within that org. I believe the above will alleviate at least some of the confusion we're seeing so suggest we move forward with this fix and adjust again later if we're still hearing customers ask about this.

Only displaying the list to users with appropriate roles/permissions to add/assign/remove could be a separate story. I'll look into whether we've considered this before and will write a new story if we haven't.

@el-mapache
Copy link
Contributor Author

el-mapache commented Aug 23, 2017

@femmebot It seems like a conscious choice to display the list even if you aren't an org manager, maybe because anyone can view the list of users via the command line?

Non-managers can't edit anything in the user list and also see less of an explanation, do we just hide all the documentation in the case of a non-manager viewing the page?

@femmebot
Copy link
Contributor

@el-mapache @suprenant i think this is what i'm trying to uncover. We may not have sufficiently probed into the root cause of the confusion. instead, we simply expect users to accept our UI decision without really explaining why that is.

@suprenant
Copy link
Contributor

@femmebot you may be right. Let's move forward with this implementation for now so we can work on other stories – we can always revisit and make further refinements later.

@el-mapache
Copy link
Contributor Author

@femmebot Based on the docs linked in the ticket, the root of the confusion seems to stem from the two different user enumeration commands that the CLI provides. I still think a decent solution might involve some kind of flagging or separation of users with no roles, although I'm not sure what that looks like.

Do you all feel like this is good enough to try out and see if confusion is reduced at all?

@femmebot
Copy link
Contributor

femmebot commented Aug 23, 2017

+1 for some kind of flagging or separation of users with no roles

really, the list is unmanageably long as is

@suprenant
Copy link
Contributor

Some separation/flagging is a nice idea. @el-mapache @femmebot okay, if you want to take one more day and see where that can get us, let's do it.

@el-mapache
Copy link
Contributor Author

@suprenant I don't know if another day is necessarily going to produce a solution that is any better than the one outlined in the ticket. I think this ticket can be closed, and a new one can be opened to focus on figuring out what the root of this problem is and how we can best address it.

@suprenant
Copy link
Contributor

@el-mapache OK, let's call this one done, then, and I'll flag the above as possible follow up work for another time.

@suprenant suprenant merged commit db51d3b into master Aug 23, 2017
@suprenant suprenant deleted the ab-org-user-management-copy branch August 23, 2017 17:06
@brittag
Copy link
Contributor

brittag commented Aug 23, 2017

The root problem is that Cloud Foundry itself behaves in an unexpected way - it doesn't remove users from the org when you remove all their roles. See the discussions linked from the bottom of this doc, including cloudfoundry/cli#781 and this discussion in #cf-docs in the Cloud Foundry Slack.

@brittag
Copy link
Contributor

brittag commented Aug 23, 2017

Also people with org user status but no org roles or space roles can still run the commands cf org-users -a [org] and cf org-users [org] and see results...

@el-mapache
Copy link
Contributor Author

@brittag I actually wouldn't expect that behavior. I would expect a user is only going to be removed when I explicitly delete their record. For example, I might create a user in the organization but only intend to give them space roles.

@el-mapache
Copy link
Contributor Author

@brittag Yes, but having an account with cloud.gov isn't the same as belonging to an organization. You can be a member of cloud.gov and belong to no organizations, and read all the same information, correct?

@brittag
Copy link
Contributor

brittag commented Aug 23, 2017

@el-mapache If you have a cloud.gov account but no "org user" status on any orgs, you can't see any results from running cf org-users -a [org] and cf org-users [org] - you just get "Organization [org] not found"

@el-mapache
Copy link
Contributor Author

Ok, that makes sense. I think I misread your above comment. I still don't consider it a fault of the API if users don't understand that roles and associations are things that a user has, rather than the actual user.

@brittag
Copy link
Contributor

brittag commented Aug 23, 2017

Users don't expect that an "org user" remains after you remove their org roles because the CF user-facing docs page about roles/permissions doesn't document the existence of "org user" status (how it gets created, what it can do, how you remove it, etc.), and if you use the CF CLI default command of cf org-users [org], you don't see "org users", just people with org roles. I'd love to get this fixed in the CF docs and CF CLI but that's a bigger project.

@femmebot
Copy link
Contributor

@brittag so it's not a compliance issue (see #1200 (comment)) but, rather, a cloud foundry idiosyncrasy shall we say? Just trying to understand the problem space and constraints.

@brittag
Copy link
Contributor

brittag commented Aug 23, 2017

Correct, no compliance requirements causing this behavior.

@brittag
Copy link
Contributor

brittag commented Aug 23, 2017

Filed a related PR just in case it helps: cloudfoundry/docs-cloudfoundry-concepts#75

@femmebot
Copy link
Contributor

@suprenant I think what I'm trying to get at is if, in the process of trying to address an issue for Org Managers, we have not been aware that it creates a problem for a larger set of users (non-Org managers) by exposing what appears like irrelevant info.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants