sfpowerkit:source:profile:retrieve does not retrieve permissions if object_api_name == field_api_name

[busybox0]

Describe the bug Let's imagine we have object named aaa__c with 10 fields including bbb__c, and object bbb__c with own 10 fields including field named aaa__c.

field aaa__c.bbb__c is of type Lookup(bbb__c) field bbb__c.aaa__c is of type Lookup(aaa__c)

running sfdx sfpowerkit:source:profile:retrieve -n 'Admin' -u user1 will omit all fieldPermissions, layoutAssignments, recordTypeVisibilities, tabVisibilities related to object aaa__c (none of 10 fields, recTypes etc are visible).

Only objectPermissions for aaa__c object is visible.

On the opposite side, the object bbb__c with field aaa__c will have all it's fieldPermissions, layoutAssignments, tabVisibilities retrieved, with exception of field aaa__c.

Expected behavior All fieldPermissions, layoutAssignments, recordTypeVisibilities, tabVisibilities related to object aaa__c are retrieved; all fields named aaa__c are retrieved from any objects including object bbb__c.

Desktop:

• OS: WSL Ubuntu / Windows
• sfdx-cli/7.154.0 wsl-x64 node-v14.17.6
• Version of sfpowerkit 4.2.8

[Caitlyn-Mills]

Thanks for raising this. Let me look more into it and get back to you.

[genoud]

@busybox0 I was not able to reproduce this. If this behavior is happening, it might not be due to field/object api name.

[busybox0]

Thanks Genoud. The issue is really tricky to reproduce, I'll try to craft a dummy project for scratch org to reproduce it, Will share it once ready.

[busybox0]

Leaving the only mentioned pair of objects in example scratch org didn't reproduce the issue. Though, it's still reproducible in real project. Trying to pinpoint it and make a sample project. It needs time though.

Budget_transaction_item__c.Payroll_Component__c is a key phrase for future investigations and crafting a test project.

[Caitlyn-Mills]

Thanks @busybox0 if you are able to reproduce this somewhere else I can look into it.

[busybox0]

it's hard to pinpoint it in sample project and provide for debug. Seems that dependencies are not just as was initially stated. In real project we are always controlling what happens with profiles by looking into git diff. Maybe it's worth closing this one as something like "not reproduced"