You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each WFO-based user of the CMS is going to have permissions at some level for multiple WFOs to provide emergency backup to their neighboring offices if/when needed. However, those instances will be rare, and their day to day operations will simply involve updates to their primary WFO.
Current state
Using the taxonomy structure of Region > WFO and the Workbench Access module we have the ability to:
Associate content with a single WFO
Grant users permission to access content for multiple WFOs
However, there is no distinction made between a user's primary WFO and the neighboring offices they have permissions for.
Future state
Whether through changes to the existing taxonomy or through other means, we want the ability for the system to understand that each user may have access for multiple WFOs, but most will have one primary WFO. Making this distinction will allow us to organize and display content based on a user's primary WFO (work captured in another ticket).
One idea discussed would be to update user profiles to allow system admins to assign a primary WFO to each one.
The text was updated successfully, but these errors were encountered:
I think what we can do is define this as part of the user profile as a setting users can set. We can then use this setting to add a filter for what the user can see in their content dashboard.
Background
Each WFO-based user of the CMS is going to have permissions at some level for multiple WFOs to provide emergency backup to their neighboring offices if/when needed. However, those instances will be rare, and their day to day operations will simply involve updates to their primary WFO.
Current state
Using the taxonomy structure of Region > WFO and the Workbench Access module we have the ability to:
However, there is no distinction made between a user's primary WFO and the neighboring offices they have permissions for.
Future state
Whether through changes to the existing taxonomy or through other means, we want the ability for the system to understand that each user may have access for multiple WFOs, but most will have one primary WFO. Making this distinction will allow us to organize and display content based on a user's primary WFO (work captured in another ticket).
One idea discussed would be to update user profiles to allow system admins to assign a primary WFO to each one.
The text was updated successfully, but these errors were encountered: