Verify sObject read access before creating select lists from records #475
Conversation
|
**lurch: attach W-038904 |
| @@ -98,9 +128,9 @@ global with sharing class VOL_SharedCode { | |||
|
|
|||
| for (Volunteer_Shift__c vs : listVolunteerJobs[0].Volunteer_Job_Slots__r) { | |||
| SelectOption so = new SelectOption(vs.id, | |||
| (useDateTimeFixup ? vs.System_Note__c : vs.Start_Date_Time__c.format()) + | |||
| canReadDate ? (useDateTimeFixup ? vs.System_Note__c : vs.Start_Date_Time__c.format()) : '' + | |||
There was a problem hiding this comment.
@scottwarren-sfdo, I waffled on what to do here if the user does not have access to the date field and / or the number of vol needed field but do have object access. The shift name is not always included in the label, the date and conditionally the number of vol still needed make up the label (this is also used on personal site report hours). My gut reaction was just to return it anyway but technically they shouldn't see the data so I went with my 2nd thought here and just display the data if they have access. However, this could potentially lead to a list with no labels and ids only... Let me know your thoughts and or if you'd like to sync up on this.
There was a problem hiding this comment.
I agree with the position you took. If the user does not have access, we should not pass the data along. The resulting suboptimal UI is a result of a permissions misconfiguration.
|
Tracking W-038904 |
|
**lurch: attach W-037822 |
|
Tracking W-037822 |
|
@jjbennett - Did you mean to lurch the Robot WI to this PR? |
|
**lurch: detach W-037822 |
|
**lurch: attach W-038946 |
|
Tracking W-038946 |
|
Detached W-038904 |
|
**lurch: detach W-037822 |
|
Detached null |
1 similar comment
|
Detached null |
|
**lurch: attach W-038904 |
|
Tracking W-038904 |
|
**lurch: attach W-038946 |
|
Tracking W-038946 |
…tion/Volunteers-for-Salesforce into feature/jen-camp-access
Critical Changes
Changes
To enhance security for internal users and Site Guest Users, we’re verifying Read Access for Campaigns, Jobs, and Shifts when displaying lists on visualforce pages (like the jobs and shifts for reporting hours in personal sites and the internal mass edit volunteer hours.)
We don’t anticipate this change having any impact on your site because Read Access should already be granted to internal users and to Site Guest Users (Configure Object and Field Permissions in Public Access Settings (https://powerofus.force.com/s/article/V4S-Config-Object-and-Field-Perms)).
If you do notice that internal staff and/or volunteers are no longer able to view the expected records in list drop downs, please review the profiles assigned to the volunteer management staff to ensure that Read Access is granted for Campaigns, Jobs, and Shifts and review the steps for Site Guest Users in the Configure Object and Field Permissions in Public Access Settings (https://powerofus.force.com/s/article/V4S-Config-Object-and-Field-Perms) documentation.
If the problem continues, please open a support case or post to the Volunteers for Salesforce App group (https://powerofus.force.com/s/group/0F980000000CjjxCAC/volunteers-for-salesforce-app) in the Hub.
Issues Closed
New Metadata
Deleted Metadata