I have a user who has been assigned the AP clerk role and I have checked the tasks assigned to this role. When she goes to the vendor inquiry screen and selects a payment to a vendor and then zooms down to the payment and clicks Recreate Check Stub, she gets the "not privileged to run this report" message. What tables can I check and what values should I be looking at to correct this?
*This post is locked for comments
Or Open the GP Power Tools Security Profiler and run the report. No logging. No SQL. No Clear Data. Instant data. Instant Fix.
That's another option, but troubleshooting security is relatively easy once you understand what you're doing.
To troubleshoot table/report permission issues, it helps to populate the SY09400 table:
1.Click Microsoft Dynamics GP, point to Maintenance, and then click Clear Data to open the Clear Data window.
2.On the Display menu, click Physical.
3.In the Series list, click System.
4.In the Tables pane, click the Security Resource Descriptions table, and then click Insert.
5.Click OK.
6.Click Yes.
7.In the Report Destination window, select the Screen check box, and then click OK to send the report to the screen.
8.Close the report. At this point the SY09400 system table should be populated with the additional information.
Then once you have the dexsql.log call to the zDP_SY10000_SS_1 procedure, causing the permissions error, you can use that information against the SY09400 table to find out what the object is, then also use that information against the SY10600 and SY10700 tables to determine what security roles and security tasks give users access to that object.
The SY10500 table shows what security roles users are assigned and the SY10000 view has to have a record for each object a user has permissions to.
Thanks for presenting another option though.
Wow, so much work for something that GP Power Tools could have solved in seconds.
Next time use GP Power Tools http://WinthropDC.com/GPPT
Thanks again, Derek. I will add this script to my GP 2018 upgrade toolkit.
I'm happy to hear that was our resolution.
It may be worth running the scripts from this blog for GP 2018:
It won't overwrite any security table records you already have, but it will add anything that may be missing, just in case other security records are not there.
Thanks
and there was much rejoicing!!!
Thanks for your help in resolving this. I will hang onto this for other installations.
Ok, so your SY10600 table shows those 6 security roles give a user access to the INQ_FIN_001* task, however, your SY10700 table is stating that there isn't any record at all for this report, as the only record returned with a securityid of 1180 is for a secrestype of 2, which is a window, not a report.
Run this script against your system database:
INSERT SY10700
Values ('INQ_FIN_001*', 0, 1180, 23)
After adding this record in the SY10700, then the SY10000 view will show users actually having access to the report, which should resolve the permissions issue.
Let me know if this still doesn't work for you.
Thanks
It was already there so I tried unclicking, saving and then reclicking and that did not help.
Here is what is returned from select * from SY10600 where SECURITYTASKID = 'INQ_FIN_001*'
SECURITYROLEID SECURITYTASKID DEX_ROW_ID
ACCOUNTING MANAGER* INQ_FIN_001* 3659
AP CLERK* INQ_FIN_001* 3750
BOOKKEEPER* INQ_FIN_001* 3834
CERTIFIED ACCOUNTANT* INQ_FIN_001* 3930
GPCHECK INQ_FIN_001* 983
AR CLERK* INQ_FIN_001* 4388
This script
select * from SY10700 where SECURITYID = 1180 and secrestype in (2,23)
returns
SECURITYTASKID DICTID SECURITYID SECRESTYPE DEX_ROW_ID
ADMIN_INV_011* 0 1180 2 24895
This script
Select * from SY10000 where DICTID = 0 and SECRESTYPE in (2,23) and SECURITYID = 1180
USERID CMPANYID DICTID SECRESTYPE SECURITYID ALTDICID Modified DEX_ROW_ID
Sabrina 1 0 2 1180 0 0 24895
Sabrina2 -1 0 2 1180 0 0 24895
Sabrina2 1 0 2 1180 0 0 24895
Sabrina2 2 0 2 1180 0 0 24895
Sabrina2 3 0 2 1180 0 0 24895
So she has access to the screen and not the report. I get the same results on our system. I will assign the INQ_FIN_001* to the AP Task Role, if it is not already there.
If you run this script against your system database for GP:
select * from SY10600 where SECURITYTASKID = 'INQ_FIN_001*'
Does it return all of the following?
ACCOUNTING MANAGER*
AP CLERK*
BOOKKEEPER*
CERTIFIED ACCOUNTANT*
LIMITED USER - FIN*
If so, then run this script next against the same system database:
select * from SY10700 where SECURITYID = 1180 and secrestype = 23
Does it show one record with the SECURITYTASKID of 'INQ_FIN_001*', DICTID of 0 (zero), SECURITYID of 1180 and SECRESTYPE of 23?
If either of these scripts isn't returning what I mentioned above, then you may be missing some setup in the default security tables.
If both of these scripts return the correct results, then the next step would be to run the following script:
Select * from SY10000 where DICTID = 0 and SECRESTYPE = 23 and SECURITYID = 1180
The users specified in the SY10000 script will be the non-Powerusers that have access to this 'Reprint Check Remittance' report. There is also a CMPANYID column you can use to differentiate which users in which companies have access to this report.
If any non-Powerusers are assigned to any of the 5 security roles above, they should be given access to the INQ_FIN_001* task, thus should have access to this report, by default.
Let me know if you have any questions.
Thanks
#1
André Arnaud de Cal...
292,468
Super User 2025 Season 1
#2
Martin Dráb
231,289
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (
