Apex Code Development You need to sign in to do that
Don't have an account?
CRMfusion - GW Creating new accountShare objects
If I create a new AccountShare object on a an account for a user that already exists with sharing on that account it seems that the original share is removed.
In the case that I'm working on the share that I'm "Cloning" has a lower level of access than the current share and is therefore removing access rights from the exisint user.
Is this by design?
Will a new share for an existing user always UpSert an existing share?
Can this be changed?
GlennW
In the case that I'm working on the share that I'm "Cloning" has a lower level of access than the current share and is therefore removing access rights from the exisint user.
Is this by design?
Will a new share for an existing user always UpSert an existing share?
Can this be changed?
GlennW
What would be the use case for changing this?
Either you are granting more access, or removing access, right?
Thanks for your responce.
The process I'm working on is merging AccountShare objects when Accounts are merged. For most other objects that can not be reparented I simply clone the object and insert a new objects associated with the Account. This works great for Attachments and Notes as they are simply recreated.
Sharing becomes an issue as I don't want to remove rights from the share owner. Therefore, I will need to check for the existance of the share for that user and only insert it if it does not exist for that user.
As a wishlist item it would be great if I could set a flag that would allow for shares to be Overwritten, Merged with highest rights winning or Ignored.
Thanks;
GlennW
Will your MergeAPI call merge all objects or just the top 3 (Leads, Contacts, Accounts)?
The same problem presents itself on OpportunityShares plus we have found internally that deduping and merging custom objects to be very usefull as we are starting to see the start of an "AppExchange Object Duplicate" problem.
When your merge call comes out it would be great if you could allow for the control of:
- What child objects are merged
- Field control on an object basis
Regards;
Glenn Wilson
The custom object idea is good.
You would be supprised at the number of child objects that people don't want to bring over. In most cases it involves around sharing but it could involve a custom objects that should never move. The bigger issue is that when you look at the meta data you'll see that a Lead is a child object of an Account. Most people would not want to clone the converted lead but there will be cases that it will have to be kept for future analytics. Because the available objects to merge (clone or reparent) comes from the describe call we need to make sure that the user has control over the non-intuitive objects.
Cheers;
GlennW
A merge API would be a wonderful feature for us. In our case, we could want all related child objects merged to the parent, including any archived activities.