Skip to main content
Roles are named sets of permissions that encapsulate the permissions needed for different kinds of users. Permissions grant users access to subsets of Lucidworks Search functionality. A role can specify UI permissions, API permissions, or both:
  • UI permissions grant users access to parts of the Lucidworks Search UI.
  • API permissions grant users access to specific API commands for specific REST API endpoints.
See Permissions for information about how permissions supplied by multiple roles and by user definitions combine.
Users who can create or modify code obtain access to the broader Lucidworks Search environment. This access can be used to create intentional or unintentional damage to Lucidworks Search.

​
Roles and environments

The roles that Lucidworks Search clients have depend on the type of environment.

​
Default roles

At initial startup, Lucidworks Search creates a set of default roles for common types of users.

​
admin

The admin role is the equivalent to the Unix root or superuser. It allows full access to all Lucidworks Search services: 
GET,POST,PUT,DELETE,PATCH,HEAD:/**

​
developer

The developer role has all the read/write permissions required for building and running applications. This role cannot add users; user management is handled by Lucidworks.
The developer role is updated for Lucidworks Search 5.10 to exclude permissions for creating, editing, and deleting Spark jobs, JavaScript stages in querying and indexing pipelines, and custom index and query stages. The new roles including these permissions are created when upgrading to Lucidworks Search 5.10, but the existing developer role is not updated in order to prevent unexpected changes.
GET,POST,PUT:/system/**
GET,POST,PUT,DELETE,HEAD:/stopwords/**
GET,POST,PUT:/usage/**
GET:/features/**
GET,POST,PUT,DELETE,HEAD:/blobs/**
GET,POST,PUT,DELETE,HEAD:/scheduler/**
GET,POST,PUT,DELETE,HEAD:/experiments
GET:/introspect/**
PUT:/usage/**
GET,POST,PUT,DELETE,HEAD:/index-stages/**
GET,POST,PUT,DELETE,HEAD:/messaging/**
GET,POST,PUT,DELETE,HEAD:/catalog
GET,POST,PUT,DELETE,HEAD:/parsers/**
GET,POST,PUT:/appkit/**
GET,POST,PUT,DELETE,HEAD:/index-profiles/**
GET,POST,PUT:/recommend/**
GET,POST,PUT,DELETE,HEAD:/history/**
GET,POST,PUT,DELETE,HEAD:/apps/**
GET,POST,PUT,DELETE,HEAD:/solr/**
GET,POST:/query/**
GET,POST,PUT:/signals/**
GET,POST,PUT:/searchLogs/**
GET,POST,PUT,DELETE,HEAD:/query-pipelines/**
GET,POST,PUT:/configurations/**
GET:/suggestions/**
GET,POST,PUT,DELETE,HEAD:/searchCluster/**
GET,POST,PUT,DELETE,HEAD:/index-pipelines/**
GET:/license
GET,POST,PUT,DELETE,HEAD:/spark/**
GET,POST,PUT,DELETE,HEAD:/query-stages/**
GET,POST,PUT,DELETE,HEAD:/prefs/apps/search/*
GET:/nodes/**
GET,POST,PUT,DELETE,HEAD:/solrAdmin/**
GET,POST,PUT:/synonyms/**
GET,POST,PUT,DELETE,HEAD:/jobs/**
GET,POST,PUT,DELETE,HEAD,OPTIONS:/collections/**
GET,POST,PUT,DELETE,HEAD:/connectors/**
GET,POST,PUT,DELETE,HEAD:/groups/**
GET,POST,PUT,DELETE,HEAD:/query-profiles/**
GET,POST,PUT:/templates/**
GET,POST,PUT,DELETE,HEAD:/tasks/**
GET,POST,PUT,DELETE,HEAD:/links/**
PATCH:/users/{id}:id=#ID
GET,POST,PUT:/registration/**
POST:/index/**
GET,POST,PUT:/objects/**
GET,POST,PUT:/templates/**
The permission PATCH:/users/{id}:id=#ID uses the variable value #ID as a placeholder for the currently logged-in user ID. It is included so the Lucidworks Search UI “change password” feature is available to native realm users.

​
readonly

The readonly role can view everything in Fusion but cannot modify configurations. Lucidworks Search customers must make changes in the appropriate stage environment, after which Lucidworks will promote the change to production. 
PUT,DELETE:/apps/*/blobs/prefs-*._lw_tmp_*
PUT,DELETE:/prefs/apps/search/*._lw*_tmp_*
PUT,DELETE:/apps/*/query-pipelines/_lw*_tmp_*
POST:/prefs/apps/search
PUT,DELETE:/apps/*/index-pipelines/_lw*_tmp_*
POST:/apps/*/query-pipelines
POST:/query-pipelines/_system/collections/*/select
POST:/apps/*/parsers
POST:/apps/*/index-pipelines
PUT:/usage/counters/*
GET:/**
PUT,DELETE:/apps/*/parsers/_lw*_tmp_*
POST,GET,PUT:/signals/**

​
rules

The rules role provides query rewriting API access to all Lucidworks Search apps. 
GET:/apps/*/query-profiles/**
GET,POST,PUT,PATCH,DELETE,HEAD:/apps/*/query-rewrite/**
GET:/solr/**
GET:/query/**
GET:/collections/**
GET:/apps/**
The search role has read-only query and write-only signal API access to the Lucidworks Search “default” collection. These permissions are required for search applications, for example, for App Studio. 
POST:/apps/*/signals/**
GET,POST:/query/**
POST:/signals/**
PATCH:/users/{id}:id=#ID
GET,POST:/apps/*/query/**
The permission PATCH:/users/{id}:id=#ID uses the variable value #ID as a placeholder for the currently logged-in user ID. It is included so the Lucidworks Search UI “change password” feature is available to native realm users.

​
webapps-role

The webapps role can list and download Lucidworks Search apps. 
GET,HEAD:/webapps/**
GET,HEAD:/license

​
Role information

Lucidworks Search stores role information in Apache ZooKeeper. Each role in a ZooKeeper entry contains the following:
  • id– ID string, created by Lucidworks Search
  • name– Role name string
  • desc– Text description; optional
  • permissions– A list of Lucidworks Search permission specifications
  • ui-permisions– A list of names of Lucidworks Search UI components
  • created-at– Timestamp; created by Lucidworks Search
  • updated-at– Timestamp for last edit; created by Lucidworks Search

​
Manage roles

Only users with admin privileges can manage roles. In Lucidworks Search environments, Lucidworks is responsible for managing roles.

​
Assign job permissions

ImportantThe colon character : is a special character used in the permissions engine, so you must use an asterisk * in the command.
To assign permissions for a specific job, enter the following command, where you must enter the specific job in the <JOB_NAME> field: 
POST:/apps/*/jobs/task*<JOB_NAME>/actions

​
Assign job permissions in the UI

The command to assign permissions for a specific job in the UI is an exact call, so you must specify the <JOB_NAME>. For example, if the job name is testing-call, two example commands are: 
POST:/apps/<APP_NAME>/jobs/task:testing-call/actions
or 
POST:/apps/*/jobs/task:testing-call/actions

​
Assign permissions in the API

The command to assign permissions to a job using an API does not require you to specify the <APP_NAME>. Two example commands are: 
POST:/jobs/**
or 
POST:/jobs/task*<JOB_NAME>/actions