4. Users, Roles and Repositories

One of the core concept of AjaXplorer is the « Repository« .  Basically, a repository can be seen as a virtual drive mounted to access a set of data. In most case, a repository will access a set of folders and files, locally or remotely via various types of protocol, but it can also be an access to other type of data, like a database content (MySQL repositories), or even the AjaXplorer configurations themselves (Settings repository). The way the files are accessed is defined when creating the repository, by choosing a « Driver » to map the data.

Repository is an important concept, as the rights to access a given set of data for one or more users is handled at a repository level. Thus, once you have created a repository, you will be able to grant read and/or write access to this repository to your users. You can assign these access individually, but you can also create « Roles », a set of right access, and then assign one or more roles to your users.

The « Settings » repository is a specific one that is only accessible by administrator users (default admin/admin at startup, but you should have changed the password already), and allows you to manage repositories, users and roles via the GUI.

Repositories Management

Defining Access Driver

A repository is defined by two things : the « driver » used to access the data (local filesystem, remote ftp server, database, etc…), and the configuration of this driver (the local path to the files, the database credentials, etc). You can even develop your own access driver by following the plugin api. The full list of available drivers for accessing the data is in the « Plugins » part of this documentation, above the « access » category : http://www.ajaxplorer.info/plugins/access/

To create a repository, click on « New Repo » in the toolbar and fill the dialog window : use a short, unique and understandable label, and choose the driver that will be used for this repository. If you don’t have an idea of what a driver is, simply choose the « File System (Standard) » driver. Then, depending on the chosen driver, some parameters will appear. By putting your mouse over the « ? » buttons, you can have more info about each parameter. All parameters followed by a star « * » are mandatory. Consult also the « access » plugin documentation on the website. Once your configuration is ok, save the repository. The repositories list (top left of your screen) should be automatically updated, and you can switch to the new repository to see if everything is alright (by default, admin user has read/write to all repositories, even newly created).

Enrich the repository features : Meta Sources

Once the repository is saved, you can reopen it and see that you have a new tab in the repository edition dialog, « Meta Sources ». In this tab, you can add « Metadata » sources support for the repository. « Metadata » are data that will be attached dynamically to the « core » data of the repository.

For example, it can be users comments attached to any file/folder of a filesystem, or versioning information, etc. This is « decoupled » from the main access driver of the repository, because the metadata can use various implementation for the same result. For example, user comments on a file/folder can be saved directly in the filesystem (in hidden files, or in the filesystem metadata if supported), or in an external database, or even why not in the client browser cookies… ?? Below is a schema demonstrating how metadata « enrich » the data.

Currently, the meta.user allows you to add any number of custom fields to attach to your files/folder (some of them with specific names can have specific rendering like Stars Rating system, color label, etc, see the meta.serial documentation), meta.exif automatically extracts the EXIF data of the photos if they exists, and you can display a given set of EXIF fields in the info panel, and meta.svn assumes that your file system is a valid working-copy of a subversion repository, and relies on command-line svn to extract and display the versionning informations.

See the list of available meta plugins http://www.ajaxplorer.info/plugins/meta/.

Roles Management

The roles feature is the recommanded way for managing users rights, as when you’ll want to change the repositories accesses for every users, it will be much simpler to change one role rights than all users rights one by one.

The roles define two set of right  :

• Repository Access : for each repository, you can define read or write access. Users that have this role will have the right to read/write data in the repository. By default, if you check « write », both « read » and « write » will be automatically checked. If you want to create a write only role (specific case where people would be able to upload data without seeing the content of the repository), check « write » first, then uncheck « read ».
• Manual Actions Filtering : this one is for advanced users only, and gives you an ultra flexible way to define what you want your users to be able to do in AjaXplorer. Every actions in AjaXplorer client are defined via XML files that are all concatenated into a big « registry », on which the client builds itself, but that also declares the server entry points. There are core actions, but most actions are defined by the ajaxplorer plugins, via the manifest.xml file of every plugin. When you want to disable a given action for a group of people, you’ll have to scan the XML files corresponding to the feature you are looking for, and find the <action name= »your_action »> XML tag. The name attribute value is the value you can enter in this « Manual Actions Filtering » box. You can add as many as you want, using a comma as separator.
  

Manual Actions Filtering Example : let’s say you want to disable « Change Password » for a group of unadvanced users, as well as the « New File » action (assuming you have a typical installation). The first is linked to the authentification plugin, and checking the auth.serial/manifest.xml, you can see a reference to the core file server/xml/standard_auth_actions.xml. In this file, you can see the pass_change action. The second one is linked to the file management plugin, thus the access.fs plugin. You can find the mkfile function in access.fs/fsActions.xml.  Thus the value would be « pass_change,mkfile » (without the quotes)  in the manual filtering box.

User Management

To create a new user, use the « New User » button in the toolbar. A modal window will ask for the new user login and password (type the password twice). By default, a new user is created with the minimal rights (see the Repositories Management about default rights).

Access Control Tab

When you edit a user (by double-clicking the user, or using « Edit » in the menu bar), you can in the first tab edit its rights to access the repositories. If you have previously defined « Roles », you should see them appear in the left frame, and be able to drag’n'drop them in the user’s right frame. When you add/remove a role, you should see in the Repository details below that the rights are automatically updated. This detailed panel is still editable, which mean that once you have applied a role to a user, you can overwrite one of the automatically assigned right with a specific user value. If you don’t use roles at all, you can directly use the details panel to edit each repositories access right.

Personal Data Tab

The « Personal Data » tab gives you access to the password change form, as well as the checkbox to give administration rights to a user. Once you grant access to a repository to a user, some repository will require additional data specific to each user in order to work. For example, in a given configuration, an FTP repository can require you to set the FTP credentials to use for each user (once again, this is a specific configuration, you can also choose to set a given credentials for all users, or to set none at all and use the users ajaxplorer credentials automatically as ftp credentials, …). In that case, you can see the forms for entering this user/repo/specific data in the « Personal Data » tab.