Improve the moving of projects

With the introduction of Team sharing the default behaviour for changing the team in the project settings has changed.

Instead of moving the project to another team (what is logical to suspect when you change a setting that can only contain one team) it doesn’t change the team, but rather adds another team.

EDIT: I was wrong about this. Changing the team through project settings only changes where the team lives. It does not change who can access the team.

EDIT2: Projects seem to be visible at the team set in project details and any teams added in project sharing, but only by those who have access to the project through sharing settings (either through team or individually)

This is leading to confusion:

I’m hoping this can be made more intuitive.

Desired outcome:

  • More clarity on what is happening.
  • Be able to move a project between team (instead of adding access to a new team) without having to switch views.

I’m thinking the most logical options are:

  • Configure the project settings back to replace team rather than to add
  • Remove the option to change from project settings, and add an option to select the “home” team in the sharing settings. EDIT: It doesn’t make sense to me that a project can live in another team when there is at least one teams that has access
7 Likes

I definitely agree with this. It is not intuitive that what appears to be an action of changing teams actually just adds a team. It’s a single select menu, so like the expected behavior in any feature or app, the user would assume they are selecting the single team they are moving the project to.

This came up with a client of mine who thought they moved the project, and then they started adding info to the project that the other team should not have had access to. It’s resolved now, but it’s an unintuitive inconvenience at best, and problematic for data sensitivity at worst.

I hope this is updated with either of the options @Jan-Rienk has suggested.

2 Likes

Are you saying that when you go to the Project Details, and “select a team”, you are not moving it to a new team? You are adding a team?

Or are you saying that when you open the Member List and you see a Team listed, when you “Invite” a different team, it’s not changing the location but rather adding a new team access?

I’ve always used Option 1 above to move projects from Team to Team, and I’m not experiencing any issue with that method on my side?

This is how I understood the feature to be working based on the conversation in the topic I linked.

EDIT - I was incorrect about this. I somehow failed to spot that Charlie was also in Staff team.

I’ve now tested to confirm, and the behaviour I’m seeing now in my Phoenix instance is the following:

  • Editing a project’s home team in Project Details only changes the team where the project shows up on the homepage.
  • If the team a private project is living in is NOT inlcuded in the project sharing field, someone who is not a member of this project, but is a member of this team, is able to see the project and join it as a Project Admin.

This means that whilst the new team isn’t included in the Sharing permissions, they have Project Admin access to this project.

I’ll demonstrate:

Perspective Alan

Project 1 lives in the Operations team after changing in from the Staff team in Project details

  • image

Charlie is not a member of Project 1, which has it’s sharing setting to “Private to members”.
The Operations team doesn’t seem to have gained access when looking at the sharing settings.

Perspective Charlie

Charlie can see Project 1 in the Operations team, and is able to join

Charlie can also find the project through search:

After joining the project, although being added as an Editor, but in fact has Project Admin access.

They can edit the project permissions:

  • image

They can delete the project:

  • image

Flagging this for @Forum-team as this seems a pretty serious loophole, and a deviation from how the privacy settings are described to work.

Upon testing this with Alan creating a new private to members project in the Operations team, it is not visible from Charlie’s perspective.

After changing the Project settings to Staff team and back to Operations team, it is still invisible to Charlie.

Steps to reproduce

  1. Create shared with team project in team A, or create a private to members project in team A, and share it with team A though project sharing.
  2. Change the team to team B in Project Settings
  3. Members of team B can now join and manipulate the project with Project Admin rights eventhough they are not part of team A, nor members of the project. The project will also show up in search.

I have tested this with teams that are private to members.

My guess is that team sharing is somehow still tied to the team in the Project settings in the background.

1 Like

@Jan-Rienk that is because you have the access permissions for team “Staff” set to “Project Admin” !

If you change the Staff access permissions to comment only, that’s how you would lock it down. You have to work your way up with permissions, so start with lowest level when giving access to an entire team

EDIT: this post was based on an incorrect assumption

Hi @Kelsea_Lopez ,

Let me rephrase: It doesn’t look like the Operations team has gained access, but as you can see from Charlie’s perspective (who is a member of Operations but not Staff), in actuality they have.

You might be right this is the cause of this, but I’d at least expect the new team that is added to show up in the sharing setting that is claimed to contain every person and team that has access.

As I said, they seem to have been added in the background.

Hi everyone, thank you so much for sharing your feedback, and I’m sorry that this change is causing some confusion.

@Jan-Rienk, I tried to replicate your scenario on my end, but I didn’t run into any permission inconsistencies. If you’d like to share this specific example in more detail with our Product team, please click the feedback link in the “Share Project” pop-up and fill out the form:

I have also shared this Forum thread with our Product team. They know about the confusion and are keeping an eye on all the comments to make things clearer. I’ll keep you posted if anything changes.

1 Like

I made a mistake. I thought Charlie wasn’t in the Staff team.

Apparently he was. :man_facepalming:

@Kelsea_Lopez you were correct.

Cannot reproduce after removing Charlie from Staff team.

Apologies for the confusion.

2 Likes

I’ve updated my posts about this to minimise confusion.

no worries, glad we could figure it out!!

1 Like

Thanks so much, @Jan-Rienk and @Kelsea_Lopez! I know this change is still a bit confusing, but our team is actively working on improvements. We can also ensure you that this update will help with some upcoming enhancements in the overall permission system. We’ll keep you all posted on any changes, and the Product team is closely watching all feedback. :blush:

3 Likes

Now I’m confused. Here is someone saying it copies instead of moves.

I don’t get it anymore…

Hi @Jan-Rienk, it looks like they also got confused with the change, but Brian shared the explanation and the user understood it. It seems to be fine :slight_smile:

My work instance now has team sharing enabled, and this instance seems to behave differently than what I tested in my Phoenix instance:

This means @Bryan_TeamKickstart 's solution doesn’t work for me.

Confirmed that it’s only visible to the team with access in sharing settings.

@Jan-Rienk - yes, I am now seeing the same thing. Previously, in my testing, it seemed “moving” the project simply gave project access to both teams. However, now, in my live instance, I’m seeing what you are seeing.

I moved the private project to Team B, and Team B did not inherit access, but for those who have permissions either as an Individual, or by virtue of being members of Team A, now see the project on both teams. However, Team B members who are not on Team A do not see the project.

I think it’s better this way than the way it seemed to work last week. This seems more intuitive, although still a bit confusing, especially since the privacy options look different while creating the project than after project creation.

Privacy options during project creation:
image


Privacy options after project creation:
image


Though I do understand the intent here, it just seems the UI still needs to be more clear to users.
Or who knows, maybe we’ll all just adapt once we are used to this method.

2 Likes

Hi everyone, I’ve already shared this in the Tips & Tricks topic, but I’m posting here too in case it helps resolve the scenarios described.

Our Developers have made some updates to the team sharing workflow. Now, when you move a project between teams, you’ll be prompted to update access. Here’s a screenshot of the new pop-up window you’ll see when changing a project’s team via the drop-down:

We hope this will make the process clearer! @Jan-Rienk, if you feel this addresses your feedback request, let me know and I can mark this thread as solved.

Thank you everyone for sharing your thoughts! :slight_smile:

1 Like

Hey @Vanessa_N Thanks! :pray:

It looks like you didn’t quite catch the pop-up, but this is great!

Small suggestion would be to tweak this text a bit.

{project name} now lives in the team: {team name}.

:point_up: This sounds like the move has already taken place. But when you close the window with [x] the project hasn’t moved yet.

I’d suggest something like this:

You are moving {project name} to the team: {team name}

1 Like