Skip to content
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

Merged
merged 23 commits into from
Apr 12, 2019

Conversation

psadie-sfdo
Copy link
Contributor

@psadie-sfdo psadie-sfdo commented Apr 1, 2019

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

@psadie-sfdo psadie-sfdo self-assigned this Apr 1, 2019
@psadie-sfdo psadie-sfdo requested a review from ptewson-sfdo April 1, 2019 20:05
@psadie-sfdo psadie-sfdo changed the title Feature/prince bge bdi fls bug fix [do not merge] Feature/prince bge bdi fls bug fix Apr 1, 2019
*/
private static List<String> getCoreDataImportFields(Boolean includeRelationshipFields) {
List<String> fields = new List<String> {
'Id',
Copy link
Contributor

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?

Copy link
Contributor Author

@psadie-sfdo psadie-sfdo Apr 2, 2019

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.

Copy link
Contributor

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;
Copy link
Contributor

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);
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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; }
Copy link
Contributor

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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoid global!

&& allowedDataTypes.contains(dfr.type)
&& !bannedFields.contains(dataImportFieldApiName)
&& dfr.getInlineHelpText() != null)
|| allowedFields.contains(dataImportFieldApiName);
|| allowedFields.contains(dataImportFieldApiName))
);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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

@psadie-sfdo psadie-sfdo changed the title [do not merge] Feature/prince bge bdi fls bug fix feature/prince bge bdi fls bug fix Apr 5, 2019
@psadie-sfdo psadie-sfdo marked this pull request as ready for review April 8, 2019 12:54
@@ -812,8 +826,8 @@ global with sharing class BDI_DataImportService {

if (failFieldLevelSecurity ||
fieldDescribe == null ||
!fieldDescribe.isCreateable() ||
(!isAuditField && !fieldDescribe.isUpdateable())) {
(!fieldDescribe.isCreateable() && populatedDataImportFields.contains(dataImportField)) ||
Copy link
Contributor

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?

Copy link
Contributor

@ptewson-sfdo ptewson-sfdo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@ptewson-sfdo
Copy link
Contributor

**lurch: attach W-030471

@LurchTheButler
Copy link

Tracking W-030471

@psadie-sfdo psadie-sfdo changed the title feature/prince bge bdi fls bug fix BDI/BGE: Update FLS to check only populated fields for DI process/dry-run Apr 10, 2019
@ptewson-sfdo ptewson-sfdo merged commit f791fc0 into master Apr 12, 2019
@ptewson-sfdo ptewson-sfdo deleted the feature/prince-bge-bdi-fls-bug-fix branch April 12, 2019 16:10
@melissabarber melissabarber changed the title BDI/BGE: Update FLS to check only populated fields for DI process/dry-run BDI/BGE: Update FLS to check only populated fields for DI & target objects Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants