Permissions and access control
  • 23 Nov 2021
  • 5 Minutes to read
  • Dark
    Light

Permissions and access control

  • Dark
    Light

Agile.Now DevOps permissions and access control refers to the roles and access permissions provided to the different users accessing the Agile.Now DevOps. This includes roles such as the admins and the project owners that has access to infrastructure wide permissions and roles such as reviewer, developer, tester and deployment that has access to the developer wide permissions within different applications. The roles are migrated directly from the OutSystems Lifetime and associated to the users that are part of the different teams within Agile.Now DevOps. This will be further explained below. More information about OutSystems access management is available here.

Visibilities of projects

Project access is defined through the team structure. The project appears when the user is part of a team and is associated with the project. Team structures are defined in OutSystems Lifetime software. 

Infrastructure level roles

RoleDescription
Settings

Users in this role can control the settings of the Agile.Now DevOps environment. The possibility or access for the user is quite similar to an admin in lifetime who has access to every part of the application and its features.

This role in Agile.Now DevOps is mapped automatically to users who's following permissions are enabled in Lifetime:

  • Manage Users and Roles permission (applies only to OutSystems Cloud)
  • Manage Infrastructure and Users permission (applies only to self-managed infrastructures)

Permissions: 

  • The user can add, edit and remove IT users, roles and teams. 
  • The user can turn on/off features in Technical Preview. Setting this permission ON also sets the permission "Manage Teams and Application Roles" to ON.

The user will be able to: 

  • Manage all the settings such as create, updated, delete and view the settings
  • Manage the environments,
  • Access and updated lifetime token,
  • Connect different applications(through connected apps section)
Projects

Users with this permission has access to modify the settings pertaining to the projects. This role in Agile.Now DevOps is mapped automatically to users  who's following permissions are enabled in Lifetime:

Manage Teams and Applications permission.

Permissions:

  • The user will have access to project level settings
  • The user will have access to the different teams. (the teams are also migrated from OutSystems)

The user will be able to:

  • Add and remove IT users from the teams
  • Grant and revoke roles to IT users to access applications within the team’s
  • Get access to manage all of projects environments
  • Create, delete, update and read projects and project related settings such as mapping, behavior, components, tests, issues and releases. 

Project and environment level roles

RoleDescription
Teach Lead

Reviewers are users who are tech leads, architects, etc. who is expected to have more permissions on the project and environment level. The users will review the quality of the application and the quality of deployment. 

This role in Agile.Now DevOps is mapped automatically to users who's following permissions are enabled in Lifetime. 

  • Create Applications permission in assigned environment.
  • Administrator role in a Team

Permissions:

  • Create applications in any team through lifetime. 
  • Review applications allocated to the team
  • The user will be able to:
  • Manages all the applications added to the team
  • Deploy from one environment(development) to another(testing)
  • See applications (through teams access) of other teams
  • Change, add and delete components from the Components module
  • See and run tests from the Tests module
  • See and sync issues from the Issues module
  • See and sync releases from the Releases module
  • Be able to see and review the dashboard and change the status of issues
  • Be able to change the version of the project - 
  • Release the current version of the project and start the next one - project section.
Developer

The user with this role will be able to control the application development of the Agile.Now DevOps environment and modify the existing modules.

This role in Agile.Now DevOps is mapped automatically to users who's following permissions are enabled in Lifetime.

  • Change and Deploy Applications permission level in current environment (level 5).

Permissions:

  • Modify the status of issues assigned
  • Code access for modification and deployment

The user will be able to 

  • Have read only access to issues not assigned to the user but in the same project and multiple applications
  • Change the code assigned to the user by opening OutSystems Service Studio from within Agile.Now DevOps.
  • Read only access to the code of other applications within other teams
  • See the users project (through teams access)
  • Can attach the test application to the component (module) by adding the component to the application assigned to the user
  • Execute tests
  • See deployment plans, verify the status of issues, what tests has been run and what is the status of the tests run, etc. 
Tester

The user with this role will be able to control, test the Agile.Now DevOps environment and edit existing issues.

This role in Agile.Now DevOps is mapped automatically to users who's following permissions are enabled in Lifetime.

  • Open and Debug Applications permission level in the current environment (level 4).

The user will be able to:

  • Change status of own issues
  • See other issues(read-only through teams access)
  • See project (through teams access) - see only own projects 
  • Execute tests
  • See deployment plans.
Deployment

The users in this role will be able to manage releases in the Agile.Now DevOps environment in the target environment and edit new releases.

This role in Agile.Now DevOps is mapped automatically to users who's following permissions are enabled in Lifetime.

  • Change and Deploy Applications permission level in the target environment (level 5).

The user will be able to:

  • See the deployment plans and can execute, cancel or start them. 

The project access

The project access is defined through teams. This means that the privilege of a user within a team is defined by the access rights provided to the user within a team. For example, in the example below: 

If the user in a team is an administrator, then the user will get administrator privilege within that project. As an administrator, the user will be able to do admin level activities such as adding new teams, editing teams etc. 

Similarly, if a member has Developer access, the user will be able to do all the activities from a deployment perspective across all the applications within that project. This means that, any member irrespective of which application they are developers of,  within that project, can do the deployment. They are however not able to change or modify the applications on OutSystems service studio to which they are not members of. 

Citing the example depicted in the diagram above, Paulo Torres being an administrator of Factory Team would have administrator privileges throughout the applications (within Knowledge and Factory teams) and Sunaif Aziz who is a developer would have deployment access for applications in both Knowledge and Factory teams but only modify access to the applications OutSystems service studiowithin the Factory domain to which he is a part of. 


Was this article helpful?