10

I developed a Managed Extension Package. When I try to install it or create a patch org for it, this fails with no error but the note to call Salesforce.

Support told me that it fails due to:

MyPermissionSet: Permission Create MyNamespace__MyChildObject__c depends on  
permission(s): Read ExtendedPackageNamespace__MyParentObject__c

From the error message it seems like the permission set is unable to assign a CREATE permission to a Master/Detail child object, because it misses a READ permission on its parent object.

BUT this is not true. MyPermissionSet contains READ access rights to this object. While packaging or installing this seems to get lost or ignored.

Can the reason for this be, that the parent object it is depending on, is no from my package but the package I am extending?

Improve this question
8
  • 1
    Does the package that you're extending have the same namespace in the target org as it does in the org you developed the extension in? If not, I'd suggest that would be the problem as technically the parent is a different object. Perhaps your extension is deploying the parent as well?
    – Matt Lacey ♦
    Oct 18, 2012 at 7:56
  • The base package I am extending has the same namespace in the dev org and an in the target org. The error happens in both cases: a) when I create a patch org in my dev org (in this case the base app must be installed automatically by Salesforce) and b) when I try to install my extension to an org where the base package already exists.
    – Robert Sösemann
    Oct 18, 2012 at 12:02
  • I don't have much experience with permission sets yet, but a couple of things to consider: Does this happen on all orgs you attempt to update or just one? Is it possible the permission set was modified on the target system (I believe they can do that with permission sets in managed packages).
    – kibitzer
    Oct 18, 2012 at 19:49
  • Also, on permission sets the docs say you can't include object permissions for a custom object in a master-detail relationship where the master is a standard object. This may apply also where the master is an object in another package - you may be the first person to ever try this.
    – kibitzer
    Oct 18, 2012 at 19:54
  • @kibitzer /Dan, (disclosed your identity; I am a fan since DF12;-) this sounds like a solution or at least a perfect explanation. I am curious what Salesforce Support team will answer. The base package is from our company as well and providing a generic document object which extension packages can enhance. As I learned instead of profiles one should provide app or role specific permission sets and bundle them in the package. If this is not possible PermSets would loose much of there power.
    – Robert Sösemann
    Oct 18, 2012 at 21:38

3 Answers 3

Reset to default
13

I'm a product manager at salesforce.com responsible for Permission Sets. I was able to reproduce this use case. We do intentionally block the setting of parent permissions if it's a standard object (Kibitzer is totally correct with this). I'm working through this use case with my team since this use case is directly related to a custom object from the base package instead of a standard object. Please stay tuned. Thanks for your patience!

Improve this answer
10
  • Hy Adam, I appreciate you sharing this here. After I removed the access rights to the base package's objects I was at least able to deploy. The installed permission sets on the target org were totally empty. Can you give a coarse timeframe on when we should expect a solution? Otherwise: can you think of a workaround for me to package any kind of permissions in a setting like this?
    – Robert Sösemann
    Oct 22, 2012 at 20:10
  • Hy Adam, in the partner portal I opened a case 08263938 for that. Should I post you reply there or close it?!!
    – Robert Sösemann
    Oct 22, 2012 at 20:18
  • Hi Robert - I checked with the team. We treat base packaged permissions the same as standard object permissions - they belong to someone else and as a result, providing access through an extension may invalidate a permission decision that was made with the base package or standard object. In other words, your permission set could enable delete on an object that is unintended for users of the base package. Ultimately, we need some administrator touch point so that they can make an informed decision whether to allow extension permissions to affect base/standard obj permissions.
    – Adam Torman
    Oct 24, 2012 at 17:39
  • 1
    I am currently looking for a workaround for you. One option that works is to use a lookup field instead of a master-detail with the base package object. The look up field can have master-detail attributes like be required and describe deletion behaviors; however, it doesn't require read on the parent object. As a result, the permission set installs but the admin ultimately needs to make the manual adjustment to allow read on the parent or the solution becomes irrelevant as the end user won't be able to do much with the child records without parent access.
    – Adam Torman
    Oct 24, 2012 at 17:41
  • 1
    Hi Robert - yes, that was one of the use cases we discussed. The concept of ownership isn't well established when it comes to the underlying components of a package. When it comes down to it, it's fairly arbitrary. We are discussing the installation flow and how it can be improved but it may be a ways out at this point before we get to this level of granularity.
    – Adam Torman
    Oct 24, 2012 at 22:42
6

Salesforce.com officially accepted this as a bug which can be tracked on their new Known Issues Site:

https://sites.secure.force.com/success/issues_view?id=a1p30000000SbMUAA0

A workaround is also described there.

Improve this answer
2

Not to hijack this post but a similar situation occurs when you define a permission set in your extension package where you assign object field permissions for sobject fields that originate in the base package.

After installation of the extension package in an org all your object field settings in the permission set are not copied. The only way around this is to define the permission set in the base package where the sobjects originate.

I don't know what happens when the extension package defines additional fields for the base sobjects and assign crud rights in a packaged permission set, haven't tried that combination yet.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .