Projects that use Worksets have four kinds of worksets: User-Created, Project Standards, Families and Views.
User-Created worksets are the bookshelves we create to organize building elements logically (read How Many Worksets...). The other three are always there but ordinarily we can pretend they don't exist. Each family that is loaded into a project is assigned its own Family Workset. It happens quietly behind the scenes. We don't have to do anything at all.
Ordinarily we don't wittingly or intentionally interact with a Family Workset at all. For example, we can place hundreds of doors and not affect any doors's Family Workset. However, if we assign a value to a door's Type Comments parameter we'll find we are the Borrower of the door's Family Workset. Altering Type parameters affects the Borrower status of a family's workset.
Occasionally we find it desirable to lock-down some families. Users might get unruly and make changes we've agreed not to make without approval or someone can accidentally reload a family from the wrong library. I'm positive we can come up dozens of other examples.
We can deliberately become the Owner of any families we'd like to prevent users from altering significantly. Select the family workset and click the Editable button. Our username will appear in the Owner column. It's for this reason that most people create an alter ego like "Family Manager", "Model Manager", "Model Admin", or "Bubba"... you decide which is best. This alter ego only opens a local file when they need to deal with updating families or whatever other task they are reserving for certain roles.
This will prevent users from easily reloading and changing type parameters. They can still alter instance parameters. They can also move, swap the family for another with the Type Selector or even delete the family. There are still plenty of things that can go wrong. We've just made it a little bit harder to do a couple specific things wrong.
Be careful with Editing Requests, making them or granting them, when you lock-down worksets. Users can become the borrower unexpectedly, as THIS POST describes.
User-Created worksets are the bookshelves we create to organize building elements logically (read How Many Worksets...). The other three are always there but ordinarily we can pretend they don't exist. Each family that is loaded into a project is assigned its own Family Workset. It happens quietly behind the scenes. We don't have to do anything at all.
Ordinarily we don't wittingly or intentionally interact with a Family Workset at all. For example, we can place hundreds of doors and not affect any doors's Family Workset. However, if we assign a value to a door's Type Comments parameter we'll find we are the Borrower of the door's Family Workset. Altering Type parameters affects the Borrower status of a family's workset.
Occasionally we find it desirable to lock-down some families. Users might get unruly and make changes we've agreed not to make without approval or someone can accidentally reload a family from the wrong library. I'm positive we can come up dozens of other examples.
We can deliberately become the Owner of any families we'd like to prevent users from altering significantly. Select the family workset and click the Editable button. Our username will appear in the Owner column. It's for this reason that most people create an alter ego like "Family Manager", "Model Manager", "Model Admin", or "Bubba"... you decide which is best. This alter ego only opens a local file when they need to deal with updating families or whatever other task they are reserving for certain roles.
This will prevent users from easily reloading and changing type parameters. They can still alter instance parameters. They can also move, swap the family for another with the Type Selector or even delete the family. There are still plenty of things that can go wrong. We've just made it a little bit harder to do a couple specific things wrong.
Be careful with Editing Requests, making them or granting them, when you lock-down worksets. Users can become the borrower unexpectedly, as THIS POST describes.
No comments:
Post a Comment