4 posts tagged with "sdk"

• [Feature]: Return Messages now expose ExtendedText1, ExtendedText2, ExtendedText3, and ExtendedText4

• [Bugfix]: Remove duplicated tablerowstate attributes when manually specified
• [Bugfix]: Validated support for large document/async invocable functionality
• [Bugfix]: Resolved text serialization errors

Bug fixes and performance improvements. Beta test version of asynchronous call support.

• [Feature]: Id and number are added to return messages to identify record relations.
• [Feature]: Model generator supports class prefix
• [Feature]: New setting to use improved xml serialization
• [Update]: Async RIO processing (Beta)
• [Bugfix]: Missing apex classes added to permission sets
• [Bugfix]: Updated model generation templates for Salesforce Critical Update Type.newInstance in API 48+

The Salesforce Winter 21 release includes a breaking change​

The Restrict Access to AuraEnabled Apex Methods for authenticated users was a critical update included in the Winter 21 release that essentially require that a user be explicitly granted access to the Apex code that a front-end lightning component calls. Without making a security change to Salesforce the lightning components in salesforce apps (including enosix apps) can behave in strange ways including not displaying or looking like they are frozen.

Does it impact my organization?​

While this update affects all apps - not just enosix. But within your enosix apps, Surface v1.10 and later include the updated permission sets and are thus unaffected. All customers running an earlier version of Surface or any enosix product other than Surface are likely to see problems.

How do I fix it?​

The easiest way to correct the issue is to create a Salesforce permission set per app and add all of the Apex classes for that app to the permission set. The permission set can then be granted to each affected user who needs access to that app.

Below is an example for our Surface app, and this same workaround will work for other enosix apps, as well as apps from other salesforce partners and any custom developed app you may have in your org.

1. Create a Permission set​

• Setup > Quick Find, Enter 'Permission Sets'
• In the Permission Sets screen click on the New button it is in the list header.
• In the Label field enter a descriptive name - something like 'enosix Surface Winter 21 Security Patch'. (The best practice is to create a permission set per app to reduce access to apex code but in a pinch one permission set can be used for all your apps.)
• Click Save.

2. Add Apex Classes to the permission set​

• In the Permission Set screen click on the Apex Class Access Link. (Under Apps Section, fifth down from the top)
• In the Apex Class Access Table click the Edit button in the table header.
• There will be two list boxes, in the right one labeled Available Apex Classes, select the classes prefixed for the app your are correcting. For enosix Surface select all classes that start with ensxapp. (NOTE: for other enosix apps select ensxsdk, ensxafs, ensxb2b and any classes that start with the prefixes CTRL_, UTIL_, SBO_, or RFC_) . Other salesforce apps will have their own guidance on what prefixes or grouping to select.
• With the list entries selected click on the Add Button with the Arrow pointing to the Right >, the selected entries will be moved to the Enabled Apex Classes list box. It may take a couple of scans of the list to find all of the apex classes, and the add button can be used multiple times.
• Click on the Save Button.

3. Assign the permission set to users​

• Click on the Manage Assignment Button in the toolbar it is to the right of the Find Settings search box.
• In the Assigned Users screen click add assignments and in the list of users select the users who need access to the app by checking the box in the Action column.
• Click the Assign Button.
• The user permissions for the app should now be corrected for Winter 21.