Getting Started with ESS (Employee Self Service)

Transcription

1 Quintessential School Systems Getting Started with ESS (Employee Self Service) Quintessential School Systems (QSS), 2012 All Rights Reserved American Street, Second Floor --- San Carlos, CA Voice 650/ Fax 650/ Published: December 2011 Revised: January 20122

2 2

3 Contents 1. ESS -- Getting Started... 7 ESS Version... 7 ESS Customization... 8 ESS Navigation... 8 The ADMIN User... 9 ESS Administration What has been installed? Directories and Files Installed by QSS Software File Layout Customer-editable Configuration Files Application Log Files Starting / Stopping ESS Startup / Shutdown Integration Manual Control Checking if Applications are Running Customization Features Home Page Layout Access Help Rights Users, Logging-In, Registration User Types Logging-In Registration User Management Security and Roles Rights Roles Assigning Role(s) to a User

4 Multiple Roles Default Roles Apps Districts District Security General Configuration Summary Users Passwords Security Views HR Multi-district / County Office Considerations Enabling New Districts for Web Use Enable New Districts for ESS Use Configuring New Districts Edit Roles to Grant Access to the New Districts Active Directory Integration Appendix A -- QCC Integration Appendix B HP e3000 and Minisoft ODBC MINISOFT ACCOUNT MINISOFT ODBC VERSION MSJOB.MM.MINISOFT MINISOFT SCHEMA FILES Appendix C -- Caring for Linux Why a Linux Support Agreement is Important Benefits of Linux Support

5 List of Figures Figure 1-1, ESS Version... 7 Figure 1-2, Navigation... 8 Figure 1-3, Current District... 8 Figure 1-4, ADMIN User... 9 Figure 1-5, ADMIN Menu... 9 Figure 4-1, ESS Home Page with Default Template Figure 4-2, Customize Home Page Figure 4-3, Layout Customization Figure 4-4, Personnel Info Screen Figure 4-5, Personnel Info Screen Customization Figure 4-6, Personnel Info Screen Customization Short-cuts Figure 4-7, Access Customization Figure 4-8, Help Customization Figure 5-1, User Types Figure 5-2, Link For Single Sign-On Figure 5-3, Links to Staff Registration Page Figure 5-4, Default Staff Registration Form Figure 5-5, Users Listing Figure 5-6, User Details Figure 5-7, User Details (Continued) Figure 5-8, User Edit Figure 6-2, Listing of Roles Figure 6-3, New Role with General Info Filled In Figure 6-4, Rights Assigned to This Role Figure 6-5, ESS Enabled by This Role Figure 6-6, District 40 Enabled by This Role Figure 6-7, Editing a User Figure 6-8, App-Based Role Security Figure 6-9, Error When Logging-In and ESS as Not Enabled for the User s Role Figure 6-10, District-Based Role Security Figure 6-11, Error When Logging-in and User s District Is Not Assigned ao User s Role Figure 6-12, District Security Figure 7-1, Summary Configuration Figure 7-2, Users Configuration Figure 7-3, Password Configuration Figure 7-4, Security Configuration Figure 7-5, Configuration Views Figure 7-6, HR Configuration Figure 7-7, Employee Leave Screen Figure 7-8, HR Absence Reason Configuration

6 Figure 7-9, HR Leave Configuration Figure 7-10, HR Leave Group Specific Absence Reasons Configuration Figure 8-1, Menu Choice to Enable Multiple Districts for any QSS Web App Figure 8-2, Enabling Districts for Web Use Figure 8-3, Menu Choice to Enable Multiple Districts For ESS Figure 8-4, Enabling Districts for ESS Figure 8-5, Cloning a New District s Configuration Figure 8-6, Change District Main Menu Selector Figure A-1, QCC HR Menu Figure A-2, ESS QCC Configuration Figure B-1, Minisoft Account Structure Figure B-2, Minisoft ODBC Version From The HP e Figure B-3, Minisoft ODBC Version From Linux Figure B-4, MSJOB Is Running Figure B-5, Minisoft Schema Files

7 Employee Self-Service (ESS) provides employees with access to their own personnel, payroll and leave information. ESS improves customer service to employees by allowing employees to access information stored within QCC without asking Human Resources and Payroll staff and without their own QCC access and training. Key Benefits: Improve employee personnel record accuracy by allowing employees access to view their records Reduce Human Resources and Payroll staff time spent answering routine employee questions regarding personnel, payroll and leave information Improve customer service by allowing employees 24-7 access to their personnel, payroll and leave information Provide web-based access that does not require a QCC log in. A web browser is the only required end-user client software, thus no client configuration is required Integrate with QSS/OASIS Provide single sign on through Microsoft Active Directory Support on Linux, PostgreSQL, SQL Server 2005+, IE7+, Firefox ESS -- Getting Started This document is based on ESS version 0.90 and Core version 0.96 and is subject to change as ESS is enhanced and improved. The goal is to assist the ESS Administrator in completing customization, configuring, establishing security, and rolling out ESS to test users prior to full deployment. The introduction below covers basic ESS menu navigation and features common to most ESS pages. ESS Version Clicking the ESS version number causes additional versioning information to be displayed, shown below. A second click reverts back to the simple ESS version string. Figure 1-1, ESS Version 7

8 ESS Customization ESS customization is covered in Section 4 - Customization Features. You can replace the top-left image, change the tooltips that display after hovering the mouse, and select the web site to visit upon clicking the image. However, at this time, the color scheme, the position of the top-left image, the main menu orientation, etc. cannot be customized. ESS Navigation Navigating ESS s menus is similar for all QSS web-based applications, including the QSS Professional Development System (PDS). ESS-specific menus appear at the top-left, where the home, my info menus are visible. Logged-in users with additional rights may also see the employee finder and the absence tracking menus, as shown above. The right half of the top ESS menu starts with the logged-in user s name ( jharrison above) and their user-type ( QCC above). Hovering over the user s login name reveals their employee number (external reference number) and the logout link, shown below. Figure 1-2, Navigation Users with the right to see additional (non-employee) information about themselves can click their login name to display some general user information and data related to usage of ESS. This is covered in Section 5 - Users, Logging-In, Registration. The logged-in user s current district is displayed in the far right top menu. If the logged-in user has the ability to switch districts then the district displayed becomes a drop-down district selector, shown below, when the district number is clicked. Figure 1-3, Current District The displayed district (40 above) is first clicked to reveal the list of districts, and then a district from that list can be selected. If no district is chosen, the original district can be clicked again to hide the dropdown list. This list is populated based on the logged-in user s role(s). Section 8, Multi-district / County Office Considerations, describes how to set up multiple districts. 8

9 The ADMIN User The ADMIN user is special in that it has no roles, has full access to all ESS features, and cannot be deleted. This user is created when ESS is first installed. The ADMIN login name and password are the same as for QCC. Most of the screen shots in the rest of this document were captured when the loggedin user was admin, and thus the top-right menu appears as below (where admin is highlighted). Figure 1-4, ADMIN User ESS Administration If the logged-in user has sufficient rights (Section 6 - Security and Roles), the admin menu is displayed to the right of the user s name, see below. Figure 1-5, ADMIN Menu This admin menu contains most of the sub-menus needed to manage ESS, and it is the gateway to the features describe in the rest of this document. 9

10 2. What has been installed? Directories and Files Installed by QSS All QSS software applications follow standard Linux file layout conventions and install software below the /opt/qss directory, configuration files below the /etc/opt/qss directory, and log files below the /var/opt/qss directory. QSS allows the use of optional application instances at installation time. When applications are installed to a named instance (i.e. production, test, etc), the instance name is appended to the standard directory paths above. For example, installing to the production instance will create application files under /opt/qss/production, /etc/opt/qss/production, and /var/opt/qss/production. This allows multiple versions of the application to be installed on the same server. QSS web applications use the same file layout described above but append an hrsweb subdirectory: 10 /opt/qss[/instance]/hrsweb software (no customer-modifiable files) /etc/opt/qss[/instance]/hrsweb configuration files (customer-modifiable) /var/opt/qss[/instance]/hrsweb log files (grow without bound) The /instance portion is omitted when the default instance is used Software File Layout Web application software files are installed below the directory /opt/qss[/instance]/hrsweb and consist of the following content, none of which should ever be modified by customers because it is subject to being purged when new versions are installed: Time-stamped subdirectories: o hrsweb contains QSS Ruby on Rails code (i.e. configuration, user management, security, etc) that is shared by all web applications. o rails contains the Ruby on Rails framework and the rest of the web application compiled software stack (i.e. Apache, OpenSSL, etc) that is shared by all web applications. o one application-specific subdirectory containing the QSS Ruby on Rails code for each web application. Symbolic links point to the most recent time-stamped subdirectories. All directory references should be via these symbolic links rather than directly to the time-stamped directories. Most recent installation log files. Customer-editable Configuration Files Customer-editable configuration files are installed below the directory /etc/opt/qss[/instance]/hrsweb. Some of the main content that can be found here is:

11 common.sysconfig file and <app>.sysconfig files these files contain parameters used when starting the web application on the Linux server. The common.sysconfig file applies to all web applications in the same instance, and may be overridden by application-specific <app>.sysconfig files. QSS staff sets up these files during the initial installation, but customers may need to make modifications if the hostname or IP addresses of the Linux server change. environment_init.rb this file contains -related parameters used when web applications send . QSS staff sets up this file during the initial installation, but customers will need to modify it if the outgoing mailer server or default From: header address needs to be changed. proxy_*.conf several Apache configuration files are present, of which proxy_common.conf is the most important. For a first-time web application installation, the Apache web server will be configured with a dummy SSL X.509 key and certificate. While this dummy certificate provides secure encrypted communication between web browser and server, web browser users will experience security warnings. It is the responsibility of the customer to obtain a real key and certificate that will be trusted by end-user web browsers. The location of the real key and certificate needs to be configured in the proxy_common.conf file. public subdirectory this subdirectory contains the customer logo & home page content that gets uploaded via the application layout customization web GUI after initial installation. QSS provides default content at initial installation, but it is up to the customer to supply their own real content prior to application roll-out. Application Log Files Application log files reside in the directory /var/opt/qss[/instance]/hrsweb/<app>. All of the log files will grow without bound over time. Customers should keep enough logging data to be useful for QSS troubleshooting purposes but without risking running out of disk space. There are two broad categories of log files: Apache log files the following standard Apache log files exist: o access.log this file logs every access to every resource on the web server and includes data such as the IP address of the web browser, the date and time the resource was accessed, and the resource identifier (URL). o error.log this file logs Apache errors and warnings. If Apache ever fails to start, look in this file first. You may see various Ruby on Rails warnings about software versions and deprecation, but these can be safely ignored since QSS is already aware of them. Ruby on Rails log files these are higher level than the Apache log files and roughly correspond to web browser actions. If you ever see unusual error messages in web browser output, look in these files first: o production.log a summary of web browser actions including the IP address of the web browser, the date and time of the action, and the action identification. o development.log this file will only exist as a result of QSS troubleshooting and is similar to production.log but adds detailed SQL tracing information. 11

12 Additionally, web applications have their own logging facility, accessible via the web browser, where the customer can configure the events to be logged and browse through the logged events. 12

13 3. Starting / Stopping ESS Startup / Shutdown Integration Startup and shutdown for QSS web applications is automatically integrated into the Linux server startup/shutdown sequence at application installation time via the Linux chkconfig command. Manual Control Web applications can be manually started, stopped, or restarted by invoking the qss_hrsweb_ctl script as the Linux root user: /etc/init.d/qss_hrsweb_ctl [-i ins1,ins2, ] [-a app1,app2, ] {start stop restart} By default the script will act on all instances and applications. You may optionally specify comma separated lists of instances and applications, in which case only those instances and applications will be acted on. Note while applications may be restarted while users are logged on and idle, any user who submits a request during the restart will receive an error. Checking if Applications are Running Each web application in each instance writes its top-level process identifier (PID) to /var/opt/qss[/<instance>]/<app>/httpd.pid at application startup (/<instance>]/ as explained in Section 2 - What has been installed?. You can check to see if the application is still running by using the Linux command line: # ps f p $(cat /var/opt/qss[/<instance>]/<app>/httpd.pid) Which in the case of ESS might display: UID PID PPID C STIME TTY TIME CMD root Nov15? 00:00:02 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf Each web application consists of many processes. To display all web application processes currently running on your server: # ps -ef grep hrsweb qssmgr Nov17? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov17? 00:00:26 Rails: /opt/qss/hrsweb/ess qssmgr :43? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr :45? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr :23? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf 13

14 qssmgr :25? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov17? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov17? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov17? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov17? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov17? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf root Nov09? 00:00:05 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_PDS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov09? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_PDS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov09? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_PDS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov09? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_PDS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov09? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_PDS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf qssmgr Nov09? 00:00:00 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_PDS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf root Nov15? 00:00:02 /opt/qss/hrsweb/rails/bin/httpd -DQSS_APP_ESS -k start -f /opt/qss/hrsweb/rails/conf/httpd.conf In the above example listing, you can determine which process belongs to which application by the presence of the DQSS_APP_<app> parameter in the command line string. 14

15 4. Customization Features The logged-in user must have one of the following rights in order to see the admin -> Customize menu and sub-menus: Edit Home Page set to write access, and/or Edit App Layout set to write access, and/or Help Text set to read access (write access needed to modify help text). ESS customization is defined per district, and there is currently no way to clone one district s customization settings to another district. Some of the ESS customization screens have tooltips to aid the administrator. Holding (hovering) the mouse over a text label next to a field will reveal a tooltip with additional information. Not all forms support this feature, but at the time of this writing it is available in the home page and layout tabs. There are currently five customization tabs, each described below. Home Page One of the first customizations to be performed is likely changing the ESS home page. The following home page elements can be customized: Welcome message text (above links and notices) Left-side links (gray pane) Notices (yellow pane) Main content The main content is probably the most important portion of the home page to customize. This is where district specific instructions, greetings, contact information, etc. are displayed. The home page main content installed by QSS (Figure 4-1, ESS Home Page with Default Template) is a template with instructions on how to replace itself with a real home page. 15

16 Figure 4-1, ESS Home Page with Default Template The home page editing screen is shown below in Figure 4-2, Customize Home Page. This form allows the administrator-user to change all of the elements listed above. The Welcome text and tooltip labels provide tooltips. The welcome message can be personalized by including the user s first name, or nickname, etc. as seen in Figure 4-2, Customize Home Page. 16

17 Figure 4-2, Customize Home Page Clicking the Upload Main Content File field brings up the standard Windows file upload dialog, where an HTML file can be selected as the replacement for the ESS home page main content. The gray pane corresponds to the gray links pane on the left-hand side of the home page (seen in Figure 4-1, ESS Home Page with Default Template). New links can be added, existing links deleted or modified, and the link order changed by dragging/dropping using the handle. The yellow pane corresponds to the top notices pane of the home page. New notices can be added and old notices deleted. There is currently no way to edit an existing notice. Layout The Layout tab specifies the image visible in the top, left corner of every ESS page, the name of the application, some tooltips, and the layout of the ESS Personnel Info screen. See Figure 4-3, Layout Customization. 17

18 Figure 4-3, Layout Customization Tooltips are available for every label shown above. The ESS application name ( QSS Employee Self- Service, above) can be customized per district. A new top, left-hand image can be uploaded by clicking the Header image field. The image must be a JPG, GIF, or PNG file. A tooltip made visible when the end-user hovers over the image can be defined by entering text in the URL Mouse-over text field. And, the website linked to when the end-user clicks the image can be specified in the On-click URL field. There is currently one ESS screen which can be more fully customized than the others, and that is the Personnel Info screen, seen in Figure 4-4, Personnel Info Screen, below. 18

19 Figure 4-4, Personnel Info Screen The form to edit the layout of this screen is shown in Figure 4-5, Personnel Info Screen Customization. The following elements of this display can be customized: Title as seen in the browser title bar or tab label Whether or not the screen is visible The names and order of each tab associated with the screen Whether or not the tab is visible Whether or not each field in the screen is visible The name of the field as seen in this screen (blank means use default name) The default name of the field The left, center, right alignment of the field s label The tooltip shown when a user hovers over the field s name. The updateable check boxes are not yet implemented and should be ignored, and the positions of the fields cannot yet be changed. 19

20 Figure 4-5, Personnel Info Screen Customization Tooltips are provided for most labels and column headers. There are short cuts at the bottom of the customize layout screen (Figure 4-6, Personnel Info Screen Customization Short-cuts) which let the administrator set the default values for all field default names and screen-specific names. The default tab names can also be restored by clicking the default link above the row of tabs. Figure 4-6, Personnel Info Screen Customization Short-cuts After clicking Update the changes are usually immediately visible to all ESS users; however, sometimes a browser hard refresh is needed to override browser built-in caching. See for more info on clearing browser caching. 20

21 Access The Access tab defines the districts that ESS can use. The tab displays the districts available for QSS webbased applications. Select the check boxes for the districts available to ESS. The default district is highlighted, as show in Figure 4-7, Access Customization. Figure 4-7, Access Customization The checked districts not only determine which districts have access to ESS, but also which roles are applicable to ESS users having multiple roles. As noted in Section 6 Security and Roles, only the roles which are applicable to the districts selected (see Figure 6-6, District 40 Enabled by This Role) are used in determining a user s access rights. The default district defines the district, visible prior to logging-in to ESS, from which login configuration information is derived. Also, if the current user has the Change District right set then she/he will have the ability to change districts, and, in this case, will see a non-default district highlighted. Help The Help tab allows the built-in ESS help messages to be customized to better meet the needs of each district. admin -> Customize -> Help shows the screen seen in Figure 4-8, Help Customization, where all of the pre-defined help messages are listed with a button for editing each message. Clicking a help message name reveals the text for that message. 21

22 Figure 4-8, Help Customization Rights The Rights tab displays the same screen seen in Figure 6-1, Listing of Rights. Read this paragraph in Section 6 Security and Roles for more information. 22

23 5. Users, Logging-In, Registration User Types All QSS web applications support three basic user types: Staff, QCC, and Guest. These user types are visible in the ESS login screen, show in Figure 5-1, User Types below. Figure 5-1, User Types QCC the QCC user type is for district, or county office, employees who also have a QCC (or QSS/OASIS Traditional ) login id and password. Passwords for these users are managed outside of ESS. QCC users can also connect to ESS directly from the QCC main HR menu. See Appendix A -- QCC Integration for additional information. Staff the Staff user type applies to district employees who are not QCC users. Staff users have a QSS/OASIS PERPAY database record. Guest the Guest user type is for users who are not district employees. In general, this user type is not needed for ESS but is useful for the QSS Professional Development System (PDS) where course instructors may be outside of the district. Domain the Domain choice is related to Active Directory (AD) login and is covered in Section 9 Active Directory Integration. If Active Directory (AD) authentication is configured then Staff and QCC users can login to ESS using their AD credentials. The forget password link is available to districts that have configured password challenge questions, see Section 9 - Active Directory Integration. If users forget their password, they can click this link and they will be prompted with their personal challenge question. If they supply the correct answer, they are automatically issued a temporary password, which is sent to their work address. 23

24 Logging-In Before users (other than the special ADMIN user) can log in to ESS, they must be assigned to at least one role, and that role must grant access to ESS and to the user s district. See Section 6 Security and Roles for more information. QCC users can login to ESS directly from the main QCC HR menu without providing ESS credentials. Appendix A -- QCC Integration shows how to configure this feature in QCC. QCC users do not need to register with ESS since this is done automatically the first time they login to ESS. QCC users are also able to login to ESS via their browser by selecting a user-type of QCC and entering their QCC user name and QCC password. Staff and Guest users need to select the appropriate user-type and provide their ESS user name and ESS password. Before these users can login they must first register, which is described below. To prevent guest users from logging-in to ESS, do not define a default role for them nor manually assign any roles for ESS. For more details see Section 6 Security and Roles. If Active Directory (AD) has been set up (Section 9 Active Directory Integration) then Domain can be selected as a user-type, and the user s AD credentials (the user id and password they use to login to Windows) are entered as their user name and password. Even when using Domain login, staff users are still required to first register. If single-sign-on (SSO) has been configured (Section 9 Active Directory Integration) the user may connect directly from the ESS home page, without supplying any credentials, by clicking the login link (top right) and selecting Automatic, shown in Figure 5-2, Link For Single Sign-On, below. Figure 5-2, Link For Single Sign-On Registration Staff and Guest users must register prior to logging-in to ESS the first time. Once users have registered with ESS, they have registered with all QSS web applications. QCC users are registered automatically the first time they login, and thus they do not need to (and cannot) manually register with ESS. Registration 24

25 is done only once, but it is easy to correct mistakes made during registration. For instance, a user s login name, password, etc. can be updated by an ESS administrator. Staff Registration: The staff registration form is reached by clicking on the register link (top right) of the ESS home page, or the new staff user link at the bottom left of ESS Login screen see Figure 5-3, Links to Staff Registration Page. Figure 5-3, Links to Staff Registration Page Staff registration consists of supplying data, such as the last four digits of the user s Social Security Number, date-of-birth, etc., which authenticates the user. Once this data is verified against the QSS/OASIS database, the user chooses their login name, password, and, if configured, their password challenge question and answer. There are staff registration configuration choices available which are described in more detail in Section 4 - General Configuration. Essentially, staff registration can be set to require confirmation, and/or to capture and automatically update an employee s work address stored in the PERPAY QSS/OASIS database. The screenshot in Figure 5-4, Default Staff Registration Form, below, is the default staff registration form. Variations of this form depend on the staff registration configuration choices described in Section 7 General Configuration. 25

26 Figure 5-4, Default Staff Registration Form If Active Directory (AD) login is enabled (as seen in Figure 5-4, Default Staff Registration Form), the Domain user and Domain password fields also display. This is where users provides their Windows login information so that ESS can map the ESS login name, and thus employee number, to the AD login name. Guest Registration: Guest users are not district employees. They must register before using QSS web applications. However, since a guest does not have an employee number, there is no ESS data available to them it would be rare to have a guest user. A guest user who is not assigned a role cannot login to ESS. User Management Administrator-users with the User Own District right set for write access can manage users within their own district. If the User Any District right is set then users across all districts can be managed. Section 6 Security and Roles covers ESS security. Clicking the top right main menu admin > Users shows a listing of all users in the logged-in user s district. Clicking the detail view link shows the screen displayed in Figure 5-5, Users Listing. Various filters are provided to reduce the number of users listed. For example, only users of a particular user-type can be selected. Or, only users who have been inactive for more than two hours can be selected, etc. Multi-district sites may see the Search all districts check box, which, if checked, lists user from all districts rather than only from the logged-in user s district. 26

27 Figure 5-5, Users Listing Clicking a user s name reveals more information about that user. The example in Figure 5-6, User Details, below, shows more detailed information about the user Aly Bush. The more link can be clicked to show the user s address and phone number. This user has had her password forced to expire, evident by the (password is temporary) text. The next time she logs-in she ll be prompted for a new password. Her roles are listed and her net access rights derived from these two roles is shown, including which applications she has access to, and which districts she can switch to (note the Change District right is set). The user can be temporarily or permanently deleted from this screen and from the Edit screen (Figure 5-8, User Edit) if the logged-in user has the User Delete Own District right set for write access. 27

28 Figure 5-6, User Details 28

29 Figure 5-7, User Details (Continued) Clicking the edit button shows the form seen in Figure 5-8, User Edit, below. The user s employee number (external reference number) and district can only be altered by the special ADMIN user no rights grant the ability to change these two fields. The user s type can be changed where applicable. Changing from a guest to a staff or QCC user type requires additional authentication. 29

30 Figure 5-8, User Edit Users passwords can be expired (and was expired as mentioned above), so that the next time they log in they must supply a new password. The user can be forced to re-authenticate by checking Expire session. The user can also be prevented from logging-in by checking the Disable login check box. If the logged-in user has the Security right set for write access then the roles assigned to this user can be selected from the list shown above. Clicking Update applies these changes immediately. 30

31 6. Security and Roles ESS, like all QSS web applications, uses role-based security users are assigned to one or more roles which control access to various ESS features. A role is simply a collection of rights (permissions), and rights are the fundamental security unit in ESS. Rights grant read-only access, or read/write access, or can deny access to a particular feature or behavior of ESS. The default access when a right is not defined for a role is to deny access. All users must be assigned to at least one role, with the exception of the special ADMIN user who has no roles but is granted full access to all of ESS. A user without a role, or whose role does not grant access to ESS or to the user s district, cannot log in to ESS. In fact, defining a role which grants ESS access and assigning this role to select users is a way to deploy ESS to a few test users in a controlled manner. Rights A right is the most basic security unit of ESS. Each right controls a feature of ESS for the logged-in user. The behavior of a right cannot be altered; however, a user assigned to a role which has the Security right defined for write access is allowed to edit rights via the admin -> Security -> Rights menu, as shown in Figure 6-1, Listing of Rights. Figure 6-1, Listing of Rights Clicking the edit button allows a right s name and description to be altered. Clicking the number under the # users / all column reveals all users who have been assigned this right, via one or more of their roles. In general, rights are left in their default state but roles must be defined. Roles As mentioned above, a role is a collection of rights, each of which is defined to grant read-only access, or read-write access, or to explicitly deny access. A user assigned to a role which has the Security right 31

32 defined for write access is allowed to create and modify roles. This is accomplished via the admin -> Security -> Roles menu, seen in Figure 6-2, Listing of Roles. Figure 6-2, Listing of Roles An existing role can be deleted (permanently or temporarily) or edited. To create a new role, click the Add role link at the top which is seen in Figure 6-3, New Role with General Info Filled In. Figure 6-3, New Role with General Info Filled In This new role is not a default role for any of the three user-types. The priority of this new role is set to 10, and, as noted on the form, a lower priority number indicates a higher priority role. Even though priority is a required field it only comes into play when a user is assigned to multiple roles, which are discussed below. After clicking Save & Continue the Rights tab is displayed seen in Figure 6-4, Rights Assigned to This Role. 32

33 Figure 6-4, Rights Assigned to This Role The rights shown are grouped by their application: Core (common to all QSS web applications), ESS, or PDS. Each right defined in the new role can grant read-only or read/write access. A right can also be defined to deny access, which is the default, but may be explicitly set in cases of multiple roles. If a right is left blank, meaning neutral, then this role is not concerned (is neutral) about that right. A lower priority role may define that right, but if not, the right will be set to its default -- deny access. After defining the rights pertaining to this new role, clicking Update followed by the Apps tab, results in Figure 6-5, ESS Enabled by This Role, where ESS has been checked. 33

34 Figure 6-5, ESS Enabled by This Role This screen defines which application(s) are applicable to this role. If a user s role does not contain the application that the user is attempting to login to then the login is denied. Section 8 Multi-district / County Office Considerations, shows how the applications names are chosen to appear in the screen above. Clicking Update again and then the Districts tab brings up the screen shown in Figure 6-6, District 40 Enabled by This Role, where district 40 has been selected. Figure 6-6, District 40 Enabled by This Role This screen defines which district(s) are applicable to this role. If the user s role does not contain the user s district then that user cannot login to ESS. Section 8 Multi-district / County Office Considerations shows how the districts are chosen to appear in the screen above. Assigning Role(s) to a User To assign a role, or roles, to a user the logged-in administrator-user needs the User Own District or User Any District right set to write access, and the Security right set to write access. Select the user 34

35 as described in Section 5 Users, Logging-In, Registration, (Figure 5-6, User Details), and navigate to the user edit page, which should appear similar to Figure 6-7, Editing a User, below. Figure 6-7, Editing a User Select the desired role(s) and click Update. The security based on the new role(s) is immediately in effect, except that a user is not automatically logged out if the newly assigned role is not associated with a logged-in user s district or with ESS. Multiple Roles A user can be assigned to more than one role and the resulting security is the set of rights defined by the role of highest priority (numerically lowest number). There can be no roles defined with the same priority. If the highest priority role is neutral for a given right (meaning the right has been defined as blank) then the next highest priority role is examined for that right, and if defined, the setting for the right in that role applies. However, if no role defines a particular right then the default of denied is assumed. Users assigned to multiple roles may have roles for different applications and different districts. The net rights granted to the user are the rights defined only by those roles granting access to the application the user is logged-in to and to the user s current district. The user s roles that apply to districts other than the user s current district, or roles that apply to applications other than ESS are ignored. Note: a user s current district can be changed only if the user has the Change district right set covered in Section 8 Multi-district / County Office Considerations. Default Roles As seen in Figure 6-3, New Role with General Info Filled In, a role can be defined as the default role for all new QCC, Staff, and Guest users. When users first register with ESS (or when a QCC user first logs-in 35

36 to ESS and registration occurs automatically) they are assigned the default role based on their user-type. If a default role is not defined, then users will need to be manually assigned a role before they can log in to ESS. QSS recommends defining a default role for all user-types that will access ESS. Consider not defining a default guest role if no guest users are expected to use ESS. The default role should be a relatively unprivileged role (meaning few rights assigned for read or write access) with a low (numerically high) priority. Users needing access to admin-type ESS features should be assigned a separate, non-default role, possibly in addition to their default role. Users can have their default role removed and a new role assigned as discussed above. Apps The Apps tab, seen in Figure 6-8, App-Based Role Security, defines which applications (ESS or PDS, shown below) are associated to this role. Note: the HRSWEB application can be ignored. Figure 6-8, App-Based Role Security Only users assigned to roles which are associated to ESS can log in to ESS see the error message shown in Figure 6-9, Error When Logging-In and ESS as Not Enabled for the User s Role. Likewise, only roles associated with ESS are considered when determining the logged-in ESS user s rights. 36

37 Figure 6-9, Error When Logging-In and ESS as Not Enabled for the User s Role Districts The Districts tab, seen in Figure 6-10, District-Based Role Security, defines which districts are associated to this role. The list of available districts is derived from all QSS web-enabled districts, as described below in District Security see Figure 6-12, District Security. Figure 6-10, District-Based Role Security Only users assigned to roles which are associated to the user s district can login to ESS see the error message shown in Figure 6-11, Error When Logging-in and User s District Is Not Assigned ao User s Role, below. Likewise, only roles associated with the user s current district are considered when determining the logged-in ESS user s rights. 37

38 Figure 6-11, Error When Logging-in and User s District Is Not Assigned ao User s Role District Security The admin -> Security -> Districts menu displays the screen shown in Figure 6-12, District Security, below. Figure 6-12, District Security The list of districts above is based on all districts known to QSS/OASIS. From this list the selected districts can be enabled (made available) to all QSS web-based applications. The list of enabled districts can be further restricted per application see Figure 4-7, Access Customization, and Section 8 Multi-district / County Office Considerations. 38

39 7. General Configuration The logged-in user must have either the Config Own District or Config Any District rights set to read access in order to view the ESS configuration, or set to write access to edit ESS configuration settings. To navigate to the ESS configuration screens select admin -> Configuration in the upper-right ESS menu. ESS configuration allows the administrator to control various ESS features in ways that best meet a district s needs. ESS configuration is defined per district but one district s configuration settings can be copied to another district, and, in fact, cloning is currently the only supported way to create a new configuration record. When ESS is factory installed an initial configuration record is created for the default district. This initial record can be modified for that district and cloned as the basis for other district configuration settings. Most of the ESS configuration screens have built-in help and tooltips to aid the administrator. Clicking the? icon brings up context sensitive help text pertinent to the field in question. Holding (hovering) the mouse over a text label next to a field usually reveals a tooltip with additional information. There are currently six configuration tabs, each described below. Summary The summary tab, Figure 7-1, Summary Configuration, shows most of the ESS configuration settings in a single screen; however, the HR summary (not shown below) is greatly simplified. 39

40 Figure 7-1, Summary Configuration The summary tab is where one district s configuration can be cloned to another district, or where the configuration for a district (other than the logged-in user s district) can be deleted. It is important not to delete a configuration record for a district used by any of the registered ESS users. Users The users tab provides settings to control aspects of a user s login name, Active Directory (AD) settings, and staff registration choices seen in Figure 7-2, Users Configuration. 40

41 Figure 7-2, Users Configuration A user s login name is case-insensitive and can contain letters and numbers, but if additional characters are allowed they need to be listed in the Special chars allowed field. If Active Directory login is desired then the AD fields in the user configuration tab must be filled in. Section 9 -- Active Directory Integration provides a pointer AD integration, but, in summary: 1. AD configuration can be applied separately to QCC users and/or staff users 2. The most important field is Domain search base which specifies the host, port, and domain hierarchical directory node to be used when validating domain users and passwords 3. The Domain Authentication and/or Single Sign-on Authentication rights must be defined in the role assigned to the user in question. 41

42 There are several staff registration choices available. Staff registration can be set up to require confirmation, meaning the user enters their work address and receives an containing a link to complete registration. The QSS/OASIS PERPAY database work field can be updated based on the user-entered work . This may be useful when the PERPAY work field is empty or used for another purpose. Having ESS update the work field saves administrators from doing this task, and is important since the PERPAY work is used by ESS for confirmations and other purposes. The pattern field is critical. It is important to read the help text associated with all staff registration fields. The default for staff registration is to display the form seen in Figure 5-4, Default Staff Registration Form, and, after authenticating the user, allow them to directly login to ESS. Passwords ESS manages passwords for all staff and guest users. Passwords for QCC users are not part of ESS. There are many password configuration choices available, as seen in Figure 7-3, Password Configuration. Figure 7-3, Password Configuration Most of the fields are self-explanatory, and tooltips and help are available for all password configuration fields. One area that may be less clear is the seemingly redundant choice of minimum number of letters, numbers, and special characters (not a number or letter) versus the check boxes indicating that a password may not contain only letters, or may not contain only numbers, etc. In Figure 7-3, Password Configuration, above, two letters must be present in every password and there is no constraint on numbers or special characters. However, since the check box for may not contain only letters is 42

43 unchecked a password could contain all letters. Select the may not contain only letters check box to require the following for passwords: At least one two letters. One number or one special character. ESS keeps track of previous passwords, and, minimally, users cannot repeat their previous password when selecting a new password. The Reuse field controls the number of unique passwords required before a user can repeat a previously used password. Password challenge questions assist when users forget their ESS password. When password challenges are enabled (set to Yes ) the administrator can add challenge questions. There should be plenty of challenge question choices available to users, and these questions should be somewhat personal so that a user s answer cannot be easily guessed. When password challenges are enabled users will be prompted to select their challenge question and to provide their answer. This occurs when staff and guest users register and when they change their own password. Security The only security configuration setting is how long an ESS login session can remain idle before the users must re-authenticate themselves. Figure 7-4, Security Configuration shows the idle timeout choices. Figure 7-4, Security Configuration Once a user s session expires the user must re-enter their ESS login name and password before they can continue using ESS. 43

44 Views The Views configuration tab defines formats for various common screen elements, such as dates, times, phone numbers, etc., shown in Figure 7-5, Configuration Views. Figure 7-5, Configuration Views Single districts may decide to hide their district number by selecting No in the Show district num field. HR A detailed explanation of the HR configuration screen, Figure 7-6, HR Configuration, is beyond the scope of this Getting Started document. In general, ESS needs to be told if the district is using new or old style credentials, and enhanced or standard position control. For old style credentials a credentialing district number can be provided. Position control is necessary to determine an employee s primary work location. 44

45 Figure 7-6, HR Configuration There are many set-up options in the Leave area that influence the Leave screen (Figure 7-7, Employee Leave Screen) seen by an ESS end-user. 45

46 Figure 7-7, Employee Leave Screen Absence reasons can be globally configured and/or individually configured per leave group. The global absence reason configuration screen defines the default settings for each absence reason which also become the initial values if that absence reason is assigned to a leave group. Global absence reasons values can be overridden by specific leave group absence reason settings. Figure 7-8, HR Absence Reason Configuration, shows three customized absence reasons sorted by their Display Name. Absence reason (AR) CL has been globally disabled (unless it is overridden by a leave group), meaning it will not be shown in the detailed leave activity screen, nor available for an employee to choose as an absence reason when requesting leave. AR A2 has a more meaningful display name defined and is set up as an Accrual type. AR A1 also has a more user-friendly display name, is defined as an Accrual type, and will have activity (in addition to balances) summarized in the ESS employee leave screen. Figure 7-8, HR Absence Reason Configuration 46

47 A generic leave note can be established for all leave groups, and leave group-specific notes can be defined, one per leave group. Also, a note for each leave bucket/category can be created, as shown in Figure 7-9, HR Leave Configuration. You can do the following: Make leave buckets hidden or visible in the employee leave screen. Make leave bucket names more user friendly. Configure leave buckets to show balances only, usage/activity only, or both. Establish the relationship between the buckets. Virtual buckets can be added to a leave group by clicking the add bucket link. A virtual bucket may be useful for customers needing more than the ten supported real buckets. A virtual bucket allows leave activity to be reported in the leave screen for absence reasons not currently assigned to a real bucket. Once a leave group has been configured, it may be cloned to all leave groups in the district, with various cloning options available. Figure 7-9, HR Leave Configuration Individual absence reasons which have been assigned to a specific leave group are seen by clicking the link showing the number of absence reasons. Figure 7-10, HR Leave Group Specific Absence Reasons Configuration shows the absence reasons defined for leave group 6A, and allows any of these absence 47

48 reasons to be disabled for that leave group. Absence Reason A0 has been disabled for this leave group. A5 has been marked to show activity and to be visible to employees requesting leave. A7 s type has been defined as Usage. The Bkts column shows which buckets, if any, each absence reason hits meaning balances are maintained for activities targeting this absence reason. The blank fields under the Bkts column are where one or more virtual buckets can be assigned to an absence reason. The absence reasons configuration for a specific leave group can be cloned to all leave groups in the district where they are included. Figure 7-10, HR Leave Group Specific Absence Reasons Configuration 48

49 8. Multi-district / County Office Considerations Enabling district access to ESS is a multi-step process. Follow the directions in the order listed in this section to enable additional districts beyond the initial district that was established at ESS installation time. Enabling New Districts for Web Use The first step in rolling out a new district is to enable the district for potential use by any QSS web application. The menus to navigate to this screen are: admin -> Security -> Districts, shown in Figure 8-1, Menu Choice to Enable Multiple Districts for any QSS Web App. Figure 8-1, Menu Choice to Enable Multiple Districts for any QSS Web App Click the check box next to the district name in the Districts Enabled for Web Applications screen for each district to enable for web use, and then click the Update button. See Figure 8-2, Enabling Districts for Web Use, below, and Figure 6-12, District Security in Section 6 Security and Roles. Figure 8-2, Enabling Districts for Web Use Enable New Districts for ESS Use To select districts allowed to use ESS, chose the admin -> Customize -> Access menu, as seen in Figure 8-3, Menu Choice to Enable Multiple Districts For ESS, below, and discussed in Section 4 - Customization Features (Figure 4-7, Access Customization). 49

50 Figure 8-3, Menu Choice to Enable Multiple Districts For ESS The districts selected in the previous step are listed in the Customize ESS Access screen, Figure 8-4, Enabling Districts for ESS, and in Section 4 - Customization Features (Figure 4-7, Access Customization). The selected districts will be enabled for ESS. One of the checked districts must be designated as the default district, which determines the initial configuration settings for users viewing the ESS home page but not yet logged-in to ESS. Figure 8-4, Enabling Districts for ESS Configuring New Districts The next step is to configure the new district, which consists of copying the configuration setting for the administrator s current district to the new district. Selecting admin -> Configuration -> Summary from the main menu leads to the screen shown in Figure 8-5, Cloning a New District s Configuration. Select the new district from the Clone this config to district selector and then click the Clone button. 50

51 Figure 8-5, Cloning a New District s Configuration The current district s configuration is then copied to the new district. There may be warnings related to leave groups in the current district that are not present in the cloned-to district. In these cases the configuration settings for those leave groups are skipped, but the remaining configuration settings are copied. If the administrator-user has the Change District right set (and they should), clicking the District: selector on the top-right menu reveals the districts available to the logged-in user. Click the drop-down list of districts to select the newly cloned district, shown in Figure 8-6, Change District Main Menu Selector. Figure 8-6, Change District Main Menu Selector Follow the configuration process described in Section 7 General Configuration -- to make additional changes to the cloned configuration. Edit Roles to Grant Access to the New Districts The final steps are to create new roles or edit existing roles that should grant access to ESS and to the new district(s). The process is described in Section 6 Security and Roles. ESS needs to be checked in the role s Apps tab and the new district needs to be checked in the role s Districts tab. Additionally, appropriate ESS-specific rights, if any, should be assigned in the role s Rights tab. Lastly, all users who need to access the new district(s) via ESS need to be assigned the correct role(s), described in Section 6 Security and Roles and shown in Figure 6-5, ESS Enabled by This Role. 51

52 9. Active Directory Integration For complete details on how to set up Microsoft Active Directory integration with QSS web applications, please visit the QSS web site at and then log into the Secure Support area. Proceed to the QSS/OASIS Online Documentation section and then to the QSS/OASIS Manuals subsection where you can find the HRSWEB Active Directory How-To document. 52

53 Appendix A -- QCC Integration QCC users (see Section 5 - Users, Logging-In, Registration) can login to ESS directly from the QCC HR menu, see Figure A-1, QCC HR Menu, below. Figure A-1, QCC HR Menu Clicking the Employee Self Service menu brings up the default browser, then logs in users with their QCC user name and QCC password. If this is the first time a QCC user has logged-in to ESS, the system automatically registers the user with QCC credentials. Use QCC to configure the connection to the ESS URL as follows: System Admin -> System Security -> App/Module/Tasks upper tab -> Module/Tasks tab Select Application = QPERSONNEL Select Type = WWW Scroll right and enter (without the quotes) for the ESS URL -- include the = at the end. <hostname> is the external name or external IP address of the ESS server. This is seen in Figure A-2, ESS QCC Configuration. Enter $IDONLY in the Command column. 53

54 Figure A-2, ESS QCC Configuration Save the changes and ESS will be available directly from QCC. 54

55 Appendix B HP e3000 and Minisoft ODBC QSS/OASIS Version L customers can skip this appendix. QSS/OASIS Version H customers use the HP e3000 Image database which only is supported on an HP e3000 server. Minisoft s ODBC product, allows an application (such as ESS) to connect to, read from, and update an Image database. MINISOFT ACCOUNT Minisoft ODBC must be installed on the HP e3000 server prior to installing ESS on the Linux server. The MINSOFT account will be created (if it does not already exist) with the MGR user and two groups: MM and PUB. See Figure B-1, Minisoft Account Structure, below, which shows the account structure. 55

56 Figure B-1, Minisoft Account Structure MINISOFT ODBC VERSION On the HP e3000, enter the odbcsrvr command shown in Figure B-2, Minisoft ODBC Version From The HP e3000, below, to see the current version of ODBCSRVR. The errors displayed can be ignored. Figure B-2, Minisoft ODBC Version From The HP e3000 On the ESS Linux server, either of the following two commands reveals the ODBC version, seen below in Figure B-3, Minisoft ODBC Version From Linux: 56

57 Figure B-3, Minisoft ODBC Version From Linux MSJOB.MM.MINISOFT The Minisoft ODBC driver listens to a configured port (default is 30006) for SQL requests coming from the Linux computer which is hosting ESS. This is accomplished via the MSJOB.MM.MINISOFT job which must always be running when ESS is running. The streaming of the MSJOB job should be added to the SYSSTART file so that it is automatically streamed when the HP e3000 is restarted. Use the :showjob command to verify that MSJOB is executing, see Figure B-4, MSJOB Is Running. Figure B-4, MSJOB Is Running MINISOFT SCHEMA FILES QSS uses Minisoft schema files to map certain Image fields to more closely correspond to their version L counterparts. Note: these Minisoft schema files are completely independent of the Image schema files read by DBSCHEMA.PUB.SYS when creating Image databases. The three Minisoft schema files used by ESS are: MENUMS, PERPAYMS, and SYSCTLMS in the SCHEMA group of the QSSUSER account, as shown below in Figure B-5, Minisoft Schema Files: Figure B-5, Minisoft Schema Files 57

58 Before a schema file can be modified (currently only performed by QSS) the MSJOB job needs to be either aborted or the ODBC connections to the above schema files must be closed (by stopping ESS on the Linux server). 58

59 Appendix C -- Caring for Linux Why a Linux Support Agreement is Important QSS recommends that customers contract with a vendor to support Linux to enable customers to get the most out of their Linux server. The Linux server may have been less expensive than your previous servers; however, it is essential that you maintain a support contract to ensure that Linux functions optimally through maintaining system updates and security. QSS web applications depend on certain Linux software packages being present prior to web application installation. If these dependent packages are missing, web application installation will be delayed until a Linux software support agreement is obtained and the missing packages are installed. Benefits of Linux Support Receiving the latest enterprise software, including security and bug fixes and enhancements 24 hours a day Linux issue resolution assistance and access to technical expertise (similar to the QSS Forums and Account Manager relationship) Incorporating new features without compromising the stability of the system Enable supported solutions from certified vendors for hardware and software 59