The idea behind permissions is simple enough: "permissions" make up "access levels" that users are supposed to play as they are assigned those. Some access levels enjoy more access rights than others, much the same as a project owner in life enjoys more access rights toward what constitutes a software project’s machinery, than a software developer, whose job is more often than not is confined to writing codes. Permissions, therefore, are a means to give a framework of access rights to a user according to his or her place on a project or, more broadly, in an environment of projects, such as in a research department, or a construction company.

Permissions are the central element of an access level and are used as specific rights that a user has in relation either to the system as whole, or projects he or she is (or is not) part of. There is a user-specific hierarchy of permissions. For example, a user with the access level of Administrator (or, in short, Administrator) has the right (permission) to set permissions at will.

In Birdview, permissions are divided into three groups:

1) global permissions,

2) permissions in relation to a project(s) the user is a member of, and

3) permissions in relation to projects the user is NOT member of.

See Access Levels, for more details.

Also, you may want to look up the following topics:

• Global permissions
• Default project permissions
• Permissions in projects where the user is NOT a member of