Role Groups and Teams

User Modules

Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Human resources
Products, assets and sales

Technical Modules

Sabre plugin module
Enterprise Architect connector

System Modules

The AyMINE Framework Module
System Management

Give us contact

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

Role Groups and Teams

AyMINE uses groups to organize users into groups that match the organization's breakdown and allow for joint management.

Video guide on how to set up roles and teams is here

Users and other groups are assigned to groups. This allows me to divide groups into properties

What applies to all groups

  • A group gives users the rights assigned to it
  • A group inherits the rights of a group from the groups it is assigned to
  • A user who is in a group is simultaneously in the group to which the group it is assigned. (A group assignment is thus a transiently inheritable property.)

Group Types

Although user groups don't seem to be very different at first glance, there are significant differences between them

General Group

A group without a specific specification is created by administrators to set up the rights to use the application

Team

A team is a group that has a manager. By being a group leader, a manager gains rights over team members. Specific rights may depend on the system modules:

  • can assign tasks to members of his team,
  • can move tasks between members,

Teams should correspond to the organizational structure of the company. But a team can also be a project team, i.e. created only temporarily.

Role

A role determines a person's job status. It does not in itself give a member new rights, but is used in the system:

  • standard tasks are assigned to a role,
  • decisions are directed to roles,
  • roles are shown in the user's description.

Note

The importance of assigning a role/group to a repository

Roles and groups determine the rights to manipulate objects in the system. By binding a group to an object repository – a project, group, and so on – you create the right to insert messages into the repository.
Note: The role to project/area link is created automatically from the settings of the area and is not followed for roles. The settings for roles are by default just done from the repositories. However, the link is also used to allow saving messages (or other objects) to areas and this is controlled by the link that is set here.
When does it make sense to use the function with an area:

  • Disconnect an area from a project that is terminated – people will still have the right to view the project, but will not be able to add more messages to it.
  • By attaching an area to a group, you can allow people to post messages to the area who otherwise cannot post to the area.

Roles do not form a hierarchy

There are many hierarchical objects in AyMINE. Information, tasks, and much else can "disintegrate" into partial information, tasks, etc. This creates a tree from more general to more detailed. System groups and roles, however, are not hierarchical. They have ancestors and successors, they can have more of both – mainly ancestors.
The sense of the ancestor is also not that it is a more general group, but that the group inherits rights from it. And it can inherit them from more other groups. This is not the logic of the tree, nor are the links.

Because roles do not form a hierarchy, they do not have a tree view in the list.