Skip to main content
P
ptc-44733951-Visitor
1-Visitor
April 2, 2012
Question

Security settings - Folder Access

  • April 2, 2012
  • 4 replies
  • 5404 views

Hi All,

I recently just came onboard with an organization that employs Windchill PDMLink. As a result, last week I ended up taking the business admin course for windchill PDMLink v10.

One of the things that was brought up last week was controlling folder access within an organization.

To restrict access to all but a handful of users to the particular folder, the course of action from the training material was to create a new domain, and restrict this particular folder to a particular domain.

This made me question - "Why can't I just use groups to achieve the same functionality?"

After continued reading through my course material I am of the opinion that going to the Domain level was a bit of overkill, and that groups should have been used.

But as I stated above - I'm new to Windchill so I could be totally off. I figured I would throw this out to the community just to see what the consensus is w.r.t. Access control inside of Windchill.

Any and all dialogue is very much appreciated.

Cheers,

Sean.

    4 replies

    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    April 3, 2012

    This is in fact about the only way that you can accomplish what I think the stated goal means - but the stated goal says "controlling folder access within an organization." This is very different.

    Each Product & Library is a world to itself and can have it's own access control rules; the rules apply to the whole "context" in general. With each Product & Library, one can have additional Folders, and these require separate domains in order to apply separate ACL's.

    Make sure that you have fully utilized Products & Libraries as needed to control access prior to subdividing each by Folder.

    P
    ptc-44733951-VisitorAuthor
    1-Visitor
    April 3, 2012

    Hi Mike,


    Thanks for the great reply.

    If I am interpreting your message correctly, you are essentially stating that rather than have one product with many folders (each of which *could* have different domains), you would create separate products with a domain applied to them.

    In my particular scenario, I'm not necessarily sure one way is more advantageous than the other, because I will likely have many different folders that all require restrictions but those restrictions (i.e. the group of users that can access that folder) will all differ.

    For example, person A can access folders 1 & 2 & 3, person B can access folders 1 & 2 but not folder 3, person C can only access folder 3.

    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    April 3, 2012

    Still lots of options - the "design" of these things is every bit as much a design project as designing products.

    1. For many reasons (some not evident until later), it makes sense to distribute data by product / product line. Within each Product context, there may or may not be folders.

    2. Shared parts, standard purchased parts, CAD formats, etc., etc. which are not specific to a Product should be in various LIbraries.

    3. You can't talk about or plan user permissions until you have decided on both object types and Lifecycle states applied to those object types - in each specific Product / Library.

    4. For user permissions, start with considering permissions by state. In general, few people should have READ access to objects not yet ready for business use (e.g. In Work); many (or all) should have READ access to Released or equivalent states.

    5. Only after thoroughly planning permissions by context and state should you consider also using Folders for permissions - to supplement / override the base methods.

    6. An example: A Document may be assigned Lifecycle 123 in Product A, and have states STATE1, STATE2. User permssions to the Document type may be assigned by state in that Product. A Document may then be separately assigned Lifecycle 456 iin Library B, and have states STATE7, STATE8, STATE9. Completely different user permissions may apply in that Library for the same type.

    This is one of the worldest greatest puzzles.... I've quit playing chess, etc. for the past 8 years since being involved in Windchill business admin. It's also very challenging to document these configurations once you've determined how to apply them. But - It's worth it to the business to really dig in and think thru this stuff. These are what I like to call "10-year" decisions - and they affect users all day every day in a major way.

    B
    BuddyHudson1-Visitor
    1-Visitor
    April 3, 2012

    Does anyone know how to give explicit access to a user to modify objects in a Library. I have tried like 2 or 3 different things but no luck. I have Full Control set for a group called "Hardware Editors" in policy for the Organization and he is in this group, which I have also added to the team for the Library itself. Out of options. Can anyone help explain this better or point me in the right direction?

    Buddy Hudson

    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    April 3, 2012

    As administrator, access an object in the Library. Select Manage Security - examine the permissions for all users and drill down to why they are there (from which speciific statements). If necessary, FIND a specfic user. Likely a DENY is overriding the permissions you've assigned.

    P
    ptc-44733951-VisitorAuthor
    1-Visitor
    April 4, 2012

    Alright,

    So first off - Mike, thank you for your continued reply's.

    Secondly - I think now that I've been playing around with it a bit I'm getting a bit more of a grasp on the concepts.

    The goal of the orignal problem, was to lock down the folders that contain sensitive data to prevent users from reading/modifying that data (I know I didn't say anything about the actual data inside of those folders in my original post).

    I locked down the folder by creating a child domain of the product's. Yes this prevented whatever user/groups I wanted from actually seeing that folder. But when I looked at the CAD documents in those folders, they themselves were still a part of the Product's context. So, if that's true, then I'm assuming regardless of what ACL's I write for that child domain of that product, it's a 'none or all' activity to lock down the individual documents of any given type.

    I believe what I should do instead, is create a new PRODUCT (perhaps even with a private domain) and then move those files that need to over into that Product. Then write any necessary ACL's I need to against that products domain.

    At leat that's the direction I think I'm headed. More reading is still required.

    Sean.

    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    April 4, 2012

    Yes, getting closer. It's a multi-dimensional "this within that" problem.

    You apply permissions to a place (Product), and possibly to a place with a place (folder).

    You apply permissions to an object type (CAD Doc), and and possibly to a type within a type (sub type of CAD Doc).

    You apply permissions to a group of people (Org, Group), and possibly to a Group or person within that Group.

    Note: Use Manage Security extensively - great tool to provide feedback on what is going on in each case, with each set of configurations. WIthin Manage Security, search for any test user that you've created to see what that user can do.

    Note also that any object can be part of a structure no matter where it is stored. If a given user does not have Read permission for that object, it won't be shown. Some structures won't be able to be retrieved because of this.

    Terms & ConditionsAccessibility statement