This documentation is for XNAT versions 1.6.0 - 1.6.5. You can find the latest documentation for XNAT 1.7 at https://xnat.org/documentation
XNAT developers and module developers should be able to define new features and allow access to sections of the application based on those features. SIte Administrators should be able to restrict or grant access to features on a site-wide basis, group-type basis (owners vs members), or specific project basis.
Features are registered in XNAT via properties files which are loaded by XNAT on server startup (or first access). The server will look for any files which end with *-feature-definition.properties. All features which are automatically a part of XNAT should be defined in the xnat-feature-definition.properties file. Features developed for specific modules should be defined using a unique string in the properties file name.
Within any feature definition file, any number of features can be defined using the following format:
org.nrg.Feature.[key].key=[key: used to identify this feature throughout the application]
org.nrg.Feature.[key].name=[Human readable name that will be used to identify this feature within the UI]
org.nrg.Feature.[key].OnByDefault=[true: this feature will automatically be on for all users, unless disabled by the admin, false: this feature will need to be enabled by an admin or project owner for it to be usable on the site]
org.nrg.Feature.[key].description=[sentence or two describing this feature ]
The most important part of the feature definition is the key. This will be used behind the scenes to identify the feature and control access.
Once a feature has been defined in a properties file, access to sections of the application can be restricted based on user membership to that feature. There are two supported methods for restricting access by features.
Option 1: Action definitions: The Data Types Registry in the Administration section has been modified to allow restriction of data-type actions by registered features.
Option 2: In source code: Developers can specifically control access to features in the source code. The User object has a method called 'checkFeature(ItemI item, String key)'. Developers can restrict access by using code like this:
<div>some content of varying complexity</div>
Access to features is restricted based on user membership in groups, which are in turn associated with projects. In order to know if a user can access a feature, XNAT needs to know the project for that feature. The $om object should be a project, subject, or experiment. XNAT will review the projects (primary and secondary) for the object and return true if the user has access to that feature for any of them.
Once features are registered in XNAT, Site administrators and project owners will be able to manage access to them.
Site Administrators have final authority over which features are usable in there site. In the Administer -> Configuration -> Features section, administrators can 'ban' features from there site. If a feature is banned, this supersedes all other specifications and the feature will not be usable by any users of the site.
Site Administrators also have the ability to set features to 'On By Default'. If this is marked true, then all users of the site will automatically have access to this feature (unless blocked by specific group specifications).
Site administrators can also control access to features based on group types. Site administrators can grant access or block access to specific features for certain user types (Owners vs Members vs Collaborator vs Custom Group 1 vs Custom Group 2).
Project owners can grant or block access to specific features based on the groups which are a part of their server. These permissions will supersede site wide settings and allow project owners to define specific permissions for users of their projects (except banned features).