The UserData class holds information about users. We keep the passwords in a separate table and use proxies to avoid loading password data each time a user is loaded to minimize security risks. It is only if the password needs to be changed that the PasswordData object is loaded. The one-to-one mapping between user and password is controlled by the password class, but a cascade attribute on the user class makes sure that the password is deleted when a user is deleted.

The GroupData, RoleData and ProjectData classes holds information about groups, roles and projects respectively. A user may be a member of any number of groups, roles and/or projects. New users are automatically added as members of all groups and roles that has the default property set.

The membership in a project comes with an attached permission values. This is the highest permission the user has in the project. No matter what permission an item has been shared with the user will not get higher permission. Groups may be members of other groups and also in projects. A PermissionTemplateData is just a holder for permissions that users can use when sharing items. The template is never part of the actual permission control mechanism.

Group membership is always accounted for, but the core only allows one project at a time to be use, this is the active project. When a project is active new items that are created are automatically shared according to the settings for the project. There are two cases. If the project has a permission template, the new item is given the same permissions as the template has. If the project doesn't have a permission template, the new item is shared to the active project with the permission given by the autoPermission property. Note that in the first case the new item may or may not be shared to the active project depending on if the template is shared to the project or not.

Note that the permission template is only used (by the core) when creating new items. The permissions held by the template are copied and when the new item has been saved to the database there is no longer any reference back to the template that was used to create it. This means that changes to the template does not affect already existing items and that the template can be deleted without problems.

The KeyData class and it's subclasses ItemKeyData, ProjectKeyData and RoleKeyData, are used to store information about access permissions to items. To get permission to manipulate an item a user must have access to a key giving that permission. There are three types of keys:

The permission property appearing in many classes is an integer values describing the permission:

The values are constructed so that READ -> USE -> RESTRICTED_WRITE -> WRITE -> DELETE are chained in the sense that a higher permission always implies the lower permissions also. The SET_OWNER and SET_PERMISSION both implies WRITE permission. The DENIED permission is only valid for role keys, and if specified it overrides all other permissions.

When combining permission for a single item the permission codes for the different paths are OR-ed together. For example a user has a role key with READ permission for SAMPLES, but also an item key with USE permission for a specific sample. Of course, the resulting permission for that sample is USE. For other samples the resulting permission is READ.

If the user is also a member of a project which has WRITE permission for the same sample, the user will have WRITE permission when working with that project.

The RESTRICTED_WRITE permission is in most cases the same as the WRITE permission. So far the RESTRICTED_WRITE permission is only given to users to their own UserData object so they can change their address and other contact information, but not quota, expiration date and other administrative information.