Assigning Roles to a Khameleon User

Assigning Roles to a Khameleon User

Roles control the menu options that are displayed and enabled when a user accesses the Khameleon application.  Essentially, roles control what screens a user can access.  The section of this document on Privileges illustrates how Privileges control what a user can do once they enter the screens to which they have been granted access.

The section below will highlight the naming convention used for roles in the Khameleon application, and how a combination of roles assigned to a particular user might be configured.

In order to create or modify user accounts, an Administrator must be granted the role of DDS_ACCTG_SUPER or DDS_SY_MGR.  The role DDS_ACCTG_SUPER has no restrictions and is the ‘super user’ role.

By default, the role DDS_USER is assigned to all new users.  This grants access for System Users to log into the application.  The list of additional roles can be viewed by clicking the list of values button on the next available line.

All Khameleon specific roles will start with DDS_XX, with XX representing the software module to which the role is associated.  Depending on DBA preference, there may also be native Oracle database roles present in this list (JAVA, OLAP, OEM, etc.)  These native Oracle roles are not used by the Khameleon application.

As mentioned above, module based roles will all start with DDS_XX, respective to the module itself.  The roles below exist for each module and can be granted to users as needed.

DDS_XX_USER – grants left hand vertical menu access to this module.

DDS_XX_REP_QRY – grants left hand vertical access to this module, and also enables all menu options within this module under the Inquiry and Reports menu headings.

DDS_XX_MGR - grants left hand vertical access to this module, and also enables all menu options within this module.

For batch processing based functions within a particular module, there is typically a role abbreviation representing that process, yielding two different roles – one ending in _INP, the other ending in _UPD.  

Batch Processing roles ending in _INP allow the user to Input Batch Transactions and run Edit List Reports.

Batch Processing roles ending in _UPD allow the user to Update or Post Batch Transactions.

As an example, DDS_GL_JE_INP grants access to input Journal Entries and run Edit List reports for Journal Entry batches.  DDS_GL_JE_UPD grants access to update Journal Entries.