Settings provide a single point of access to built-in administrative functions such as change password and to the settings of installed applications. It is available from the Settings option in the pull-down menu at the top of the page, or typically from the account home page.

The settings folder

Each settings page is a folder based on an aggregator, with links to built-in administrative functions and application settings. The default settings page arranged the links into four sections:

  • About me (reference "me")
  • Account administration (reference "account")
  • Applications (reference "app")
  • System administration (reference "system")

The settings page can contain links to any nodes, but it makes sense to have a single link for the settings of each installed application.

In addition, each settings area requires a bindings node, typically settings.advanced.bindings, which binds the reference "settings" to the settings folder. This bindings node is then inherited by the high-level package for the account, to provide navigation to the settings area.

Finding the settings page

The settings page for a user is calculated using the following steps:

  • Find the user's user node.
  • Find the user's account node.
  • Find the first high level package.
  • Find the "settings" binding on the high-level package.
  • If any of the above can not be found, return a system-wide defaults settings page, currently Settings (library.settings.DefaultSettings).
  • If no default settings page can be found, go to a built-in admin page which shows the built-in functions.

How settings are structured

Each settings page inherits from Settings (library.settings.DefaultSettings), which contains links to the built-in functions. Settings pages use a specialised page type Settings Aggregator Package (library.settings.SettingsAggregatorPackageType). Settings Aggregator Package is like a standard aggregator except:

  • The default layout and view are different.
  • The aggregator filters the nodes before displaying them.

There are two types of filtering. The built-in functions are accessed using a node redirect, with an additional field which describes what capabilities the user must have to access the built-in function (see Script User for a description of capabilities). The required capabilities field is used for filtering. For example, the Users shortcut has capabilities of "own-users maintain-users" which means that the current user must own or be able to maintain groups of users in order to see the Users shortcut node. The non built-in settings nodes are simply filtered on read authority, using a permission token.

Each account can have its own settings node, or will use Settings if it does not. The settings node should inherit from Settings and should use the Settings Aggregator Package, but can have its own layout. The standard layout has four sections (me, account, app, system), and uses icons or icons with popup links, but individual account settings pages can use different sections and styles if required.

If you want to change the view for the settings aggregator, it must include two columns which are used by the filtering process:

Settings script

Settings Script provides programmatic access to the settings area. The method getSettingsPackage() returns the settings folder for a user, or null if none can be found. The method setSettingsSection() inserts a link into the settings folder.

If applications want to redirect to the settings area, they should redirect to ${rootPath}app/settings.jsp, not to the node returned by getSettingsPackage().