Skip to main content
S
sdrzewiczewski10-Marble
10-Marble
June 17, 2010
Question

Add to Project permissions/preference?

  • June 17, 2010
  • 12 replies
  • 4534 views

Are there ACLs or a preference that controls who/when an object can be shared to a Project from a Product/Library?

I have a user that is trying to share some objects, but the "Add to Project" option is greyed out.

Thanks,

Steve D.

12 replies

R
RajeshBalasunda1-Visitor
1-Visitor
June 17, 2010
The user needs to be added to the role Collaboration Manager in the
context. This will allow him/her to share objects to project.



Best Regards

Rajesh Balasundaram
    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    June 17, 2010
    Quite incredible but the permission is: Change Permissions

    I put in two different calls on this and got the same answer and it works.
    J
    jfrankovich12-Amethyst
    12-Amethyst
    June 17, 2010
    Seriously? Does it have any other unintended consequences?


    From: Lockwood,Mike,IRVINE,R&D [
    S
    sdrzewiczewski10-MarbleAuthor
    10-Marble
    June 17, 2010

    Thanks everybody, once you mentioned the Collaboration Manager role, i remembered...

    The Collaboration Manager role has the ACL set for Change Permissions. This also allows users to Modify Permissions through the Ad-Hoc permissions. They can only grant the permissions that they have.

    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    June 17, 2010
    None other that we've found. It's just a very strange name for the permission.

    I'm attaching a spreadsheet that we continue to work on to try and make sense of the puzzle PTC has provided re ACL's (it's only ~ 30% done). Note: All the good stuff is in the cell comments. See column P for this one.


    From: John Frankovich [
    B
    BrianSullivan10-Marble
    10-Marble
    June 17, 2010
    Hello Steve,

    The Change Permission grants permission to share between PDMLink and ProjectLink. The Change Permission also turns on Manage Security Power in PDMLink.

    My normal recommendation (9.0/9.1) is to modify the Profile for your users and Hide the Manage Security Button. That way they can share to PDMlink but not grant additional privileges in PDMLink.

    PTC has a Reference Document that explains all the access control requirements between PDMlink and ProjectLink, page 31 of the Integral Operations Between Windchill PDMLink and Windchill Projectlink.

    Brian Sullivan

    PS
    I have an old copy, I will send in a separate email directly to you


      V
      vmcdaniel1-Visitor
      1-Visitor
      June 18, 2010

      We are currently working on setting this up as well (9.1 M040). This guide (p.31)says the user must have Change PermissionsAND Modify permissions on the object. This poses a problem for one of my PDM-Project share actions, specifically Users cannot 'Add to Project' a Released object since they do not have Modify permissions. <u>Is this what you see as well?</u> I don't see that reflected in Mr. Lockwood's excel sheet.

      Also in the Policy Administrator I'm noticing that created Projects show up in the \Private\Project\ tree, when I have been controlling our PDM link fron Default\PDM. Default does have Default\Project, but none of them show up in there.

      I have a couple use cases for Projects: 1. Internal Development 2. External Collaboration

      I think I would want these 1. in Default, 2. in Private,<u> thoughts? I'm guesssing the template of the Project controls this? How do I even make a Project show up in the Default tree?</u>

      M
      22-Sapphire I
      MikeLockwood22-Sapphire I
      22-Sapphire I
      June 18, 2010
      Didn't know that the user needed Modify for the object (in PDM).

      I swear there is no more complex puzzle in Windchill than ACL's (and there are many). It would help if PTC published some type of guideline that really did list what each control did in terms of the user experience.

      Re Private vs. "regular" in terms of Domains, I remember struggling with understanding this. The choice shown below (from Editing from the Details of the Product or Library) controls what Domain tree that context inherits from. Using Private for some allows you to put most ACL's at the Org level, then make some Libraries / Products private in order to not have them inherit from Org level (reducing total ACL statements by 90%). It is in fact a very useful configuration - just not documented in any clear way by PTC (and not well-explained by our GSO person at the time or by tech support).

      [cid:image001.png@01CB0EC0.8CB51B20]
      R
      RussPratt8-Gravel
      8-Gravel
      June 21, 2010

      The user needs Modify permission on the object in PDM in order to "Check it out to a Project", this is after all a check out action. Modify is not required if the user is only going to Share to the Project.

      BTW, "sharing" is a very significant "Change Permissions" activity, as it results in potentially a very large new "audience" for the object. Hence the requirement to have "Change Permissions" permission.

      Also note that there is a preference which controlls whether or not the ad hoc "Manage Security" action is ever visible in PDM.

      Russ

      R
      RussPratt8-Gravel
      8-Gravel
      June 21, 2010

      Also, as to how to set Projects to be either "Private" or "Public", so that you can manage them in the desired domain tree...

      The Project "attribute": Access Group determines whether or not the Project is Private. (Unlike the nice simple selection in PDM contexts.) If you choose the value "Team Members Only", the Project will be Private, and it's domain controlled appropriately. If you choose the value "Default", the Project will be non-Private, and it's domain controlled under the Org Default>Project domain.

      Russ

      Show more replies
      Terms & ConditionsAccessibility statement