This is an old revision of the document!
Manage Roles
Functionality in APEX is controlled through a series of Role and Permission definitions. Role definitions are found in the ROLES table, which contains 2 fields, the ROLE_ID and the ROLE_NAME.
APEX does not have a UI for role creation because any new role record would be created with a database script along with its corresponding permissions during a standard APEX update deployment.
The following roles are currently defined in the CeRTNA ERDS/G2G system:
ROLE_ID | ROLE_NAME | DESCRIPTION |
---|---|---|
1 | Submitter User | A role that is able to submit transactions for electronic recording. |
2 | County User | A role for county-side non-administrative functions. |
4 | System Administrator | A role with full access to the ERDS/G2G system. |
8 | Security Administrator | Defined but not used in the ERDS/G2G system. |
16 | Submitter/User Administrator | Defined but not used in the ERDS/G2G system. |
32 | County Administrator | A role county-side user and admin functions. |
64 | System Alert Recipient | Defined but not used in the ERDS/G2G system. |
128 | Submitter Developer | A role the emulates a submitter user but also has access to developer tools. |
256 | County Developer | A role that emulates a county administrator user but also has access to developer tools. |
512 | County Public Service User | A role for accessing county oriented web services. |
1024 | Agent Public Service User | A role for accessing submitter oriented web services. |
2048 | Payload Service User | A role setup for server-side server-side sending/retrieving/returning of transactions. |
4096 | Service Submitter User | A role to facilitate submitter remote folders support. |
8192 | Service County User | A role to facilitate county user remote folders support. |
16384 | Service County Administrator | A role to facilitate county administrator remote folders support. |
APEX application and user functionality is controlled based on the permissions that are assigned to a particular role. Every user record has a role assignment.
The APEX permission architecture is broken down into 5 basic categories as follows:
Category | Description |
---|---|
Modules | The APEX source code is structured in manner that segregates groups of functionality into various modules, for example an Administration Module or a Common Module or a Reports Module. Within these categories source code can be sub-categorized further, for example in the Administration Module there is Agent Management, County Management, Role Management, Submitter Management, etc. In addition to permission management, structuring the code in this manner helps with resource management, for example, there is no need for the County Management module to be loaded if you are performing an Agent Management function. |
Public Service | This category is used to define which public web services a role is authorized to use. |
Reports | This category is used to define which reports a role is authorized to use. |
Service Command | As a Windows Communication Foundation (WCF) based application, the APEX client communicates with server-side services that fulfill the functional delivery of client-side requests. The permission to call these services are defined based on a users role. This also serves as a security mechanism, ensuring that functions cannot be called by processes that do not have a role assigned. |
View Permission | The APEX UI is built upon a series of visual components. For example, ribbons, buttons, tabs, grids, etc. Different functional roles will have different will use different sets of controls, for example the view that a Submitter or County sees, will be different than a System Administrator would see or the controls that a Developer would see would be different from the controls that a non-developer would see. These viewable objects are controlled through the View Permission and they are segregated based on role. |
The Following table contains a list of permissions and the roles that make use of them:
PERMISSION_NAME | ROLES | DESCRIPTION |
---|