Changes between Initial Version and Version 1 of Public/Docs/CinnamonClientConfiguration


Ignore:
Timestamp:
Sep 11, 2019, 10:06:54 AM (11 months ago)
Author:
Administrator
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Public/Docs/CinnamonClientConfiguration

    v1 v1  
     1= Cinnamon client configuration
     2== Abstract
     3This documentation applies to Cinnamon Desktop Client plus (CDCplus) configuration which is maintained on the Cinnamon Server and deployed to the client.
     4
     5== How CDCplus configuration works
     6=== Concept
     7Earlier Cinnamon Desktop Client versions maintained client configuration in a file named {{{CinnamonDesktopClient.custom.config.xml}}} that was stored locally with the client.
     8
     9Since the introduction of CDCplus in 2018, the configuration is no longer maintained on the client, but on the server. All configuration is stored in the metadata of an object named {{{_client_configuration}}} inside the Cinnamon path {{{/system/config/client_configuration}}}.
     10
     11This object can contain multiple sets of configuration that will be deployed depending on the user's group membership or superuser privileges. It is possible to assign individual configuration to a single user. In any case, there must be a default that is assigned to all users not matching any of the specific configuration sets.
     12
     13CDCplus itself contains an //emergency configuration// that is loaded whenever no server-based configuration can be deployed for whatever reason. This can happen when a legacy system is accessed with CDCplus for the first time or when a superuser has somehow misconfigured the server-based configuration. The emergency configuration allows a superuser to fix the configuration and restore a working state for all users.
     14
     15=== Assigning configuration to users
     16The metadata inside the {{{_client_configuration}}} can be accessed with the //Edit metadata// tab in CDCplus. The exact permissions on this object are subject to ACL configuration and assignment. Generally, only superusers or selected users who are responsible for configuration changes should be allowed to modify the configuration. To use the client, only read access to the object is required.
     17
     18The metadata has the following, general structure:
     19
     20{{{
     21<meta>
     22  <metaset type="client_configuration" id="52146">
     23    <cinnamon_client>
     24      <match>
     25        <default />
     26      </match>
     27      ... configuration ...
     28    </cinnamon_client>
     29    <cinnamon_client>
     30      <match>
     31        <superuser />
     32      </match>
     33      ... configuration ...
     34    </cinnamon_client>
     35    <cinnamon_client>
     36      <match>
     37        <group sysname="test" />
     38      </match>
     39      ... configuration ...
     40    </cinnamon_client>
     41    ... further group based matches ...
     42    <cinnamon_client>
     43      <match>
     44        <user name="john.doe" />
     45      </match>
     46      ... configuration ...
     47    </cinnamon_client>
     48    ... further user based matches ...
     49}}}
     50
     51The following rules apply:
     52
     53* There **must** be **one** //default// match.
     54* There **may** be **one** //superuser// match.
     55* There **may** be any number of //group// matches.
     56* There **may** be any number of //user// matches.
     57
     58Matches are applied in the following order:
     59
     60* If no configuration object can be retrieved, or if the configuration object is invalid, emergency configuration is returned.
     61* Next, user matches are tried.
     62* Next, the superuser match is tried.
     63* Next, group matches are tried.
     64* If no match was found, default is tried.
     65* If no default is found, emergency config is returned.
     66
     67== Structure of the cinnamon_client element
     68=== Root structure
     69The {{{cinnamon_client}}} element has the following structure:
     70
     71{{{
     72<cinnamon_client>
     73  <match>
     74    ... match definition ...
     75  </match>
     76  <global_settings>
     77    ... some basic client settings ...
     78  </global_settings>
     79  <classes>
     80    ... all libraries and classes that are used
     81    inside the client, and their configuration ...
     82  </classes>
     83  <menu>
     84    ... context menu structure, referencing classes
     85    that were defined inside the classes element ...
     86  </menu>
     87</cinnamon_client>
     88}}}
     89
     90=== Structure of the global_settings element
     91The {{{global_settings}}} element has the following structure:
     92
     93{{{
     94<global_settings>
     95  <culture_name>en-US</culture_name>
     96  <log value="false" />
     97  <branching allow="false" />
     98</global_settings>
     99}}}
     100
     101* {{{culture_name}}} defines the client satellite libraries to load. The content of the element must be one of the valid satellite library language codes. The default is {{{en-US}}} (if no {{{culture_name}}} element is provided). Currently, apart from English, only German ({{{de-DE}}}) is fully supported. There is limited language support in French and Dutch, which can be completed, or other languages can be added, if needed. If no {{{culture_name}}} element is present, the user's language setting configured in the user account is used. 
     102
     103* {{{log}}} may have the values {{{true}}} or {{{false}}} in the {{{value}}} element. {{{true}}} causes a log to be written into the temp folder, named {{{Praties_<timestamp>.log}}}
     104
     105* {{{branching}}} may have the values {{{true}}} or {{{false}}} in the {{{allow}}} element. {{{false}}} disables operations that will cause a branch on client side.
     106
     107 > **NOTE:** This does not disable branching on server level. Also, branching can be enabled or disabled, depending on the configuration deployed to the client, and thus by user role. 
     108
     109=== Structure of the classes element
     110The {{{classes}}} element has the following structure:
     111
     112{{{
     113<classes>
     114  <default_window assembly="CinnamonEnterpriseClient" type="EnterpriseClientMainWindow">
     115    <path>/</path>
     116  </default_window>
     117  <content_awareness>
     118    <content id="dita">
     119      <implementation assembly="ContentAwareness" type="XmlContent" />
     120      <format_filter>dita</format_filter>
     121      <format_filter>ditamap</format_filter>
     122      <custom>
     123        <children>
     124          <xPath>//@href</xPath>
     125          <xPath>//@conref</xPath>
     126        </children>
     127      </custom>
     128    </content>
     129  </content_awareness>
     130  <session_extensions>
     131    <session_extension key="icon_service" assembly="CinnamonEnterpriseClient" type="DefaultIconService" />
     132    <session_extension key="cec.basichookcontainer" assembly="CinnamonEnterpriseClient" type="BasicHookContainer" />
     133  </session_extensions>
     134  <session_window assembly="CinnamonEnterpriseClient" type="EnterpriseClientMainWindow">
     135    ... session Window configuration ...
     136  </session_window> 
     137  <tab_controls>
     138    ... tab controls configuration ...
     139  </tab_controls>
     140  <functions>
     141    ... context functions configuration ...
     142  </functions>
     143</classes>
     144}}}
     145
     146==== The default_window element
     147The {{{default_window}}} element allows the definition of one window to be opened opened whenever a session is created. Different user groups can have different default windows.
     148
     149> **NOTE:** Future CDCplus versions will allow to define multiple windows. Since opening a window requires several calls to Cinnamon to retrieve the data to display, and thus takes a few seconds, not too many windows should be configured.
     150
     151The {{{path}}} element's content defines the Cinnamon path to the folder to be shown. Example: {{{/Documentation}}}.
     152
     153==== The content_awareness element
     154The {{{content_awareness}}} element contains configuration of content awareness modules. Content awareness modules are classes that can handle certain data and can be assigned to one or more formats.
     155
     156Only formats that can contain either references to other objects (like XML or SGML), or that are subject to client-based custom processing on inbound and outbound operations need a content awareness module. Most formats, like pictures and PDF, do not normally need explicit support.
     157
     158> **NOTE:** The documentation for content awareness will follow. The existing configuration as shown in the example describes referencing in DITA and should not be changed, unless a future DITA release has a different data model, or unless custom behaviour should be achieved.
     159
     160It is possible (and encouraged) to develop new content awareness modules that support other referencing file formats. For example, Microsoft Office adaptors that support image and hyperlink references are possible.
     161
     162==== The session_extensions element
     163The {{{session_extensions}}} element contains the definitions of session extensions. A session extension is a class that's instantiated when a session is created. The instance is attached to the session and is available anywhere inside  the client.
     164
     165Session extensions can be used to provide functionality that should be globally available to standard and custom functionality.
     166
     167Two session extensions are defined by default:
     168
     169* The default icon service which deploys icons inside object lists and elsewhere. Implementing a custom icon service allows displaying individual icons by any available parameters of an object, for example lifecycle state, content format or object type.
     170* A basic hook container provides methods that are called on the client before and after lifecycle change. Other hooks can be added. The basic hook container has empty methods. To implement custom functionality, a custom hook container must be programmed and linked in the configuration.
     171
     172Other session extensions can be added as required.
     173
     174==== The tab_controls element
     175The {{{tab_controls}}} element contains the definitions of all tab controls that are available in the upper and lower right portion of the CDCplus main window. In a typical client configuration, there are 20 or more tab controls defined.
     176
     177Not all tab controls are shown on every selection, since many of the tab controls are bound to specific situations, object types, formats or other parameters. There are, for example, specific tab controls for creating search definitions or managing translation tasks.
     178
     179As with functions, session extensions, content awareness modules and other entities, tab controls are bound into the client just by configuration. It is therefore possible to program your own tab controls and add them to the client.
     180
     181A minimal {{{tab_control}}} element looks like this:
     182{{{
     183<tab_control assembly="Praties" type="PermissionFolderControl" display="list" />
     184}}}
     185
     186The {{{assembly}}} and {{{type}}} attributes define from which program library the tab control must be loaded and what its name is. The {{{display}}} attribute determines whether the tab control will show:
     187
     188* in the upper right area (value: {{{tree}}})
     189* in the lower right area (value: {{{list}}})
     190* in both areas (value: {{{all}}})
     191
     192The {{{tab_control}}} element shown above binds the control exposing the permissions on a folder into the client. Whether the tab control is shown or not depends on the return value of a method inside the tab control. That means, the tab control decides itself by the rules the programmer provided, whether to show up or not. In this case, the rule is to show whenever a folder is selected, and to hide when the selection is an object.
     193
     194The above example is a tab control that has no configurable parameters and therefore, the {{{tab_control}}} element has no configuration inside. Most tab controls are configurable.
     195
     196===== Configuration of tab controls
     197* [wiki:Public/Docs/CinnamonClientRelationsTabControl Relations tab control]
     198* [wiki:Public/Docs/CinnamonClientContentsTabControls Contents tab controls]
     199
     200
     201==== The functions element
     202The {{{functions}}} element contains the definitions of all context functions that are available for objects, folders, lists of objects and / or folders, and the session.
     203
     204Basically, the configuration works much like the configuration of the tab controls. The {{{functions}}} element contains a list of {{{function}}} elements, where each one configures a context function that's available in the program.
     205
     206Functions can be triggered by the following:
     207
     208* The context menu that must be configured in the menu section of the configuration.
     209* Key events, as configured in the tab controls.
     210* Buttons in a button bar at the top of the window.
     211* Drag & drop events, asc configured in the tab controls (drag & drop is not yet functional).
     212
     213The following example shows two function declarations, one without and one with parameters:
     214
     215{{{
     216<function assembly="Praties" type="CancelCheckoutObjectFunction" />
     217<function assembly="Praties" type="CheckinObjectFunction">
     218  <custom>
     219    <default_versioning_behaviour checked_out_file="write" other_file="write" />
     220  </custom>
     221</function>
     222}}}
     223
     224=== Structure of the menu element
     225Declaring a function in the {{{functions}}} element does not, by itself, add the function to a menu, nor link it with any other type of control. These connections must be made separately.
     226
     227The {{{menu}}} element describes all context menus available.
     228
     229The Cinnamon client has four different context domains:
     230
     231* single objects
     232* single folders
     233* the session
     234* lists of objects and / or folders
     235
     236All four domains have independent menu definitions. Since some functions provide functionality for more than one domain, it is common to reference the same function in more than one menu.
     237
     238A menu declaration looks like this:
     239
     240{{{
     241<menu>
     242  <object_context_menu>
     243    <menu_item assembly="Praties" type="CheckoutObjectFunction" />
     244    <menu_item assembly="Praties" type="CheckinObjectFunction" />
     245    <menu_item assembly="Praties" type="CancelCheckoutObjectFunction" />
     246    <separator />
     247    <menu_item assembly="Praties" type="OpenObjectFunction" />
     248    <menu_item assembly="Praties" type="CopyNameToClipboardObjectFunction" />
     249    <menu_item assembly="CinnamonEnterpriseClient" type="CreateNewVersionFunction" />
     250    <menu_item assembly="Praties" type="AppendContentObjectFunction" />
     251    <separator />
     252    <menu_item assembly="Praties" type="ExportObjectFunction" />
     253    ...
     254  </object_context_menu>
     255  <folder_context_menu>
     256    <menu_item assembly="Praties" type="CreateObjectWithoutContentFolderFunction" />
     257    ...
     258  </folder_context_menu>
     259  <list_context_menu>
     260    <menu_item assembly="Praties" type="CancelCheckoutListFunction" />
     261    ...
     262  </list_context_menu>
     263  <session_context_menu>
     264    <menu_item assembly="Praties" type="NewFolderSessionFunction" />
     265  </session_context_menu>
     266</menu>
     267}}}
     268
     269The four domains are defined in the {{{<domain>_context_menu}}} elements. Menu items are declared in the order they should have in the menu. It is possible to add separators as required.
     270
     271> **NOTE:** The functions that are declared do not necessarily all appear in the menu on every selection. The functions have methods informing the client (based on the current selection) whether they should be displayed or not, and whether they should be active or inactive ("greyed out"). This behaviour is normally not subject to configuration, since functions are made for a specific purpose and context, and refuse to be used outside of their specification. For example, a "cancel checkout" function makes no sense on objects that are not checked out, and is therefore not active.