Has anyone created a folder subtype so that it can have different attributes in a specific context (presumably also it's own OIRs?)?
There's plenty of discussion on CAD Document subtypes and WTDocument subtypes... I don't see anything on Folders in any documentation.
A particular product context has some custom type attributes that we agreed would be best served at the Folder level. I can add the appropriate attributes and make them searchable but that impacts ALL of the folders. So at creation of a new folder all of the users would then see the custom type attributes that are intended just for one product.
So my thought was that I'll just make a folder subtype and have that be the default for the particular context. But, alas, there aren't OIRs for a folder so... how do I make it default for one context and not for the whole site?
I see in the Type manager that it seems to allow it and I suspect that you will be able when creating a folder to get a choice of what subtype to create (manually). Checking the JavaDoc, the SubFolder class does not appear to be able to contain attributes as you would expect. There also isn't a details page which would show the attributes you are entering in. Still not understanding use case but caution with soft-typing. I am in the middle of trying to work them out of the system.
In general, folding is ok but trying to prescribe complex meaning to being in a folder has problems. I've seen instances where they used folders to release items where folders had different access rights. Might be best to put the attributes on the data objects like Parts and Docs.
WTParts might be the way to go... this is a new team moving into Windchill from shared drives. The way they are managing their data today is through folder structures so the path of least resistance was to keep the structure and their mode of work. Windchill does allow attributes to the folder type and they are searchable so that solves all of the requirements there. And we have a script to auto-create a folder structure the team wants in their context for each new set of tooling.
I was just hoping that through a folder subtype I can have their particular folder type with their attributes be contained just to their context.
With WTParts I guess the same can be achieved since it can be treated just as a container for CAD data, WTDocs, etc.
I'll keep that as option.
I will repeat my strong objection to using soft-typing. There is no supported method of changing soft-type once an object is created as a certain type. It falls apart as soon as the first user creates an object with the wrong type and wants it changed. In Windchill, it matters little where an object is location (folder). I only use them for loose organization so that you can browse to a folder and you do not see all objects in one location. Beyond that, I would encourage them to understand that folder management of data does not apply in Windchill. Lifecycle state and attributes work better to organize.
What about using different contexts for different products? We did this at another company where we had many products to keep track of and some had restricted access. Then you can put your folder structure under each context as needed.
Fair question and one that we on the admin side discuss at great length often. Our structure is somewhat basic in that we have a single site and a single org and everything else is broken down through contexts across what are hierarchically distinctly different business units.
We have (depending on the org) hundreds of products per year. Most of them are active for a brief amount of time and are then left alone. In some cases they are referenced or parts of the solutions reused in other products but mostly after about a year, the solution is either obsolete or will seldom be looked at again.
From an organizational standpoint there's a hesitance in seeing thousands of contexts over the last 20 years just sitting there being unused. We can't delete contexts and I'm not sure what options exist for archiving at that level. So instead, we go the context route for a team/group container and then within there their work is managed how they want. This is mostly through folder structures within their own context for projects the teams have.
I know this was raised to R&D in the past before, and by design, Folders are not intended to be soft typed.
R&D's intended usage is to just provide a hierarchical data organization structure which is used to manage authorization; folders provide the means to organize data into the domains against which access control policy rules are written.
There is this knowledge article (though it looks like it hasn't been updated in awhile, nor had much info).
You could try posting a product idea for visibility to product management, on newer releases.