Profiles & Layouts
Profiles and layouts are a fundamental aspect of Dime.Scheduler. Giving users the possibility to create personalized workspaces is part of what makes the application so powerful and flexible. It also stimulates collaboration as profiles and layouts can be shared among users and user groups.
A profile contains all the settings that are necessary to recreate the user interface and apply subsequent behavior after initialization. It is a snapshot of the planning view's structure. Many settings are stored, including, but not limited to:
- Color
- Theme
- Sidebar menu collapsed state
- Dock panels and their position, width, height and the default layout of the component that is contained inside
- Planning board presets
- Map presets
- ...and many more
On the other hand, layouts are tightly coupled to components. In fact, layouts are snapshots of components. They contain the necessary data to create templates of a given component, so it can be used by other users or in other profiles. Many settings are stored, including, but not limited to:
- Column selection
- Column width
- Sorting
- Filtering
- ...and many more
It is important to understand that layouts and profiles do not store transactional data. Instead, they store the settings that make sense for that component or profile. In that regard, profiles and layouts are very similar but, as we will see, they have a different scope and context.
Layouts versus profiles
At first glance, profiles and layouts look very similar, but they serve two different functions. A profile is a snapshot of the planning view whereas a layout is a snapshot of a single component in that view. Thus a layout has a much smaller scope: it is usually concerned with settings of the components like the column selection, sorting, filtering, etc.
This is visualized in the example below: the area with the red border is profile territory whereas the blue area is managed by layouts:
The only time when layouts are relevant to user profiles is during profile initialization. That is because users can mark default layouts for their components in the profiles:
A default layout is the glue between profiles and layouts: without it there would be no meaningful connection between the two. The existence of default layouts forces Dime.Scheduler to keep track which components have default layouts for which profiles. When a profile is loaded, the (optional) default layouts are applied. In the absence of a default layout, the component will fall back to the standard layout that was defined by Dime. Similar to the profiles, users can always modify the settings of the components (or even load other layouts) during the session.
To reiterate once again, a layout is scoped down to a single instance of a component. This means that every individual component in the view can have its own settings; no matter how many other instances of the same component are stored in the profile. It is not uncommon to have multiple open task grids in the profile with different filters, for example to divide the data by region or customer, order status, etc.
Because layouts are snapshots of components, they can be reused in other profiles. They can even be used by other users in their own profiles. In fact, any kind of combination can be made between layouts and profiles. Profiles document what components are captured, where they are positioned in the view and which default layouts are defined. This concept is depicted in the little schema below. The left column shows the layouts grouped by component type, the right column shows the contents of two profiles; whose contents are also grouped by component type.
Layouts and profiles are stored in two different data stores. There's a catalog of profiles and a catalog of layouts. In this example, the planners have defined a few layouts for the open and planned tasks components to show records from the EMEA region and the LATAM region. In the second profile (orange), not all components have a default layout. Dime.Scheduler will apply the standard layout for the details, map and notification components.
This system is powerful and efficient because it allows you to reuse settings across profiles and users. Instead of loading the layout every time you start Dime.Scheduler, it is much more efficient to flag this record as the default layout for this profile.
When this profile is applied, the 'Tasks LATAM' layout will automatically be applied for this component instance. This exercise is done for every other component in the profile. If you decide to create a new profile, you'll be able to use the layouts you created earlier (and the ones who are shared by other users).
Users versus profiles
It is important to understand the difference between a user and a profile, and the relationship between the two. As explained here, a user is the physical person who operates the application 3.
One of the artifacts a user can produce is a profile. A profile is nothing more than a workspace that the user can configure to tackle a certain planning scenario. In some cases it may be even useful to get rid of a few components while adding others to the workspace, and apply different filters. Instead of having to reconfigure this workspace every time the application is launched, users can opt to save the workspace along with a set of other settings to a profile.
It is important to know that security filters are applied to the user that is using the profile, not the profile itself. Thus, the profile is a template which is executed in the context of a user session. What the different users of that profile will get to see is determined by their security clearance.
Authorization
Manage layouts and profiles
Not everybody can create, update, delete and load profiles. For starters, users need to have access to the "Personalization" user action to be able to store profiles and layouts. When this user action is missing in all of his roles, the user will only be able to load layouts.
Even when a user is authorized, he will only see the profiles that were shared either publicly or with a user group that he is a member of. Profiles other than the ones that he created cannot be overwritten (or deleted), but they can serve as the basis for a new profile. It is like trying to save a read-only Word document: saving the document is only possible by storing it as a new document.
Data
Even though profiles and layouts can be shared, this doesn't mean the authorization levels are shared. The data-driven security and role-based access control mechanisms are still in place. Profiles and layouts are merely concerned with settings which ensure a consistent look and feel but it doesn't get involved in the process of deciding which data the user will actually get to see and what he'll be able to do with it.
Read more
- A user can also be a fictional entity to represent a piece of software that interacts with Dime.Scheduler programmatically.↩