Administration interface users
Funnelback provides the ability to partition a Funnelback installation to allow individual people to manage their own collections.
Upon installation, an administrator user is created to manage all collections, and this user has the ability to create users and roles with varying levels of permissions within Funnelback.
Although for some Funnelback installations simply using the single admin user for all tasks may be appropriate, we encourage administrators to make features such as the marketing dashboard available to interested parties within their organisation.
Other possible applications of the Funnelback security model include:
Allowing a web-designer to upload and download search templates within an existing implementation; or
Allowing a manager to view query reports on particular collections without granting the ability to change technical implementation details.
The "System" menu in Funnelback’s navigation bar has a Manage users and roles link which leads to the user and role management functions of the system.
From these pages users may be added, edited, have their passwords changed or be removed entirely. Similarly, roles may be added, edited or removed from the system.
Funnelback’s roles features allow for any permission or capability traditionally assigned directly to users to be granted to a role, which can then be granted to many individual users, simplifying permission management over time.
When a new user is created you will be asked to provide user details, set the user’s password, assign the user to any roles they should have and finally grant permissions to manage the new user.
Once the user has been created, these details (other than the username) can be edited, and specific settings can be adjusted including:
Assigning specific permissions to the user (though we encourage using roles where possible)
Assigning roles to the user and granting the right to edit a role or grant the role to other users
Allowing the user to see some or all collections on the server
Allowing the user to see some or all profiles on the server
Allowing the user to create specific types of collections and associate them with licenses
Allowing them to manage some other users/roles, other users/roles matching some suffix (e.g. all users who’s username ends in @example.com) or all other users on the system
Allowing them to acknowledge accessibility auditor issues at selected levels of scoping
In context help is provided for each of these actions within the user editing screen.
Please notes that Funnelback does not provide any interface to manipulate user specific file manager rules. If required, it is recommended that these are directly edited into a role.ini file and then that role is granted to the users that need it.
Funnelback includes a set of default roles covering a number of common permission scenarios, such as administrator users and users who can access only search analytics.
New roles can also be created and edited to match the specific requirements of a Funnelback installation.
The role will initially require a name and a list of roles (or users) who should be granted permission to manage the new role. Once created, the role can be assigned any of the permissions or settings a user may have, as described above.
As with the user editing screen, in context help is provided for each section of the role editing screen.
Please note that roles may also be assigned other roles, which allows for higher level roles to be assembled from sub-roles rather than being recreated from scratch.
Users and roles are automatically upgraded during the Funnelback upgrade process. It is also possible to manually apply these changes by calling
When a new permission is introduced, the user or role may gain this permission based on what the user or role previously had. For example, a newly introduced permission
can_taste will be granted to any user or role that already had the permission
can_chew. Sometimes, these new permissions may be granted based on having a combination of multiple existing settings. For example,
can_eat is only granted if the user or role previously had
can_swallow. If the user or role does not have both of these permissions, they will not be given
Upgrading of users and roles is done in isolation and does not consider inherited permissions. In the example above, it is possible that the user being upgraded has both permissions
can_swallow through the inheritance of multiple different roles. So if a user gets
can_chew from one role and
can_swallow from another role, even though the user has access to both permissions, they will not be given
Manually upgrading users or roles may not result in exactly the same results as going through the upgrade process because the upgrade process may also update the default file-manager rules. This can result in new permission not being granted because the user or role no longer has access to something that was previously granted in the default file-manager rules.
Please refer to release notes where any changes in users and roles permissions will be mentioned.