In this Topic
To protect your agency's system and the confidentiality of the information contained therein, the system only displays the information and action options for which a logged-on user has been assigned access rights by means of user roles. User roles combine the permissions needed for several related tasks and allow you to more efficiently provide agency and non-agency users with access to the parts of the system they need.
When setting up your security system, there are questions you need to ask. Think about how your organization is structured, how people can be grouped together, and how work flows through your system. Consider the needs of non-agency users, if appropriate. Once you have a general structure created, start setting up the web-based AASHTOWare Project application. For more information, see Questions To Consider for Security.
You can set up access rights for prime projects, projects, proposals, lettings, and contracts. Permissions are given based on what component and at what particular time during the workflow a user should have access. You can also control access to specific prime projects, projects, proposals and lettings based on matching attributes. Specific permissions can also be set at the individual field level.
Defining access rights for a role entails the following areas that can be specified:
Role Summary – defines which components are displayed on the dashboard when the user logs on to the system with this role. Select the highest level component you want the role to have. For more information, see Managing Components on the Role's Dashboard.
Assign Rights: Workflow – defines WHEN a user has access based on the assigned workflow and phase. The workflow and phase can change during the life cycle of an entity.
Assign Rights: Components – defines WHAT components and WHICH records an agency or non-agency user can access based on criteria within the records.
Assign Rights: Resources - determines the resources assigned to a role, and at what level the resource can be changed. Resources include restricted fields, rows accessed, base and custom reports, imports, interfaces, processes, and services.
Assign Role to Users - enables you to assign the selected role to particular users. Each user can be assigned multiple roles as needed.
Assign Contract Authority Assignable Roles - The Assign Contract Authority Assignable Role Overview allows you to assign contract authority assignable roles to a selected role. Users to whom you assign contract authority assignable roles will then in turn be able to assign contract authority to other roles, either by specific contract or office-wide by the agency office where they work. For more information, see Assigning Contract Authority Assignable Roles to a Role.
Assign Source Authority Assignable Roles - The Assign Source Authority Assignable Role Overview allows you to assign source authority assignable roles to a selected role. Users to whom you assign source authority assignable roles will then in turn be able to assign source authority to other roles, either at the source or facility level. For more information, see Assigning Source Authority Assignable Roles to a Role.
Assign Workflow rights if you want to control access to an entity as it progresses through its life cycle.
To determine how to set this up, consider how access to the entity will change over time as the life cycle progresses. Use workflow phase access rights if you have different people that are in control during these stages or if the level of rights (for example, ReadOnly or UpdateWithDelete) change as the entity progresses.
For example, if during the design phase a project is controlled by one group, once associated to a proposal its control switches to another group, and after that, its control again changes when the proposal is let, a workflow phase should be established and then access rights applied for each phase. For another example of a workflow, see A Simple Scenario for Security.
Phase 1 |
Phase 2 |
Phase 3 |
Design |
Proposal Preparation |
Letting |
If access rights do not change as the entity progresses (for example, a user has full access to anything in their district, no matter the stage in the life cycle), then full access would be given to all phases in the workflow.
Note: When a project is associated to a proposal, the project inherits the proposal's workflow and phase, which can no longer be changed at the project level. They can only be changed at the proposal level. The workflow and phase of a letting and prime project operate independently of project and proposal.
All workflows are displayed in an accordion list on the Assign Workflow Rights component. When expanded, each workflow lists the phases associated with that workflow. You may select or remove access rights to view, update or delete data for each phase in the workflow.
Component access rights are used when you want to control access to parts of an entity (prime project, project, proposal, and letting) and its associated data as represented by the different components and component tabs.
Note: Access can be set up separately or work together, so you can also specify what base or custom components (Funding, Category, Items, etc.) are available based on specific attributes of the entity (District, WorkType, Designer, etc.).
When setting up a role, one of your first considerations will be which components you want available to the user, and whether role will be used by agency users who need more functionality or by non-agency users who will need limited functionality. For example, if you want to allow access to a project's general information, but limit access to the project items or funding information, you can do this by selecting individual components to which the role will have access. For more information about how to do this, see Assigning Component Access Rights to a Role.
These are other considerations you may want to include when setting up a role:
What type of entities (projects, proposals, prime projects, bid lettings, or contracts) do you want the user to work with? For example, you may want to allow access to only District 7 projects.
Does the type of entity dictate that a different set of components should be available? For example, one user may be allowed update access to project items for District 7 for those projects assigned to the user, read-only access to project items in District 7 assigned to other users, and no access to project items for projects in other districts.
You can assign access rights to a role for a variety of elements and features available in the system. Types of rights are grouped in ten tabs, located on the left side of the Assign Access Rights component. For information about assigning these rights, see Assigning Resource Access Rights to a Role.
When multiple roles are assigned to a user, the user can only log on with one role at a time. If a role does not have access to a specific page or report, the user must change to a role that grants that access.
The Home menu lists all of the roles to which the user is currently assigned in blue and his active (current) role is displayed at the top of the list in black. The user does not need to log off to change his active role; he can do this at any time by clicking on another role in the Home menu. Keep in mind that newly assigned roles do not appear on the Home menu until the next time the user logs on or refreshes the page.
Related topics:
Assigning Component Access Rights to a Role
Assigning Workflow Phase Access Rights to a Role
Assigning Resource Access Rights to a Role
Assigning Restricted Field Access Rights to a Role
Assigning Selection Criteria Access Rights to a Role
Assigning Report Access Rights to a Role
Assigning Process Access Rights to a Role
Assigning Service Access Rights to a Role
Security Component and Row Level
Maintaining Home Page News for a Role
Creating Agency Help for a Role