Permissions Release (deployed 8/14/2020)

IMPORTANT NOTE: The permissions changes outlined below require review and adjustment of all Roles to ensure users can complete their work. Contact ShotFlow support if your Admin users need assistance adjusting existing Role permissions.

What’s New?

• Additional permissions granularity. This release focuses on additional permission controls that provide greater granularity when defining Roles. These permission changes are:
  • Create record. This new permission was split from the prior create/update record. Now a Role can be granted the create record permission independently of other record-related permissions.
  • Clone record. This new permission was split from the prior create/update record permission. Now a Role can be granted the clone record permission independently of other record-related permissions.
    
  • Update record. This new permission was split from the prior create/update record permission. Now a Role can be granted the update record permission independently of other record-related permissions.
  • Export view. This new permission was split from the existing manage view items permission. Now a Role must be granted the export view permission independently of other view-related permissions. Note that users with other View-related permissions will no longer see the Export View menu option unless this permission is added to their Role.
  • View Data Ingest configurations. This new permission was added to enable a Role to have visibility to Data Ingest configurations independently of the permission to create/update those configurations.
  • Access Mobile application. This new permission was added to control which Roles can access ShotFlow via the Samples & Styling Mobile App. This is the similar to the existing access capture module permission but is specific to the iOS Mobile App.
  • Update relationship lookups. This new permission was split from the existing create/update relationships permission. Now a Role can be granted the permission to update the related record lookups (the fields used when viewing/managing related records) independently of managing the underlying table-to-table relationships.
  • Manage Protected Views. This new permission was added to address a new feature (see below) enabling Views to be designated as protected, in order to prevent deletion of those Views by another user.

• Protected Views. Similar to protected fields, a View can now be designated as "protected" by a user with the appropriate permission, which prevents deletion of the View by users with the "Delete View" permission. Protected Views display a "lock" icon in the UI to identify them. This is primarily to protect Views that are utilized for reports, data export, external automations, and other mission-critical workflows.
• View visibility to equal or higher Roles. Views created by a Role will now be visible to Roles with equal or higher permissions by default. This enables Admin roles to have visibility to Views created by others in order to manage visibility of those Views by other Roles.

What Did We Fix?

• Views in reports do not apply saved searches. When including a View in a Report, it should include a saved search (if present) to show the same results as the Table View. This was fine at one point, then not fine. Now, fine again.
  
• Pagination support to charts and reports including while searching. Pagination! All the cool tools are doing it these days.
  
• Materialized Views improvements. What are materialized views, you ask? Why, they are magic tricks to increase performance in very complex databases like this one! Suffice to say, enjoy the speed and don't worry too much about what's under the hood.
• Querying a uuid field with an invalid uuid value not displaying the correct error. Any user who actually experienced this prior the fix, please contact us for a special prize, because you are really committed.
• Data ingest functions incorrectly parsing characters in data for a given value. Don't ask. It's just better not to know.

What Did We Change?

• When a view is created it is now added to all roles with equal or more permissions of the user who created the view. This is to help Client Admins keep track of Views created and manage their visibility in other Roles.
• Logic for verifying the uniqueness of value in unique fields overhauled and optimized.
• A search which contains “All Fields” can no longer be saved to a View. This is to improve system performance, as "all fields" searches are resource-heavy. In many cases the same results can be achieved by defining multiple Advanced Search criteria or using a saved List Search.