-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BDI/BGE: Update FLS to check only populated fields for DI & target objects #4155
Conversation
*/ | ||
private static List<String> getCoreDataImportFields(Boolean includeRelationshipFields) { | ||
List<String> fields = new List<String> { | ||
'Id', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason that Donation_Amount__c, Donation_Date__c, and NPSP_Data_Import_Batch__c aren't included in this list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, these get added in by the getActiveFieldNamesFromBatch
method as these are always required and are also considered "selected" fields in the BGE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nm let's leave this alone
DataImportBatch__c currentBatch = dataImportBatches[0]; | ||
if (!String.isBlank(currentBatch.Active_Fields__c)) { | ||
relevantDataImportFields = BGE_BatchGiftEntry_UTIL.getDataImportFields(batchId, false); | ||
batchFromBGE = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Want to avoid references to "BGE" if we can describe this property more generically ... "batchDefinesActiveFieldList" or somethign
return dataImportBatches[0]; | ||
DataImportBatch__c currentBatch = dataImportBatches[0]; | ||
if (!String.isBlank(currentBatch.Active_Fields__c)) { | ||
relevantDataImportFields = BGE_BatchGiftEntry_UTIL.getDataImportFields(batchId, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the thing that made me the most uncomfortable about the original PR, but I am thinking we may be able to avoid it - applications calling BDI (like BGE) should ideally not be defining BDI behaviors, else we could build up all these conditionals and exceptions built in for each application that's calling into it. HOWEVER, I think we may be able to avoid this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ptewson-sfdo - Would moving this logic (along with other the field collection/map building) from the BGE util to the BDI_DataImportService class make sense? The one thing that immediately sticks out to me is that the getActiveFieldNamesFromBatch
method from BGE_BatchGiftEntry_UTIL
relies on the BGE_ConfigurationWizard_CTRL.BGEField
class. If the above is acceptable, would moving BGEField
into its own file make sense so we don't rely on the config wizard controller in BDI here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We believe we can pull the call to BGE_BatchGiftEntry_UTIL.getDataImportFields(batchId, false) entirely - these fields would only be used for FLS when the help text maps to a target object field and then the check would be on the target field. None of these fields have default mappings or map logically to target fields and would not be checked anyway, and we can remove an unneeded dependency on BGE by pulling this out.
/******************************************************************************************************* | ||
* @description flag to let us know if we came from BGE | ||
*/ | ||
global static Boolean batchFromBGE { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
avoid global!
* This list gets set in the loadBatch method. | ||
* If no batch is loaded, we use the full list of all DI fields listStrDataImportFields | ||
*/ | ||
global static List<String> relevantDataImportFields { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
avoid global!
…forceFoundation/Cumulus into feature/prince-bge-bdi-fls-bug-fix
&& allowedDataTypes.contains(dfr.type) | ||
&& !bannedFields.contains(dataImportFieldApiName) | ||
&& dfr.getInlineHelpText() != null) | ||
|| allowedFields.contains(dataImportFieldApiName); | ||
|| allowedFields.contains(dataImportFieldApiName)) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the call to "BGE_BatchGiftEntry_UTIL.checkFieldPermissions(filteredDFRMap.values());" below on line 223 redundant now, since the field has to be updatable to get in the map in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it is redundant as all the fields passed in will always pass. What do you think about the following scenario?
If a user without perms for a field (Campaign Source) accesses a DI Batch that has Campaign Source in its Opportunity Selected Fields... with this update they'll receive an error on the DI Batch page but still be able to click "Edit" and open the Config Wizard. The page will tell them they don't have access to field Campaign Source, the page will not render the New Gift form and not render the Gifts table. They'll still be able to open the Config Wizard, but Campaign Source will not be visible for them in the Opportunity Selected Fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what we discussed earlier today (Monday 4/8) right? I think this is ok, we may look to providing a more informative blocking message when trying to edit a batch with an inaccessible field, but this is great of this story.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I believe we should still remove the redundant call to "BGE_BatchGiftEntry_UTIL.checkFieldPermissions(filteredDFRMap.values());" on line 223-ish?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, exactly. Completely agree, I'll go ahead and remove the call to the BGE util
@@ -812,8 +826,8 @@ global with sharing class BDI_DataImportService { | |||
|
|||
if (failFieldLevelSecurity || | |||
fieldDescribe == null || | |||
!fieldDescribe.isCreateable() || | |||
(!isAuditField && !fieldDescribe.isUpdateable())) { | |||
(!fieldDescribe.isCreateable() && populatedDataImportFields.contains(dataImportField)) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
format this block's linebreaks a little more cleanly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
**lurch: attach W-030471 |
Tracking W-030471 |
This updates the way we handle FLS during the mapping phase of processing/dry-running. Previously we checked FLS on all the mapped fields. Now we'll run FLS only on fields that are actually being populated/otherwise being updated in the DI records. If any DI record in a Batch has a failing FLS check, then the entire batch is failed.
Critical Changes
Changes
Batch Gift Entry Enhancements
We updated how Batch Gift Entry and Data Import handle field level security (FLS). Before this release, a user would receive an FLS permissions error when creating a new batch in Batch Gift Entry when they didn't have edit access on all NPSP Data Import fields. Now, Batch Gift Entry only displays NPSP Data Import fields in the batch setup screen when a user has edit permissions on those fields.
In addition, we made it possible for an intern or a user with fewer security permissions on Opportunities or Payments to prepare a batch for processing by a gift entry manager or another user with more permissions. A user entering gifts must have access to the NPSP Data Import fields included in the batch. To process a batch, a user must have access to the fields on the NPSP Data Import object as well as the corresponding fields on Opportunities or Payments. For example, if your batch includes Donation Date (on the NPSP Data Import object) and that field maps to Opportunity Close Date and Payment Date, then the user must have Edit access to all three fields.
Issues Closed
New Metadata
Deleted Metadata