This page (revision-22) was last changed on 26-Nov-2021 10:22 by Karen Parrott

This page was created on 26-Nov-2021 10:22 by Kevin Higgs

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
22 26-Nov-2021 10:22 17 KB Karen Parrott to previous
21 26-Nov-2021 10:22 17 KB Karen Parrott to previous | to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 15 removed one line
At line 50 removed one line
\\
At line 52 changed one line
\\
\\
At line 54 removed one line
At line 56 removed one line
At line 54 added 27 lines
!!New Database Function\\
To ensure the SITE_REFERENCE_ID column is populated correctly, on all INSERT triggers, the P2K_SESSION.DETERMINE_SITE function will pull from the values documented in the lexicons above if the site is NULL. The value inserted into the SITE_REFERNCE_ID will not be changed on any subsequent updates to the record.\\
\\
Before going through the upgrade, review the value of your current Site Code (IMST) as this will have an impact on some DB user names and roles (see section “New Admin Users”). We recommend keeping the site code short if you’re still using the Admin User Interface. Site records on IMST will be set up for the Base site and the Master site.\\
!!Changes to Forms
!Maintain Form Definition (IMFDH)\\
The [IMFDH] screen is one of the key places where users may notice changes in the multi-tenant environment.\\
In the new multi-tenant set-up, users are not able to make any changes to preloaded data, including form definitions, unless logged in as a MASTER (Admin UI) user.\\
Preloaded screens will still allow the addition of fields as long as they are “User Defined”. Any preloaded aspect of the form will no longer be modifiable. It has always been a best practice to not alter the default set up of a form. In Personality 5.05, this practice is not just best practice; it is now a requirement.\\
!!User Profile Changes (IMUS)\\
There are several changes to the ADMIN user roles in 5.05. The P2K user profile should no longer be used within the Admin or Browser User Interface. The P2K user profile has been replaced by MASTER and MASTER_[[SITE_CODE] user profiles. The P2K_USER role, as defined on IMRO, is still a requirement for all users and should be included in all user profile setups, including these new administrator profiles.\\
!__P2K User Profile__\\
The P2K user profile should no longer be used to log into the application in the Admin User Interface. \\
The P2K user profile will not have access to any data and should be treated as a “Schema” only.   If you sign in as P2K, the system will appear to be __empty__.  \\
The P2K user profile user is replaced with the MASTER_(SITE_CODE) user profile. \\
The P2K user profile can still be used to see everything at the Database level. \\
Symmetry is site independent with installation and the owner is still under the P2K schema.\\
!__MASTER User Profile__\\
The MASTER user profile is used to access and modify global data. In the SAAS model, this user is not accessible to end users. In the non-SAAS model, MASTER is added to every database.  \\
Custom integrations, links, ODBC connections, etc. that currently use P2K need to be changed to the Master user of the base site. The P2K user profile can be used to access data at the DB level and the MASTER user profile should not be used.\\
Preloaded items cannot be changed from any sites except the MASTER. While MASTER can modify forms, it is not the recommended practice.\\
When logged into the Admin User Interface, the MASTER user profile is not able to access any employee data. A new entity was created named ADMINISTRATION. This entity and all its related data are visible to the MASTER user alone. This entity is hidden from all other user types logging into the environment.\\
The SITE CODE for the MASTER user profile on IMST is MASTER.\\
\\
When accessing the Browser UI, the MASTER user profile is associated with an identity record on IEID called “Super User.” \\
The Access Code used to log into the BROWSER UI on IEID is ADMIN_MASTER.  \\
The User Profile associated with this identity record is MASTER\\
At line 59 changed one line
New Database Function\\
!__MASTER_[[SITE_CODE] User Profile__\\
At line 84 added 7 lines
While the MASTER user profile controls the records that are global in nature, a site-specific admin user is also required. The MASTER_[[SITE_CODE] user profile now replaces the P2K user profile when accessing the User Interface. \\
\\
In this document [[SITE_CODE] represents the value found in the SITE_CODE column found on IMST.\\
After the database is loaded and prior to installation of the 5.05 software, please update the site code (IMST) to make the code meaningful and to not have spaces or dots. Once the 5.05 software is loaded, the master admin and self-service users are created using the site code.  \\
P2K preferences and logics (i.e. Setting preferences on forms, Establishing Report Parameters, Publishing Usercalcs,etc) will be transferred to the MASTER_(SITE_CODE) user profile.\\
Preferences that are noted as Global should be established using the new MASTER_(SITE_CODE) profile.\\
Note - To avoid any conflicts, all scheduled jobs should be canceled before any major upgrades and then rescheduled after. \\
At line 92 added 3 lines
The username to log into the Admin User Interface is the MASTER_[[SITE_CODE] from IMST\\
For example: the site code in our test environment is TRAIN, therefore the sign-in user is MASTER_TRAIN.\\
After completing the upgrade process, users may initially log in with the password “p2k”. It is highly recommended that clients change their password as soon as possible.\\
At line 63 changed 5 lines
To ensure the SITE_REFERENCE_ID column is populated
correctly, on all INSERT triggers, the P2K_SESSION.DETERMINE_SITE function will
pull from the values documented in the lexicons above if the site is NULL. The
value inserted into the SITE_REFERNCE_ID will not be changed on any subsequent
updates to the record.\\
Site data is only visible to a user logged into that site. \\
At line 98 added one line
When accessing the Browser User Interface, the MASTER_[[SITE_CODE] user profile is associated with an identity record on IEID called “Super User1”. The number in the name of the user increases with each new tenant record (User1, User2, User3, etc.). Most clients are not expected to have more than one tenant record. \\
At line 100 added one line
The Access Code used to log into the BROWSER user interface on IEID is ADMIN_MASTER_[[SITE_CODE].  \\
At line 71 changed one line
 \\
This identity record’s user profile is MASTER_[[SITE_CODE].\\
At line 75 removed 220 lines
Before going through the upgrade, review the value
of your current Site Code (IMST) as this will have an impact on some DB user
names and roles (see section “New Admin Users”). We recommend keeping the site
code short if you’re still using the Admin User Interface. Site records on IMST
will be set up for the Base site and the Master site.\\
Changes to Forms
(IMFDH)\\
The IMFDH screen is one of the key places where
users may notice changes in the multi-tenant environment.\\
In the new multi-tenant set-up, users are not able
to make any changes to preloaded data, including form definitions, unless
logged in as a MASTER (Admin UI) user.\\
Preloaded screens will still allow the addition of
fields as long as they are “User Defined”. Any preloaded aspect of the form
will no longer be modifiable. It has always been a best practice to not alter
the default set up of a form. In Personality 5.05, this practice is not just
best practice; it is now a requirement.\\
User Profile
Changes (IMUS)\\
There are several changes to the ADMIN user roles
in 5.05. The P2K user profile should no longer be used within the Admin or
Browser User Interface. The P2K user profile has been replaced by MASTER and
MASTER_[[SITE_CODE] user profiles. The P2K_USER role, as defined on IMRO, is
still a requirement for all users and should be included in all user profile
setups, including these new administrator profiles.\\
__P2K User Profile__\\
The P2K user profile should no longer be used to
log into the application in the Admin User Interface. \\
The P2K user profile will not have access to any
data and should be treated as a “Schema” only.   If you sign in as P2K,
the system will appear to be __empty__.  \\
The P2K user profile user is replaced with the
MASTER_(SITE_CODE) user profile. \\
The P2K user profile can still be used to see
everything at the Database level. \\
Symmetry is site independent with installation and
the owner is still under the P2K schema.\\
__MASTER User Profile__\\
The MASTER user profile is used to access and
modify global data. In the SAAS model, this user is [[not accessible to end
users. In the non-SAAS model, MASTER is added to every database.  \\ |]
Custom integrations, links, ODBC connections, etc.
that currently use P2K need to be changed to the Master user of the base site.
The P2K user profile can be used to access data at the DB level and the MASTER
user profile should [[__not__ be
used.\\ |]
Preloaded items cannot be changed from any sites
except the MASTER. While MASTER can modify forms, it is [[__not__ the recommended
practice.  \\ |]
When logged into the Admin User Interface, the
MASTER user profile is not able to access any employee data. A new entity was
created named ADMINISTRATION. This entity and all its related data are visible
to the MASTER user alone. This entity is hidden from all other user types
logging into the environment.\\
The SITE CODE for the MASTER user profile on IMST
is MASTER.\\
 \\
When accessing the Browser UI, the MASTER user
profile is associated with an identity record on IEID called “Super
User.” \\
The Access Code used to log into the BROWSER UI on
IEID is ADMIN_MASTER.  \\
The User Profile associated with this identity
record is MASTER\\
__MASTER_[[SITE_CODE] User
Profile__\\
While the MASTER user profile controls the records
that are global in nature, a site-specific admin user is also required. The
MASTER_[[SITE_CODE] user profile now replaces the P2K user profile when
accessing the User Interface. \\
 \\
In this document [[SITE_CODE] represents the value
found in the SITE_CODE column found on IMST.\\
After the database is loaded and prior to
installation of the 5.05 software, please update the site code (IMST) to make
the code meaningful and to [[__not__ have spaces or dots. Once the 5.05 software is loaded, the
master admin and self-service users are created using the site
code.  \\
|]
P2K preferences and logics (i.e. Setting
preferences on forms, Establishing Report Parameters, Publishing Usercalcs,
etc) will be transferred to the MASTER_(SITE_CODE) user profile.\\
Preferences that are noted as Global should be established
using the new MASTER_(SITE_CODE) profile.\\
Note - To avoid any conflicts, all scheduled jobs
should be canceled before any major upgrades and then rescheduled after. \\
The username to log into the Admin User Interface
is the MASTER_[[SITE_CODE] from IMST\\
For example: the site code in our test environment
is TRAIN, therefore the sign-in user is MASTER_TRAIN.\\
After completing the upgrade process, users may
initially log in with the password “p2k”. It is highly recommended that clients
change their password as soon as possible.\\
Site data is only visible to a user logged into
that site. \\
When accessing the Browser User Interface, the
MASTER_[[SITE_CODE] user profile is associated with an identity record on IEID
called “Super User1”. The number in the name of the user increases with each
new tenant record (User1, User2, User3, etc.). Most clients are not expected to
have more than one tenant record. \\
The Access Code used to log into the BROWSER user
interface on IEID is ADMIN_MASTER_[[SITE_CODE].  \\
This identity record’s user profile is
MASTER_[[SITE_CODE].\\
At line 457 changed 11 lines
 
||__FUNCTION - Analytics
Dashboard__||__DESCRIPTION__
||__FUNCTION - Analytics Dashboard__||__DESCRIPTION__
At line 469 removed 3 lines
At line 474 changed 17 lines
||__FUNCTION - Analytics
Dashboard Panel__||__DESCRIPTION__
|BBDD|Benefits
Dynamic Dashboard
|BBSH|Benefits
Static Dashboard
||__FUNCTION - Analytics Dashboard Panel__||__DESCRIPTION__
|BBDD|Benefits Dynamic Dashboard
|BBSH|Benefits Static Dashboard
At line 492 changed 8 lines
|BDQL|Dash
- Quick Link Icons
|BDQL|Dash - Quick Link Icons
At line 501 changed 38 lines
|BEDD|Human
Resources Dynamic Dashboard
|BESH|Human
Resources Static Splash
|BET4|Print
My T4 form
|BEW2|Print
My W2 form
|BPDD|Payroll
Dynamic Dashboard
|BPSH|Payroll
Static Dashboard
|BPTC|Dash
- Total Compensation
|BEDD|Human Resources Dynamic Dashboard
|BESH|Human Resources Static Splash
|BET4|Print My T4 form
|BEW2|Print My W2 form
|BPDD|Payroll Dynamic Dashboard
|BPSH|Payroll Static Dashboard
|BPTC|Dash - Total Compensation
At line 540 removed 3 lines
At line 544 removed 3 lines
At line 549 changed 7 lines
||__FUNCTION -
Interactive Screen__||__DESCRIPTION__
||__FUNCTION - Interactive Screen__||__DESCRIPTION__
At line 557 removed 3 lines
At line 561 removed 3 lines
At line 565 removed 3 lines
At line 569 changed 8 lines
|IRNB|Maintain
NGV Benefits
|IRNB|Maintain NGV Benefits
At line 579 removed 2 lines
At line 582 removed 3 lines
At line 586 removed 3 lines
At line 590 removed 3 lines
At line 594 removed 3 lines
At line 601 changed 10 lines
||__FUNCTION - Self
Service Screen__||__DESCRIPTION__
|WAOD|Onboarding
Dashboard
||__FUNCTION - Self Service Screen__||__DESCRIPTION__
|WAOD|Onboarding Dashboard
At line 612 removed 3 lines
At line 616 removed 3 lines
At line 620 removed 3 lines
At line 624 removed 3 lines
At line 628 removed 3 lines
At line 632 removed 3 lines
At line 636 removed 3 lines
At line 640 removed 3 lines
At line 644 removed 3 lines
At line 648 removed 3 lines
At line 652 removed 3 lines
At line 656 removed 3 lines
At line 661 changed 7 lines
||__FUNCTION - Update
Process__||__DESCRIPTION__
||__FUNCTION - Update Process__||__DESCRIPTION__
At line 669 removed 3 lines
At line 673 removed 3 lines
At line 677 removed 3 lines
At line 681 removed 3 lines
At line 685 removed 3 lines
At line 689 removed 3 lines
At line 693 removed 3 lines
At line 698 removed 2 lines
At line 333 added one line
Below is a list of the new or existing reports that were converted to Windward, most are in .xlsx format.\\
At line 703 removed 10 lines
Below is a list of the new or existing reports that
were converted to Windward, most are in .xlsx format.\\
 
At line 714 removed 3 lines
At line 718 removed 3 lines
At line 722 changed 8 lines
|RFBU|
Budget Structures Report
|RFBU| Budget Structures Report
At line 731 removed 3 lines
At line 735 removed 3 lines
At line 740 changed 14 lines
New Preferences\\
Below is a list of the new preferences.\\
 
__New Preferences__\\
Below is a list of the new preferences. For more information see the [system preferences|SYSTEM PREFERENCE] page.\\
At line 755 changed 10 lines
|ADD_CALENDAR_APPOINTMENT|The preference ADD CALENDAR
APPOINTMENT will allow a user to automatically send an email and add an
appointment to outlook calendar for an event (Implemented for Leave Request and
Class Registration)
|ADD_CALENDAR_APPOINTMENT|The preference ADD CALENDAR APPOINTMENT will allow a user to automatically send an email and add an appointment to outlook calendar for an event (Implemented for Leave Request and Class Registration)
At line 766 changed 67 lines
|DB_OUTPUT_BASE_FLDR|This preference is for new logic that allows output
directory option on reports and dynamically creates and saves directory on DB
|DEFAULT ESS ROLE|This preference is used to Auto assign IMUS on IEID
upon hire via IEQH if the IDJB IMUS is missing.
|DEFAULT_RANGE_MIDPOINT|Defaults the Position Wage Rate from
the Job’s Salary Range.
|DFT_PRENOTE_REQUIRED|This preference will allow the user to turn OFF the
PRENOTE_REQUIRED toggle on insert. Default value is Y.\\ \\ If this preference
is set to N the PRENOTE_REQUIRED toggle will be turned OFF.\\ \\ NOTE: t the
PRENOTE_REQUIRED toggle is turned ON only when the PRENOTE_DAYS on Payroll Bank
Accounts is not null. \\ \\ Setting the preference value to Y will not
turn the PRENOTE_REQUIRED toggle ON if the PRENOTE_DAYS on Payroll Bank Accounts
is null\\
|DFLT ESS ROLE|This preference is used to Auto assign IMUS on IEID
upon hire via IEQH if the IDJB IMUS is missing.
|DFLT_ESS_EFF_DT|This preference is used for the Start Date override
for IEID access begins.
|DFLT_ESS_USER |When an employee is hired via
IEQH or via API/conversion process, they should automatically have access to
self-service. The agency should be able to have an IMST setting that is the
default user profile for the identity. There should also be an IMST for the
default accessor_key. This should allow for work email as this will be Neogov's
approach for unique user logins
 \\
\\
\\
 
|DB_OUTPUT_BASE_FLDR|This preference is for new logic that allows output directory option on reports and dynamically creates and saves directory on DB
|DEFAULT ESS ROLE|This preference is used to Auto assign IMUS on IEID upon hire via IEQH if the IDJB IMUS is missing.
|DEFAULT_RANGE_MIDPOINT|Defaults the Position Wage Rate from the Job’s Salary Range.
|DFT_PRENOTE_REQUIRED|This preference will allow the user to turn OFF the PRENOTE_REQUIRED toggle on insert. Default value is Y.\\ \\ If this preference is set to N the PRENOTE_REQUIRED toggle will be turned OFF.\\ \\ NOTE: the PRENOTE_REQUIRED toggle is turned ON only when the PRENOTE_DAYS on Payroll Bank Accounts is not null. \\ \\ Setting the preference value to Y will not turn the PRENOTE_REQUIRED toggle ON if the PRENOTE_DAYS on Payroll Bank Accounts is null
|DFLT ESS ROLE|This preference is used to Auto assign IMUS on IEID upon hire via IEQH if the IDJB IMUS is missing.
|DFLT_ESS_EFF_DT|This preference is used for the Start Date override for IEID access begins.
|DFLT_ESS_USER |When an employee is hired via IEQH or via API/conversion process, they should automatically have access to self-service. The agency should be able to have an IMST setting that is the default user profile for the identity. There should also be an IMST for the default accessor_key. This should allow for work email as this will be Neogov's approach for unique user logins