Issue #6552 resolved

Team membership notifications are in conflict with members tab on profile page (BB-7755)

csbubbles
created an issue

I was playing with group settings for a team account, and faced a weird issue. I disabled "can create repositories in this account" checkbox for the Developers group, and all members of that group received the notification "User1 revoked User2 's access to TeamX" over email. The same messages for each group member I can see in my NewsFeed. Though no one actually lost their access.

Comments (23)

  1. Erik van Zijst staff

    The way team privileges are implemented in Bitbucket are such that the two checkboxes ("can administer account" and "can create repos") define the level of access the users in that group have on the team.

    When you deselect both checkboxes, you essentially revoke all access for its members, even if the group is not empty.

    Now you say that the users who received that email did not actually lose access to the team. Can you verify that by having one of these users load up their dashboard and check whether "TeamX" is listed on the right (and whether they can access any of its private repos)?

  2. csbubbles reporter

    Not only those checkboxes define access rules. I am attaching the screenshot of that group management dialog. "Developers have write access to this account's repositories." But they "cannot administer this account" and "cannot create repositories in this account". They can see themselves in that team group, and they can commit to that team's repositories. And this is expected behaviour - they can work with repositories, but cannot administer the team account and create new repositories. The unexpected behaviour is the notification sent to them that their access was revoked, as it is wrong actually.

  3. Erik van Zijst staff

    I should be a little more precise:

    With none of this boxes checked, it members still have the specified access to the team's private repositories, but since this is indistinguishable from any other non-team member that is given direct access to a repo through the repo's own admin screen, we don't count these members as collaborators on the team. They're just "repo collaborators" if that makes any sense.

  4. Erik van Zijst staff

    I guess it's a matter of definition. I can see how you would regard the members of a group as team members and our implementation is slightly different.

    Internally we track "repo access" and "team access" separately. The dropdown (repo access) and checkboxes (team access) on the team groups control both and you can effectively enable/disable each independently.

    When you turn off everything (no repo access and no checkboxes checked), you'll understand that the group members have absolutely no access to anything and their privileges on the team (or rather lack thereof) is equal to that of any other random user on Bitbucket. Under these circumstances we do not count these members towards your plan limit.

  5. csbubbles reporter

    I understand this approach, but please look from the user perspective.

    There is a team and also some projects created under that team account. There are a couple of guys in the team. All those guys received the notification that they were revoked from the team. All of them have read it as "you cannot work with the team projects" any more.

    Also, that group "Developers" is bound to that team account, and people were not removed from there. You can see them even on your screenshot, people are still in the team's group. They have other rights now to manage the team account (no rights in this case), that's right, but they are still in the team (because they are still part of a group created for a team account).

  6. Erik van Zijst staff

    Yes, I'm sympathetic to your position. I'm just explaining why it works the way it works.

    The thing is that when you consider members of powerless teams to count as full blown team members, you would also expect them to show up under "Plans and billing" in the team admin page and that in turn would mean that you have these count towards your plan limit.

    It would say e.g. 12/10 users, meaning you're over your limit and your account would be locked down, while that group of yours contains 5 users that don't have any access at all. So in reality you only have 7 active collaborators.

    We found it important to not unnecessarily count users towards your plan, so you don't need to upgrade while you're technically not using all the collaborators your plan allows.

    One consequence of this is that such users are notified that they no longer have any access to the team when you revoke all of a group's privileges. I understand that that is scary, but technically that is exactly what happened. These users have no way to access any of the team's repos anymore.

    In your case, your group still has write access on all the repos. However, if your team doesn't (yet) have any repos, these users effectively have no privileges at all, just like in the scenario where all privileges were revoked. So again, you don't get "charged" for them and we don't count them as active collaborators.

  7. csbubbles reporter

    Those guys are still in the "Billing" stuff. It doesn't matter what access rights they have while they are in a team group. And actually that what I personally expect, and how it is working now. So, those guys are still considered "team members" even in your system internally. Please see the attachment...

    My initial point was that everything is fine, but you have a bug with notification. No one expects to get notified about "revoking from the team" when that didn't happen in actual fact.

  8. Erik van Zijst staff

    If those guys are still listed on the billings page, then that means that they have access to one of more repos on your team. If your team does not have any repos, you will see that those users will no longer show up in that list.

    Similar to when you have a privilege-free group that has users in them. Unless those users are also members of other groups (or have been given direct access to one or more of your repos through the individual repo admin pages), those users will not show up under plans and billing:

  9. csbubbles reporter

    So again, if those users are still on that team account, why did they get a message that they are not anymore? I am talking only about the first case, where they do have "write" access.

    They: 1. have a write access to team's all repositories as they are in the team group 2. are listed in the team group 3. appear as users on the team account 4. are showed up in the team members list

  10. Erik van Zijst staff

    No one expects to get notified about "revoking from the team" when that didn't happen in actual fact.

    I was going to say that it's really a matter of definition. Of whether or not you consider a user that has no team-specific powers a team member, however:

    Our permissions layer only considers users that have some form of team privileges (being able to create a repo, or even administer the entire account) to be team members and this extends to the notifications.

    The plans and billing page works slightly differently in that it only cares about users that actually count towards your plan (meaning they have access to at least 1 private repo -- "team member" or not).

    I have to admit that this is somewhat inconsistent.

    Unfortunately, there are more inconsistencies. The "members" tab of a team profile page considers everyone in all groups to be a team member, if those whose groups give them no access whatsoever.

    The latter, you are right, is certainly in conflict with the backend and the notification system.

    I've raised an internal issue to reconsider the situation. Specifically to see if we can come up with a solution in which everything is consistent.

  11. Erik van Zijst staff

    So again, if those users are still on that team account, why did they get a message that they are not anymore?

    For posterity: the permissions system only considers people that have some form of team access to be a member. Team privileges are:

    • ability to create repos under the team
    • ability to administer the account

    The ability to access a repo does not give a user any team-specific abilities. Any user can be given write access to a repo, without being a group member.

    So: if a team member is exclusively defined by being in a group that has at least 1 of its checkboxes checked (which is the definition followed by the backend and notifications), then your users actually did lose their membership.

    Where things get messy is that our members tab on the profile page has a different definition.

  12. csbubbles reporter

    Thank you Erik. I believe it would help if you just changed that notification message. If instead of "revoked from the team account" it said something like "you cannot create repositories as a member of that team", it would solve everything as it would show what actually happened.

  13. Brian Nguyen staff

    Hi,

    We have now updated the emails so that they say the user has lost create access rather than access to the entire team.

    I have included a task for sending an email when a user is actually revoked from a team (#7475).

    Cheers, Brian

  14. Log in to comment