5 Replies Latest reply on Mar 6, 2012 11:37 AM by Brian Dalton

    Some rights are inherited, some are not... is that correct?

    Brian Dalton

      I have Mfg users that are only supposed to be granted Read Contents access to files once they reach the 'Released' state.  I discovered that if an Engineer moves a 'Released' file to the 'In Revision' state, the Mfg users can still see them, because the Read Contents right is inherited by all subsequent states, unless I set 'Ignore permissions' so that the right is not inherited.

       

      This seemed strange to me, because it doesn't work that way with 'Check out files' rights.  My Engineers have Check Out rights when they create their files and they retain that right until the file reaches the 'Released' state.  In that state, Check Out rights are not granted - however - I have not set 'Ignore Permissions' at that state, so the Eng users should still be able to check the files out.... but they can't.

       

      So, I'm wondering if that's the way it's supposed to be?  Are some workflow state rights inherited by default and others are not?  I don't remember reading anything about different rights having different 'inheritability' but I could have missed it.

       

      Is there a list of workflow state rights with indications of which are inheritable and which are not?

        • Re: Some rights are inherited, some are not... is that correct?
          Jenny Johnson

          From the knowledge base....

           

          In Enterprise PDM in order to access a file the user needs to have "read file" permission to the folder the file is in and at least one of the workflow states it has been in.

           

          As you transition a file through the workflow, it will likely go through several states. The read permission you assign on a workflow state means that a user or group will have read access to ANY version of the file that have passed through that state - even if the user lacks read permission in the current workflow state that the file is in.

           

          The versions that have only been created in a state where logged in user lacks read permission will not be accessible to the user, but if there are some versions in other states that user has read access to, the file will be visible in the file listing.

           

          This behavior is in place to allow workflows to be "circular", i.e. same state can be re-used multiple times.

           

          Consider the following example from the default workflow:

          1. UserA has read permission only in state "Waiting for approval"

          2. A file is added to the vault by UserB and checked in, creating version 1/1 in state "Under Editing"

          - At this point, the file is not visible to UserA

          3. UserB checks out, modifies and checks in the file creating version 2/2

          - At this point, the file is not visible to UserA

          4. UserB changes state on the file to "Waiting for approval"

          - The file is now visible for UserA and version 2/2 can be cached (version 1/2 is still inaccessible)

          5. UserA change state on the file back to "Under Editing"

          - UserA can still see the file and access version 2/2 since user has read permission to the previous state

          6. UserB checks out the file, modifies and checks it in creating version 3/3

          - UserA will still see the file in the file listing since version 2/3 was in a state where user has read access.

           

          The exception to this rule is if the current state of the file has setting "Ignore permissions in previous states" enabled, in which case it will ignore the circular workflow permission calculation and only use the permissions explicitly set on that state. So if a file is in a state where "ignore permission in previous state" is enabled, and user has no read permission, the file will not be accessible to that user even if an older version of the file was in a state where user had read access. (In the above example, if "ignore permissions" is enabled for state "Under Editing" the file would only be visible to UserA in step 4, not in step 5 and 6).

            • Re: Some rights are inherited, some are not... is that correct?
              Brian Dalton

              Thanks for the info, Jenny.

               

              However, based on my own testing, what is written in the KB is not exactly true.  Here's what I tried, using EPDM 2011 sp0:

               

              Workflow:

               

              State               User1 permission          User2 permission

              ONE                         All                                   None

              TWO                         All                                   None

              THREE                    All                                   'Read file contents'

              FOUR                       All                                   None

               

              'Ignore permissions in previous states' is off for all states

               

              Working as User1, I created the following file history:

               

              version 1  --  State ONE               Initial checkin

              version 2  --  State ONE               Create version 2 while in State ONE

              version 2  -> State TWO               Transition version 2 to State TWO

              version 3  --  State TWO               Create version 3 in State TWO

              version 3  -> State THREE           Transition version 3 to State THREE

              version 4  --  State THREE           Create version 4 in State THREE

              version 4  -> State FOUR             Transition version 4 to State FOUR

               

              Under these conditions:

               

              I might expect User2 to be able to read version 3, since it has been in State THREE, where User2 has 'read contents' access, even though the file is currently in State FOUR

                  -OR-

              I might expect User2 to be able to read version 4, since that version was created in State THREE, where User2 has 'read contents' access, even though the file is currently in State FOUR

               

              In fact, User2 shows only a white file icon, the State is shown as <Local File>, and User2 has no access at all.

               

              Something is amiss, relative to what the KB says should be happening, but I'm at a loss to understand what.

                • Re: Some rights are inherited, some are not... is that correct?
                  Brian Dalton

                  I neglected to mention that User2 has 'Read file contents' permission to the folder, but no other permissions.

                    • Re: Some rights are inherited, some are not... is that correct?
                      Jenny Johnson

                      Add in the Show working version of files and see if that helps.

                        • Re: Some rights are inherited, some are not... is that correct?
                          Brian Dalton

                          Yes, adding 'Show working versions of files' allows some visibility (I need to do a full experiment to determine exactly how much and when) but I've determined that without that setting, User2 has no access at all under any circumstances.

                           

                          This begs the question of why there is a 'Read file contents' setting at all, since it apparently does nothing useful.  What I've read in the manual and what has been stated by others here on this forum suggests that 'Show working versions' is an optional addition to 'Read file contents', but it seems to be necessary in all cases.

                           

                          I just don't understand the purpose of these two settings the way the seem to interact.  Since both are necessary, why have two settings?  Under what circumstances would one use one and not the other?

                           

                          But of course, my original question was relating to the fact that 'Read file contents' seems to be inherited (when 'Show working files' is on) but 'Check out files' is not.

                           

                          Sorry for so many questions, but I'm at the point where I really have no excuse for not fully understanding every detail of how these workflows and permissions function, and there seems to be contradictory statements all around regarding them.  I seek clarity, and I greatly appreciate any and all assistance.