How to define ACL on specific work items

[rhussain]

Hi All,

I would like to know about defining ACL's on work items

Thank you

[doehr]

What kind of work items, and what do you want to do to them?

[rhussain]

Hi Daryl,

Thanks for replying

The workitems like change task or change request  and I want to define acl in the way that these tasks should be available only for certain groups.

[doehr · Accepted solution]

Hi there,

That's quite easy to do in the Policy Administrator function, that you can get to from Org or Site/Utilities/Policy Administration. This can let you very carefully control what anyone can do to any object in the system, by the object's State, by group, by context role...it's extremely effective.

It might look like a bit of a beast at first but it's very straightforward. All you really do is define an object Type, which State it has to be in for the rule to work, the Principal (i.e. user, group, context team role, everybody etc) and the actual access itself.

For what you mentioned above, some of the Types might not be that obvious so:

• A Change Task is type WTChangeActivity2
• A Change Request is WTChangeRequest2
• A Change Notice is WTChangeOrder2
• A Problem Report is WTChangeIssue
• A part (gear icon) is WTPart
• A CAD file is EPMDocument
• A document is WTDocument
• The parent object type for everything, which will define access to everything in the entire system, is WTObject

Putting any rules on WTObject should really only be for Administrator access rules.

Creating an individual rule brings you to this:

You pick a Type from the list on the left, select which State the rule applies to, select a Principal using the Groups/Users/Organizations/Roles filters (it is highly recommended never to add a rule on specific Users) and Add them to have them as the Selected Principal, and then you pick the Permissions.

The Permissions shown above allow Grant, Deny, Absolute Deny and None. Granting some of them will also automatically trigger Grant for some others (i.e. selecting Grant to Modify will also Grant Read and Download, for example), and gives the Principal the selected access.

Deny removes access to something. Please note that the Policy Administrator access is based on a layered hierarchy, and all of the defined rules work downward going from Site, to Org, to PDM, to a context folder. If you give Grant to something at the Site level and then put Deny at the Org level, the Deny rule will take precedence since it was on the lower layer (and vice versa).

Absolute Deny is a stronger version of Deny; it cannot be overridden by a lower-level Grant line.

There is one other thing to consider, just because someone has access via the Policy Administrator doesn't guarantee that they can actually do anything. There are two other access control systems that overlap with this: user Profiles and the Configure Actions for Role function on the contexts, which control which action buttons users can see. You have to make sure they all line up; if someone has Full Control All on something but you have disabled their view of the Edit or Revise buttons via their Profile/Configure Actions for Role, they still won't be able to do those functions (and vice versa, someone could see the buttons but not have access via the Policy Administrator so if they try to use it they get an error popup).

Hope that helps...if you wish, list out precisely what kind of access you want to give/restrict and I could suggest some specific lines for you.

[rhussain]

Hi Daryl,

Thanks for providing a detailed explanation with screenshots, I will get back to you if required.

[kc-2]

Hi Daryl Oehr,

Am looking to restrict the pdf for the particular users. but i given as a user level. In that if i give only read only permission then download also it takes automatically.

Also modify means i need a Adobe professional to modify that. i have confused on that.

Explain me clearly if possible.

My main goal is to protect pdf files from some users. But some users only read permission.

[doehr]

Alright krishnamoorthy, let's take that piece by piece.

First off, are the users you want to restrict all within a specific Group or context team role?

Secondly, what kind of PDFs? Drawings, or something else?

Thirdly, just to be sure do you want to fully block the users from Downloading a copy of the PDFs? Or just from modifying the files saved within PDM? What exactly do you mean by "protect"?

For the Modify access rule in the Policy Administrator, that is not linked to Adobe Professional. Remember, PDM is a big linked set of data containers, I usually refer to them as buckets. Every part number, every document number etc...those are all just buckets, with all the core data files and reference links contained inside. Say, for example, you have a pdf Report called RPRT-12345. If you have Modify access to that report you'll be able to edit some of the general Attributes on that document's info screen (perhaps you have a sub-attribute called Type with options like Factsheet, Test Result, Analysis, etc, you could edit that value). Modify Content lets you replace the attached PDF file, not actually edit the PDF directly, that new PDF file has to be generated elsewhere (such as the Print to Adobe PDF function found in a number of places like Microsoft Word and most CAD softwares from their Drawing file). Modify Identity lets you change the document number itself, i.e. setting it to RPRT-67890.

[kc-2]

Thanks for your immediate response.Actually i created one ACL Default --> PDM. I given grant only Read permission for WTDocument for a group. But if i login with group memberi can able to view only the information of that document.

My question is what is the difference between Read and Download??.

If i give Read access i cant able to read the document only information i can.

Customer wants the designers should not Save as the PDF file which is attached. They need read only format.

Is there any way to set that in Policy Administrator????

Thanks in advance....

[doehr]

Ah...I see.

Remember as I said, the item number entries in PDM (documents, parts, Change Requests etc) are all just buckets to hold info. You can think of it as the main Attribute fields like Name, Number, Description etc as the label on the bucket; Read access lets you read the label. But usually for a PDF drawing or document that's just superficial info about the file, the actual file itself is attached within it (i.e., inside the bucket). Download access lets people open the attached file.

As for restricting Save As...that's a bit pickier, and might not be possible. There are Save As functions available in contextual menus all over the place that appear to be disabled if you deselect the Save As function from both Configure Actions for Roles on a context and the relevant user Profile, but they still get Download which lets them save a copy on their computer (because I was curious I directly tested this just a few minutes ago with those exact access restrictions on a dummy account). Then it's basically the same thing you're trying to avoid, the only controls are in the Adobe software they use to read and manipulate it.

If they must be able to read the content file itself they must have Download, and if you want to restrict what they can do with a Downloaded copy that pretty much moves outside the realm of PDM into your PDF-reading programs. You might be able to do something with access locks via signatures, etc within the Adobe programs themselves that create the files, but I don't really think I can help you here. Via PDM, you're better off restricting the list of people that can even see the files by restricting who is in the host Context of them.