Robert Robinson
Reputable Poster
We have two print queues, the standard QB7333 and JDEPAY which is payroll only. We established security over who can see jobs in these queues as follows:
NON IT USERS: We placed Column Security on the UserID data item in *PUBLIC and set Add and Change to N. This allows users to only see or change their print jobs.
IT USERS: We accessed the data dictionary for the item JOBQUE and turned on Row Security. We then granted back Change and Add in Column Security. We then applied Row Security to the F986110 table, Queue Name "JDEPAY" and set Add, Change, Delete and View to "No". This allows IT to work with all jobs in QB7333, but locks us out of all jobs in JDEPAY, per payroll request.
This security has worked fine until this weekend, when we applied the latest payroll ESU JD22872. After deploying this ESU, IT staff could no longer change the User ID field on the "Submitted Job Search" screen, as if our Column Security over the F986110 had been set to "No" (it has not). To test this, I removed the check from the Row Security field of the JobQueue data item in the data dictionary. I then removed the dddict, ddtext and global tables from my spec directories and allowed these settings to JITI from the server. When I logged back in to OneWorld, I still had no control over the User ID field.
What could have caused this? I did not see anything in that ESU that should have cuased this, and we have deployed other full packages since instituting this security with no problems.
NON IT USERS: We placed Column Security on the UserID data item in *PUBLIC and set Add and Change to N. This allows users to only see or change their print jobs.
IT USERS: We accessed the data dictionary for the item JOBQUE and turned on Row Security. We then granted back Change and Add in Column Security. We then applied Row Security to the F986110 table, Queue Name "JDEPAY" and set Add, Change, Delete and View to "No". This allows IT to work with all jobs in QB7333, but locks us out of all jobs in JDEPAY, per payroll request.
This security has worked fine until this weekend, when we applied the latest payroll ESU JD22872. After deploying this ESU, IT staff could no longer change the User ID field on the "Submitted Job Search" screen, as if our Column Security over the F986110 had been set to "No" (it has not). To test this, I removed the check from the Row Security field of the JobQueue data item in the data dictionary. I then removed the dddict, ddtext and global tables from my spec directories and allowed these settings to JITI from the server. When I logged back in to OneWorld, I still had no control over the User ID field.
What could have caused this? I did not see anything in that ESU that should have cuased this, and we have deployed other full packages since instituting this security with no problems.
