Document and PushTopic standard objects missing

176 views
Skip to first unread message

aho...@gmail.com

unread,
Feb 19, 2017, 12:01:52 AM2/19/17
to Illuminated Cloud Q&A
Is there any particular reason why these objects don't appear and so can't be selected when subscribing to metadata?  Without subscribing to them, retrieved permissionsets and profiles don't contain their object permissions.

Thanks,
Al

Scott

unread,
Feb 22, 2017, 4:39:40 PM2/22/17
to Illuminated Cloud Q&A
Al, again sorry for the long-delayed response.  Document absolutely should be included in the subscription editor.  I'm definitely seeing it in my orgs:


I include that metadata type in the subscriptions for several of my own projects.  As for PushTopic, it looks like it's not being included because it isn't a metadata type; it's an SObject type.  As a result, it's not part of the response to MetadataApi.describeMetadata().  This is consistent with what I see when I look at the metadata types in Workbench:



Regards,

Scott Wells

aho...@gmail.com

unread,
Apr 7, 2017, 11:58:09 AM4/7/17
to Illuminated Cloud Q&A
Hi Scott, 

Just now returning to this issue once again as I have a little more information I'd like to share and also a request.  We use a tool called Gearset for deployments between orgs and it works by comparing a source org or a set of metadata files from a Git repo with a destination org and then gives the option to deploy any differences - either selectively or automatically.  The problem is it keeps reporting that permissions for the Document and PushTopic standard objects are missing from my source Git repo profiles and permissionsets.  They informed me that although Document and PushTopic are different than other standard objects, they are still standard objects that have permissions like the others. Further, if these objects are included in the package.xml within the CustomObject type section (not a separate metadata type, i.e. Documents) for a metadata retrieve operation, the permissions for those objects come back in all profiles and permissionsets.  Also, the permissions are listed on the same page as other objects in Salesforce here: 
The problem I am having is that there is no way to specify these CustomObject types in Illuminated Cloud's metadata subscription selections. And unless they are specified there is no way to get these permissions to be retrieved into profile and permission set metadata.  I could use a predefined package.xml but then my team is forced to keep that file manually updated and I think that will result in a lot of errors and lost time.  So my request is that Illuminated Cloud can somehow allow these 2 objects to be selected in the metadata subscription selections within the Configure Module... and Retrieve Metadata... dialog boxes.

Thanks,
Al Hotchkiss

Scott

unread,
Apr 7, 2017, 12:01:55 PM4/7/17
to Illuminated Cloud Q&A
Hey, Al.  That's a totally reasonable request.  If those are valid entries for the CustomObject metadata type during metadata API deployment and retrieval, I have zero problem supporting them.  It's definitely odd that they're not returned by MetadataAPI.listMetadata("CustomObject"), but it wouldn't be the first time there was a one-off in the Salesforce APIs like this!

Let me verify that including them doesn't introduce any other issues.  Once that's verified, I'll just explicitly add them to the list of values that can be selected for the CustomObject metadata type when configuring your subscription.

Would you mind logging an issue in the public issue tracker that I can use to track this?

Regards,
Scott

aho...@gmail.com

unread,
Apr 7, 2017, 12:05:48 PM4/7/17
to Illuminated Cloud Q&A
They are odd in that the retrieve operation does give the following messages when they are included in package.xml but the operation still succeeds:

[sf:retrieve] package.xml - Can't retrieve non-customizable CustomObject named: PushTopic
[sf:retrieve] package.xml - Can't retrieve non-customizable CustomObject named: Document

Reply all
Reply to author
Forward
0 new messages