You can define access control settings under the "Edit -> Access" menu for an entry.
The access control mechanism in RAMADDA is centered around a set of actions that can be
applied to entries -
view, new, edit, etc.
For each action a set of user roles can be specified
that grant or remove permissions to do those actions.
The form is composed of this list of actions and, for each action,
there is a field where you can enter any number of user roles (one per line).
Image 1: Entry Access Control
Note: Access control settings have no effect on RAMADDA site administrators. They can do anything.
Note: after setting access (e.g., creating a private space) it is best to log out (or user another browser)
and check if the access is set to what you think it is.
The roles for a user are defined by the RAMADDA administrator through the Admin-Users page.
Other "special" roles include:
- "none" - this denies access to any user
- "user" - any logged in user
- "any" - any user, either logged in or anonymous
- "anonymous" - non logged in user
- "ip:prefix" - The user is coming from an IP address that begins with prefix
Furthermore, any role can be negated with "!"
In the example shown above any user in the role "group1" can view anything under the
sub test entry.
No other user can view the "sub test" because of the "none" specified.
Along with the view access, the user "joe" can also edit the entry and any entry under
On the right shows a summary table for the particular entry being viewed.
This shows the access control
settings for all of the ancestor entries of the current entry and allows the
user to see just what access settings are applicable to the entry.
To see if a given user has the ability to do a particular action for a particular entry RAMADDA looks
at the permissions for the entry and its ancestors and either looks for the
first permission grant or the first permission denial.
If nothing matches then permission is not granted.
Here are other examples:
- To make a whole tree of entrys inaccessable - under the view action enter:
This will only allow admins and entry owners to view anything under that tree.
- To make an entry (or tree of entries) inaccessable to non logged in users - under the view action enter:
- To make an entry (or tree of entries) inaccessable to users outside of an ip address - under the view action enter:
- To allow anyone to view the entries in a tree but don't allow anyone to
access the files then under the file action enter:
- To allow anyone to view the entries in a tree but only allow file access to
users who are coming from the IP address 123.456 then
under the file action do:
- If you wanted to give a certain user permission (e.g., joe) to view the entry but not allow
any one else to view the entry then enter under the view action:
RAMADDA would first check if the given user was "joe". If it is "joe" then permission is granted. If
its not "joe" then RAMADDA looks at the next role - "none". This blocks any other access.
- To allow for a group of users in the role "group1" to be able to edit and create new entries under a whole
tree then enter:
for both the edit and the new actions.
- A common case is to allow one role to have new and edit capabilities under a whole tree (like the group1
example above) but to grant new and edit capabilities to some other user to a sub tree. For this you would
grant the access to the parent entry like above, e.g.:
- parent entry - access =
- descendent entry - access =
Each access type can contain any number of roles (one per line).
- Special roles
- any - this is a special role and says that anyone can do the action.
- none - nobody (except admins) can do the action.
- user - any logged in user
- anonymous - the user is not logged in
- guest - the user is a guest user
- Assigned user roles - All users can have one or more roles. This is set by the site administrator
when editing the user. They are just string names. For example, you might have the roles "group1" and
"group2". If you wanted to grant access to "group1" you would just enter:
If you wanted to grant access to users in either group1 or group2 you would enter:
- Self identity role - If you enter a role in the form as user:someuserid this grants
access to that specific user. So, if you wanted to give "joe" access to something enter:
- ip:ip address - This format grants access to incoming requests with the given ip address or ip address suffix.
For example, the following would grant access to any request coming from any IP address that starts with 128.117
- !some role - Prefixing a role with "!" is a way to deny specific access to a user, role, or ip address.
For example, the following would deny access to any request coming from any IP address that starts with 128.117:
Say you want to grant access to user "joe" but deny access to user "jim". You would do:
The different access types are:
RAMADDA has support for a data policy mechanism that allows for
the specification of a data license and access settings in a centralized
location. This allows for the use of a single data policy across multiple
entries within a single RAMADDA repository as well as sharing data policies
across a group of confederated RAMADDA repositories.
See the documentation at
for more details.
A RAMADDA repository is configured to read in data policies
from a set of URLs specified in a repository.properties file
in your local RAMADDA home directory.
#Comma separated list of URLS to fetch the data policies from
#Use "this" to refer to the current RAMADDA
#Number of minutes between fetches of data policies from the URLs
#Set this property to turn on debugging
The URLs specified are read at a given frequency (with the property above).
Each URL returns a document that has one or more data policies.
A data policy consists of name, ID, data license and a number of permissions.