I help run a local makerspace and I often help members with some CAD/CAM and running our CNC router. It's a bit limiting that everything happens through my computer and Fusion account though, and looking at it very briefly I thought Fusion teams would help a lot with this. I created a team and migrated some projects over to discover that this is ... not the case. To put it mildly.
My use case I thought would be extremely normal and basic for any sort of sharing and collaboration system. Here are the individual scenarios with every specific need listed:
Have a folder/project/whatever for each member where they can put their files and we can open them and work on them when we're on location.
Needs:
(a) All member-related things need to be in one easy to see location away from all our other things.
(b) A member should be automatically granted carte blanche access to this "home location".
(c) A member should not have access, read or write, or even awareness of another member's existence unless invited to work on a specific project or file.
(d) A new member should be able to share their files into this new home folder with minimum headache.
- Have some folders/projects with files available to everyone as demos or educational material, as well as a generic dump/shared area for members to exchange things in.
Needs:
(e) A member should have automatic but then individually configurable read/write access to team-wide shared items.
- Share machine setup and tool libraries, so that people can see what tools we have and our settings presets as well as the machine size and limits, things like this, all without me having to do anything except update the tool library in the cloud like normal. The libraries should also be protected from accidental overwriting of tool parameters and presets because with a lot of users of various skill and experience level, this will obviously happen a lot, and then someone will use a "good" preset without thinking, and bad things will happen.
Needs:
(f) A member should have automatic read access to the tool and machine libraries.
(g) A member should be able to be selectively granted write/edit access to these libraries.
(h) A member should be able to use these libraries in their own personal projects.
- Have some folders available only to staff where we can keep projects and files about things we're working on for the workshop or equipment.
Needs:
(i) Members should be able to be assigned a grantable "staff" role that gives them read/write access to these projects/folders/files.
(j) Members should be able to be individually granted read and/or read/write access to these.
So, I migrated all the files that are "ours" from my personal account via the Team Onboarding link, and then spent a few hours meticulously organizing projects and folders - itself a counter-intuitive, inscrutable conundrum but that's not the team feature's fault. But as a semi-brief aside here I have to wonder what's even the definition of a "project" for the Fusion UI designers. To me a project is an individual "thing" you're working on with all the associated files connected to that thing. This leads to a natural organizational hierarchy for a team like this wanting to look like:
.
├── Members
│ ├── Name Nameson
│ │ ├── 3D Print Projects
│ │ │ └── <Projects, folders, files, etc>
│ │ ├── My random project
│ │ ├── My interesting project
│ │ │ └── <Projects, folders, files, etc>
│ │ └── <Unsorted projects and files>
│ ├── Other Nameson
│ │ └── <Their stuff>
│ ├── <More members>
│ ├── <More members>
│ ├── <More members>
│ ├── <More members>
│ └── <More members>
├── Workshop Stuff
│ ├── CNC Fixtures
│ │ └── <Projects, folders, files, etc>
│ └── Laser Cutter Upgrades
│ └── <Projects, folders, files, etc>
├── Demos and Examples
│ └── <Projects, folders, files, etc>
└── Shared
└── <Mayhem>
Instead in Fusion, teams and otherwise, a "project" can only exist in the root location. INSIDE a "project" you can have a nearly endless scheme of organization but it's not possible to organize projects in any way beyond pinning them to the top of the list. As we will see, since essentially all access control features relate only to "projects", the only possible hierarchy that's possible to use is:
.
├── A Nameson
│ └── <Folders and files which are logically projects>
├── <very long list of alphabetic members>
├── CNC fixturing
│ └── <Folders and files which are logically projects>
├── <many more names>
├── <many more names>
├── <many more names>
├── <many more names>
├── Laser cutter parts
│ └── <Folders and files which are logically projects>
├── <many more names>
├── <many more names>
├── <many more names>
├── <many more names>
├── Shared
│ └── <Chaos>
├── <many more names>
├── <many more names>
├── <many more names>
├── <many more names>
├── Workshop stuff
│ └── <Folders and files which are logically projects>
├── <many more names>
├── <many more names>
├── <many more names>
└── <many more names>
(I can pin the shared/important workshop "projects" to get them on top and have slightly less of a mess, since all members will start under those and be alphabetized from then on.)
As you can see, none of these "projects" are actually projects in a logical sense. They, by necessity end up being containers, categories or folders into which you put your actual project files. Anyone who would actually use a "project" to store each and every project they work on would almost instantly end up with an immense list with no possibility of organization or navigation. Does no one at Autodesk have more than a handful of "projects"?! Did this never bother the designers or developers in the soon to be decade this software has been in development?
Like I said, I don't think even a single part of this use case is even remotely strange or unusual, but it turns out in the current implementation of "teams" in Fusion essentially none of these are actually possible. We've even violated (a) unfixably before we even go into invidual scenarios. Failure point(s), point by point:
- There is no meaningful role- or group-based access control. All access control is only on projects, and has to be done one by one, so I can't create a folder for a member (because there are no project folders) where they can live and breathe and create projects. I have to create a project for each member and then they have to apply or get invited (I can't just... add them? Why?!) to the project so I can grant them access. Then they can create folders inside this "project" and pretend that those are their actualy projects - but of course you can't share a folder with someone, only projects or files. So if they have a project with multiple files then they can either share all of their stuff, or every file individually.
And let's not even start on the clear-as-mud distinction between a "project contributor" and a "team member". Between project visibility, member/contributor, viewer/editor status there are so many unconnected, overlapping access control points and concepts and they're spread all over the interface and interact in many exciting and intuitively utterly unforeseeable ways.
Which unfortunately leads us to another brief intermission:
Why is project details so hard to find? It's a place where you change distinctly admin-y things isn't but it isn't in admin, nor is it in a button next to or inside the projects, nor is it in the right click menu of the projects, which are all places where a normal user would expect to find it: instead it's in a basically invisible solitary tab on the far right of the browser that's otherwise occupied by the highly ignorable and easy to miss team activity log. Did you not have any user testing or feedback in the many years this feature has existed?!
And once we do find this obscure, hard to find panel which is as stealthy as it is essential we have in it: a big blue "manage members" button, definitely an admin function and then we have the tiny cogwheel icon that doesn't even look like a button in the top right corner that controls project visibility/access, definitely another admin feature. These should both be in the same place and style! Nowhere else in this entire interface is there a cogwheel settings button! And why is the team admin link under my profile anyways and not in the actual team interface where it belongs? It's definitely not something that is conceptually close to my account settings.
What about newly interested members I add to the team? They can move their "projects" into the team but of course, only "projects". Not files, folders or whatever organization they are using on their own account.
But wait, people can share their own designs on a file-by-file basis with other personal accounts. Surely people must be able to just share their personal project files with the team then? No, of course you can't. The only way to get anything into a team hub is if that team owns it. Then of course it's deleted from the user's personal account and if they want it back they have to export and reimport it, and then it's a copy with no associative link. If they ever leave our team or anything happens then they will lose it forever.
- For team members there are open projects, essentially solving this point, but they always have editor status in these until individually changed to viewer. It's also pointless extra clicking and explanation to do to manually need to "join" open projects instead of just having access.
- Like 2, team members always have access to this but additionally this CANNOT BE SET TO VIEWER ACCESS?! Ok so we already established that people can't have access to this without the ability to accidentally cause all kinds of chaos which would then affect everyone.
What if we keep it all read only so that we can use this team cloud sharing thing to disseminate machine and tool information and people can use it on their personal projects on their own account? Nope. When you're in your personal hub, this stuff doesn't show up in the "cloud" list of machines or tools. In fact you can't even have files from a team hub and personal hub open at the same time because Fusion will instantly close them all when you switch. Again you can share files from a personal account to another personal account, but you can't share anything from a team without adding them to the team and then they are locked out from interacting with any personal hub files.
- This can actually be done completely with secret projects and all staff being granted administrator status. That's not how I'd want it at all, but hey at least it's possible - and at this point I take what I can get.
Ok so... We accept that we can't have any real organization on the "project" level and the only access control we have is on "projects". Now we have to decide if we want to have our members be "team members" or "project contributors".
Option 1, Team Member:
The documentation says that typically internal users are team members, and I think our users are internal so we'll try this first. This lets them see all open and closed projects and have full editing rights to open projects. They can unfortunately also create projects, which has the potential to create pointless clutter I will have to clean up later. They can also "invite users to projects" and I'm really not sure what that even means. Does it mean they can create "project contributor" members to closed/secret projects that they are members of? Only projects they create themselves? All closed projects? All open projects?! (No: PC's can't be member of an open project in the first place for whatever reason).
Members as TM then leaves us at these fulfilled needs:
(b) - If we count "automatically" as me creating a project with their name, setting it secret, then inviting them into it with editor status and they accepting the invite. Not exactly smooth or ideal but I can live with it.
(c) - If all member projects are secret, which is reasonable.
(e) - Barely, partially: If these projects are open they can invididually join them on their own, which is a silly extra step but ok, I can accept it. However they always seem to join these projects as editor, which is undesired.
(f) - Technically fulfilled. They do have automatic access but it's editor and it's not actually even possible to set viewer access on the libraries. Catastrophically undesireable. I'm really just keeping it here to have things on the positive side.
(i) - These projects would have the "secret" visibility. Staff can be invited to the secret projects individually but it must be done one by one for every project and staff member. Not ideal but acceptable.
(j) - Members can be invited to secret projects. Great!
The following needs are directly violated:
(a) - You can't organize projects and we can only control access on projects.
(d) - Impossible, you can only move files one way into the team. They can't be shared between hubs if one of them is a team.
(g) - They can't even selectively, manually be granted read only access at all. Everyone always has full read/write access to all asset files. This failure point alone makes it unpleasant and somewhat terrifying to have our members as "team member" status but let's keep going anyways.
(h) - Impossible, Fusion basically resets to boot status when you change from one hub to the other in the data panel. No data exchange between information on different hubs is possible without manually exporting and re-importing files, which isn't exactly nice in this cloud era.
Ok so that's a bit of a mixed bag really. We can make perhaps 50% of the original plan work with some changes and a LOT of manual work clicking around. What about making the staff "Team Members" and our ordinary members "Project Contributors"?
Option 2, Project Contributor:
Having ordinary members as PC and staff as TM leaves us at this status of needs fulfilled:
(b) - Same as option 1.
(c) - Same as option 1.
(i) - Same as option 1.
(j) - Same as option 1.
The following needs are directly violated:
(a) - Same as option 1.
(d) - Same as option 1.
(e) - Impossible. A PC member can't under any circumstances be granted any access to open projects.
(f) - Impossible for the reason above. The assets library is automatically, forcibly an open project - with the consequence that PC members can never participate in any sort of CAM in a project except for using machines and tools that are already in a design file from being used by a Team Member.
(g) - Impossible, see above.
(h) - Same as option 1.
Well, that was even worse. Getting kinda disheartened here.
The only way I can even remotely approximate our original use case is by having each member be a "project" that they can apply to. This of course leaves dozens and eventually hundreds of "projects" that aren't projects in a long, unwieldy list that is not possible to organize in any way whatsoever because remember, you can't put projects into folders, you can't put projects into projects, you can't do ANYTHING AT ALL to organize them. They're just there, forever. In a single, huge, flat list.
And then when we have a new member they will need to individually join or apply to half a dozen projects, and I have to go in and individually change some of those to "viewer" instead of "editor" - except the assets library, about which I have to make a very stern and serious face and explain that you must at all times be absolutely sure you're never editing the cloud tool library or machine definition, whatever you do.
I don't think there's a single real-world team working in CAD anywhere in the world that can have any benefit whatsoever from these bizarre restrictions in how they can organize their assets and access control.
And these "projects" not even projects in a real-world sense to begin with - it becomes a very confusing name for what would normally be a home folder or category. I suppose we consider ourselves lucky at this point that we have the "pin" and alphabetical sorting.
While we're at it I can bring up some other nonsensical peeves:
There's no way to hide the "samples" that we really don't need to see every day we open the data panel. Please let us hide rarely/never used interface cruft like this. Right now they take up as much space and visual attention as actual projects.
Why can we only create one team? Is it an unthinkable reality to Autodesk that a person might want to have two different teams? You can be a member of several teams, even an administrator (I think) but you just... can't be an owner of more than one. The mind boggles.
When you create a team it's automatically given a subdomain based on the email domain of your autodesk account ... WHAT? I'm sure many if not most people have old Autodesk accounts with emails completely unrelated to whatever team-based activity they happen to participate in. There's no warning that this will happen and not even ANY possibility to change it. Was there seriously a design meeting where the conclusion was "of course everyone will have their Autodesk account email address on a domain they want as their team URL"?!? Boggling intensifies.
Why can file sharing only be turned on/off on a team-global scale? What about by user role? Per project? Per file? EVERY OTHER option is more reasonable than on/off for everything and everyone. Also file sharing here, unlike the rest of fusion shares a copy of your design because ... you just can't share into or out of team hubs like you can with personal hubs. I'm sure there's a reason. I'm sure. I hope.
Why are there two buttons in the project list in teams (bell, pin) and then a dropdown arrow that has only one option inside it (archive)? There's space for 20 buttons at least, and what's the point of a dropdown with only one option in it? At least put the project admin options in this dropdown if anything for the love of god!
Constructively, the way to fix this unbelievable, nightmarish tangle is to dump it all and implement a flexible, simple to use and already familiar to everyone access control and file structure system.
A very quick and easy spec sheet for such a system would be:
- In the hub root there are items. Everything in the entire file structure is an item. There is no arbitrary and infuriating distinction between a "project" and a "folder" - and no imposed limitations thereof.
- An item has a parent item. This means you can have folders inside folders, designs inside designs (which you already can do after all). Even folders inside designs - which you can also essentially already do by nesting components. No arbitrary, artifical restraints on where and how you can organize things.
- Items can be folders design files, uploaded files or anything else.
- Items can have permissions set on them (for example visible/read/write/share) by team-wide default, group membership and individual user.
- Administrators can create groups (or call them roles, whatever). A group has a policy attached to it.
- A user can also have a policy attached to them.
- A policy is an independent store of data that describes exactly what the entity this policy is attached to is allowed to access and how.
- A group/role can have specific or recursive (sub-items) access to any item, at any level specified by the group policy. Other plausible and useful policy items are for example being able to administer the group/team/role, invite members, accept member requests and anything like this. Administrator is just a group under this system like any other. Team-wide defaults is also just a normal group like any other, except assigned automatically to new members.
- Items belong to an owner hub/account but can freely be either associatively or not (copied) shared or linked to any other hub/account. There should be no distinction between sharing personal-to-personal, personal-to-team, team-to-personal or team-to-team.
- Items should be freely transferable from one owner hub to any other type of new owner hub.
That's it. That's all the complexity you need. With these simple guidelines, almost any concievable organizational or access scheme can be trivially constructed, including replicating the spaghetti mess the current one is if someone really would want to. This is how almost all access control systems work out in the wider world and there's many very good reasons for it, not the least that having a solution that has as many generic concepts as possible is both easier to develop and easier to maintain than one that forces specificity and hard-codes a lot of unique situations. It's also close to how the file systems and relational databases that the software actually runs on is laid out, for many equally good and well-proven reasons.
In such a system, when I have a new member I would simply:
- Create a new home folder and give the new member full access rights to it.
- Add the new member to the generic member group/role (if it's not automated) - granting them read access to examples, tool library and write access to the shared folder.
- Add the new member to a group that gives write access to the tool library, for example, if I should wish it.
And it's done. Just working. Members can see and get in everywhere they should, can't break anything they shouldn't, and can organize their own space exactly as they want - up to and including just dropping a link/shortcut/associative copy of their design from their private hub into the team hub.
I don't understand how the current offering has existed this way for years. It's just not a finished design, more like a first proof-of-concept napkin sketch that somehow got implemented without anyone pointing out how astonishing it is. I don't get it. The only other part of Fusion that's as hopelessly bizarre as this is the Parameters window and I've typed enough tonight.
Oh, and please make the onboarding tool also work as an offboarding tool so we can undo the damage we did to our personal accounts without manually exporting and reimporting each design file individually.
