Adv Security on Version 8

[Luvsql]

I have upgraded our databases to version 8 in a test environment. Since now all our users can access everything (ie in version 7.5 used secrurity to restrict palettes and not windows), I am now having to redo each user class. I have gone into the adv security, setup the accelerated option to not use (ie we have 15 companies, 60 users and it recommends to not use). I have selected one user class. I then go to toolbar > tools > system and start to deselect each window. After just clicking off one, it turns into an hour glass for a good 30 seconds. If I then try to select all the windows in the list, it takes 3 minutes until it has unselected every window.

At this rate, it's going to take me a good 20 minutes just to fix one class. Why is this so slow? I am running Great Plains 8 on Windows 2003 server with all latest service packs. The data is local so it's not a network issue.

 

[Luvsql]

As well, as SOON as I modified a user class within Adv Security (only unmarked windows under tools > setup, utilities and routines) and now no user within this class can run integrations that have to do with receivables (all receive error "Unknown GP field subtype 25710." I had the exact same issue in version 7.5 after modifying security using adv security, but was hoping this had been fixed.

This specific error has to do with alternate GP windows. However, I never even touched the cards or transaction parts within Adv Security. If I look now, they are all set to Great Plains and not project accounting (even though project accounting is installed, so even if had access to project, should still work).

I also had an issue that I contacted Microsoft on where one class that I had been playing with access within Adv Security actually caused apply information within payables to go all crazy (only one class was modified using adv security and all users experienced same issue, not a coincidence).

Does anyone else have problems with Adv Security?

 

[stef315]

Luvsql, you always seem to answer your own questions! Maybe you are too stressed?

I have only ventured to use Advanced Security for one client on version 8. The client still hasn't used Great Plains much so I'm not sure if they have problems yet.

I suppose it takes a long time because setting permissions on multiple SQL objects for multiple database users. Setting permissions seems to take a while. For instance, when you give a user access to a company, there is usually a slight pause.

Stinks that it doesn't work but I may just continue using regular Great Plains security until you tell us all the issues are worked out.

Good luck!

 

[Luvsql]

It doesn't actually apply the permissions until you click on the Apply button (after you click on or remove a setting, it keeps tabs of all the pending changes). That part is actually quite fast because I'm assuming it's just running a sql script to update.

 

[winthropdc]

Luvsql

In version 8.0 I would suggest using the Accelerator regardless of size. If you use the accelerator you will be able to set security with a single click for each menu. The accelerator is a cache table which allows Advanced Security to read each node of the tree without needed to read the child nodes more than once. Note that if you use the accelerator and it is background processing, you do not have to wait for it to complete processing, but while it is working in the background, foreground performance will be decreased.

If the class you are changing has many users in it, you may decide to turn off the "Display class changes on affected users" option. This will then not apply class changes to the users of that class until you press apply and so will speed up the initial setting of the class.

I know we have discussed the issue you are having with integration manager before. Please note that when running integration manager, access to modified or alternate windows is actually overridden. Integration Manager will always use the original window regardless of what security says.

If security says you are using an alternate it is possible that the 3rd party products triggers will fire because they think the alternate is in use, but because IM has forced the original to be used you will now get an illegal address error from Dexterity when it tries to reference a 3rd party field which is not on the original form.

Your message shows the resource ID of 25710. All 3rd party resources are above 22000, so this is definately a third party resource.

Can you please swap the access back to the original windows for the windows being used by the integration and see what happens?

As the original developer of Omni Security and later Advanced Security and having done the re-write for v8.0, I know that the code works. I have looked in the bug logs for Advanced Security and there are no bugs logged for the issues you describe.

There is nothing wrong with Advanced Security and the v8.0 code is 10 to 20 faster than v7.x.


David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Luvsql]

The access has always been Great Plains (ie I created the class from scratch using GP's user class setup with no restrictions, all windows default to use GP and I would manually have to tell it to use PA or some other third party). I have verfied again that there are no alternate GP windows being used. That is why the error does not make any sense.

 

[Luvsql]

I have changed all the options, including the default to grant security to all alternate windows and reports. I created a brand new class ID in user class setup, no restrictions. I then unmarked all windows under setup, utilities and routines. I assigned User A to new class. Errors during integration are 25710. If I disable PA, it changes to 1567. If I disable both PA and extender, it's 25710. If I disable just Extender, it's 1567.

If I do not have it marked to grant access to alternate windows, why is it doing so, even though it shows that it is not? If I do nothing with Adv Security, our users within this new class can run integrations fine.

 

[Luvsql]

I removed ALL our third party products, except for the defaults that are instlled with version 8. I created a brand new user class using GP. I then assigned user to it and logged into GP (again, no third parties except defaults) and was able to run.

I then modified the user class in Adv Security with options marked as you suggested, then removed Setup, Utilities and Routines. Logged into GP and ran integration. Error is "Unknown GP field subtype 1565."

There are no third parties now.

 

[winthropdc]

Did you see the options for handling unregistered resources. They will answer your question from the other discussion group.

The grant access to alternate and grant access to modified window options only take affect when granting access back to a resource which was previously denied. And the only if a modified resource exists or only one alternate is available for that resource.

To try and work out what is happening can you try this for me, still with no other 3rd parties and the Advanced Security grant options unchecked:

1) Create a new user and grant access to the company.
2) Test the integration.
3) via SQL look at the SY02000 table for that user and company combination and store the results of the query.
4) With Advanced Security remove access to the Setup, Utilities and Routines.
5) Test the integration.
6) via SQL look at the SY02000 table for that user and company combination and store the results of the query.
7) With Advanced Security grant access back to the Setup, Utilities and Routines.
8) Test the integration.
9) via SQL look at the SY02000 table for that user and company combination and store the results of the query.

The results of 3 and 9 should be the same. You could also try doing the security changes with Standard Security and comparing results.

I don't understand how Advanced Security can be the cause when all it does is provide a better interface to the standard security tables.

What sort of integration is this.. I was looking at the dictionary to see what datatypes and fields have resource IDs of 1565 and 1657. There are either PM or POP related.

David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Luvsql]

1) Created brand new user called 'integration' no class and assigned to company A.
2) Logged into Company A with new user and ran integration without error.
3) Checked SY02000 and have 161 records. Saved results to file.
4) Logged in as sa and went into adv security and just chose the integation user. Unmarked File > Maintenance, All Setup, All Utilties and All routines (except for sales > aging, statements, reprint statments and writeffs) as that is what I did to the other class/users.
5) Logged in as integration user and ran integration Received errors "Unknown GP field subtype 1565."
6) SY02000 now has 365 rows. Saved results to file.
7) Logged into company as sa and marked the above back on for user integration.
8) Checked Sy02000 table for user integration. There are 161 records again. Saved results to file.
9) Logged in as user integration. Integration ran fine.

 

[winthropdc]

Luvsql

This proves that it is not Advanced Security that is actually causing the problem. If it was, the final integration would have failed.

So, the problem is that when you are denying access in step 4, you are removing access to something that the integration needs. This should not really happen in the By Menu view, as this avoids denying access to hidden or system forms.

Lets try one more test.

Create two users, use Advanced Security to deny access to the windows for one user and use Standard Security to deny access to the other user.

Then test the integration to make sure that the first user fails and the second user works.

Then compare the records in the security table for each user. We should be able to find the difference and then we can explore why that has an effect.

David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Luvsql]

I would say this proves, without a doubt, that it is advanced security causing the issue. Before touching adv security, there are no errors, then as soon as I use the product, I get errors. You had mentioned before that errors in the 20000 series were third parties, but now that I have removed the third parties, it is back to an error 1565 (which is Great Plains).

 

[winthropdc]

No the error is with what you are removing. You (using Advanced Security) are taking away access to something that is needed. If you use the By Dictionary view and remove exactly the same windows as you removed with Standard Security the problem will not occur. Advanced Security is not the problem.... it is just the tool you are using to create the problem.

David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[winthropdc]

FYI: I have written a FAQ document to help you remove lists in v8.0 and posted it on this group.

David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Luvsql]

I now have more problems with another class of users. I modified a class to remove access to routines, setup, all financial transactions etc. They are in Sales Transaction Entry. After entering an item number, they cannot tab. Shift-Tab does not go backwards, and no buttons on the field are editable somehow. If they click on ctrl-H to do the historical lookup, they get an error about permissions. I selected permananent for that user and it opened the 'Customer Item Lookup" window. This is not listed anywhere in Adv Security under Tools (the only place where restrictions were removed). If I look under inquiry for sales and inventory, that class has everything checked.

What is going on with this module?

 

[Luvsql]

I created a brand new user and assigned it to this class. I entered a new sales order. I entered an item number. I then went to ctrl-h to lookup history, received error that I do not have permission to Customer Item Lookup (gpslookup) and clicked No. I then could not click on X, void, save, anything. I deleted the row and still cannot do anything. The only way out of the window is to ctrl-alt delete.

It appears that after using Advanced Security, I have to go in as a user with that class and test evertying single window, transaction, third party, everything. Why did it REMOVE access to a third party window (this Customer Item Lookup that you open with Ctrl-H is a defaulted install of 7.5) when nothing was removed from any inquiry windows in sales or inventory?

Why does it remove access from things I did not unselect?

 

[Luvsql]

None of the classes that were modified can access this window. When User A in this class received the error, I entered the system password and changed it to permanent to allow. THis user now has 903 records in the SY02000 and the other users in this class have 904. I have found the one difference.

User with issue

UserID DictID ResType ResID Alias AltDictID
elainem 1838 2 22036 0 1838
elainem 1838 23 22036 0 1838
elainem 3107 2 22036 0 3107


User Without Issue

UserID DictID ResType ResID Alias AltDictID
isabellec 1838 23 22036 0 1838
isabellec 3107 2 22036 0 3107


The extra line for DictID is the Technical Services Tool, which is an MBS module, and has literally nothing to do with Sales ORder Entry or Historical Lookups. If I run a delete statement on the SY02000 to get rid of the 1838 2 record, the user can then use Ctrl-H and then the rest of the buttons in the window.

 

[winthropdc]

Luvsql

Please stop blaming Advanced Security, it is only a different interface into the standard security model and only does what it is told.

I am not sure what 3rd party addon you have installed, but Control-H on my v7.5 system opens help. The Item History window that you are describing seems to be added by a third party dictionary. If that windows does not appear directly on the menu structure, it will not be visible or controllable by the By Menu view. Please identify the product and look in the DYNAMICS.SET for its Product ID and Product Name.

Then use the By Dictionary view to ensure that access is granted to those windows. If you find a resource in the By Dictionary view and click on it on the left hand tree, it will show which users/classes have access to it on the right hand list. Please use this to confirm that access is granted as required.

I am not sure what products 1838 and 3107 are, you will need to check in the DYNAMICS.SET. The record with a Restype of 23 is denying access to a report.

David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

mailto:dmusgrav@online.microsoft.com

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Luvsql]

1878 is Excel-Based Budgeting, which is a core GP module.

 

[Luvsql]

BTW: Using Ctrl-H for Historical Lookups only works when you are in the Sales Transaction Entry screen.