create users and set their access rights    

OBEROn lets you control the user access for that concerns both the information they can see and the actions they can perform. Every person who will use a OBEROn application should be associated with a OBEROn User administration object.
There are three levels of access rights for each user: infrastructure (or system) administration access, schema modeling access and object manipulation access. When you define a new user or you modify an existing one you can set these access options for him in addition to the basic properties like the email address, the phone, the address, the language and so on.

The user name and password represent the account credential to access OBEROn with that user; another important information is the email address: this is used to send comunications from OBEROn to a personal email when the mail External option is set. OBEROn can send messages to users in two ways: using an internal mail service or externally via a smtp host.
When both Internal and External option are set, both methods are used to send the messages.

You can also define some default parameters for the user:
- the language - OBEROn manages multilingual translations, this parameter represents the user default language for all label translations in a web application. The language code is one of the internal dictionary languages.
- the objectspace - When the user creates a new object instance without specify the space where put it, OBEROn uses this space as default.
- the localarea - When the user put a file into a object instance and this parameter is defined, the file is physically stored into this local storage area (if and only if this localarea is a mirror of the destination filespace).
- the metricsystem - A metric system is a set of unit measures used to automatically convert (or format) the object real (or date/datetime) values. When a user has an associated metric system, values for each specific filed type (length, area, volume, mass .... ) are showed in the corresponding metric's unit instead of the standard SI unit (meter, square meter, cubic meter, kilogram.... )

As said above, part of creating a user definition involves specifying the access rights the user should have for administration level (System / Admin) and object manipulation (Basic) level.
In particular you can set the access options for each administrative object: user enabled for a specific administrative object type (like objectspace, filespace, class, field, etc.) will have the full access to create, modify and destroy all instances of that type.
Moreover, if the user will ever need to perform a task for any business object instance, you must assign the (Basic) access in the user definition.
At the contrary, if you want to prevent a user from ever having a form of access independently from other access roles, you may do so by denying that access in the user definition.
When you add a new user the System and Admin accesses are disabled as default while the Basic accesses are enabled because the specific access to business object instances are usually governed by the lifecycle rules. Only users defined as SuperUser are able to perform all actions for all business object instances even if they are not enabled by the assigned lifecycle rules.

The same result can be obtained with the following OOQL command :

A default user "ADMIN" is created when you install OBEROn; this user has all access rights, but is not a SuperUser. You can access OBEROn using this account, but you can't change its properties.

Users can share accesses for certain classes of business objects or other to administrative objects, such as menus, commands, forms.
If many users need access to a class of objects, you should consider creating a user category to represent the set of users. There are two types of administrative objects that allow you to identify a set of users (people) who require the same accesses: teams and assignments.
To decide which type of user category you should define, consider what the users have in common and why they need some of the same access rights:

• Team - Is a group of people who work on a common project or for the same business area. In a team, people of many different talents and abilities can share a set of functional skills, but usually act in different jobs/roles. For example, a software development team might include a graphic stylist and system architect in addition to software developers.

Teams are frequently hierarchical. In hierarchical teams, access privileges that are available to a higher parent team are available to all of the teams below it (SubTeams). If you select a SuperTeam for a team, this team becomes a SubTeam and inherits all access rights from the parent team.

• Assignment - Is a collection of people who have a common job type: project manager, software developer, marketing director, designer and so on.

When adding a new team or assignment you can specify, in addition to its name and description, other default parameters such as:
- the email address - if specified is used to send email messages in place of sending it to each associated users.
- the language and the localarea (only for team) - these parameters are not internally used by the system, but can be read and used by some custom application processes.

Moreover, you can assign specific users to this new category.

An equivalent team creation OOQL command might be:

and for the assignment definition :

A user can belong to any number of teams and can have more assignments.
If a user belongs to a team, it automatically belongs also to the SuperTeam and all its parent teams in the hierarchy. For example, a designers associated to the Designer's division belongs also to parent division "Research & Development" and, as consequence to the Company.

In addition, all users belonging to different teams may have the same specific assignment, in this case you can associate directly the teams with the assignment; as result, all users in the teams inherit the assignment privileges.

Creating a user category let you to avoid to add all user list every time you define access rights for administrative and domain objects. For example, suppose you create a user category, such as a team, and assign a certain number of users to that team. If you enable the team to perform a specific action and so you grant the group full access to it, all the users within that group will have the same access rights for that action.

When an application user attempts to perform an action for a domain object instance, OBEROn checks to see what type of credentials the user have in the user definition. If the user is a SuperUser the system allows the action and performs no further checking. If action involves read access only, the action is allowed; otherwise the access depends on the lifecycle settings.