Hi,
One of my clients recently purchased EthoTech's Commission Plan for GP. They provide a .xml file with all their SmartList Builder objects and you load it into the system and magically all your SmartLists appear under "The EthoSeries" folder.
However, in this case, they do not. They show up in SmartList Builder, but the users, including "sa" can not see them. At first, I thought this was a simple security issue, so I tried to grant permissions to all users for those objects. In security tasks, I navigated to product ID SmartList, Series Smartlist, Type Smartlist Objects.
Low and behold, all their custom and canned Smartlists are there, EXCEPT the EthoSeries ones! ARGH!
So, I checked the SY09400 table, and low and behold all their smartlists are there, except these new EthoTech ones. Next, I used the "copy" command in SmartList Builder, and made a copy of one of the mystery smartlists... And guess what? It worked! But when I go to open the SmartList, it says "you do not have security privileges to open all the tables used in this SmartList".
I then looked at the SmartList and noted the two tables, RM_Class_MSTR which was in fact a table in SY09400. But the other table, ETI_CP_CustomerClassSetup is ALSO missing from SY09400 and I can NOT add it manually through security in GP.
This leads me to believe that something must be mucked up with the security tables, pertaining specifically to the EthoTech Commision Plan Product.
So, I'm wondering if I do a CLEAR DATA on the SY09400 table, will GP reset everything and put it all back in there? Or will it only put the GP stuff back in there?
It's very odd, I've never seen a situation where SLB objects, or tables from a 3rd party product don't show up anywhere in security, but we are their only client having this issue, so they are puzzled on how to fix it, so I thought I'd throw it out to the community. I can not reproduce on my test system either, it works fine, which is what leads me to believe there is an issue with a specific security table.
*This post is locked for comments
LoL
Reminds me a custom trigger that an former partner had setup on the POP10100 table for god knows what purpose many years back and I got bitten by that trigger during the first SP that I applied on GP the very first time after joining the company. You wouldn't notice it during the upgrade, but all of sudden users were calling that they couldn't save a Purchase Order anymore because of an error message popup on the screen.. It took me some time to figure out the first time (thanks to the SDT), and later wrote a script to disable the default trigger zDT_POP10100U so it wouldn't conflict with the user custom trigger.
With the upgrade to GP2013R2, we could finally get rid of that custom trigger, which seems to have been linked to POE commitment, that we disabled a while ago.
It turns out the whole issue with the SmartList objects had to do with a legacy audit trail trigger that was still on the SLB20000 table. As soon as I removed the trigger, we were able to reimport the Commission Plan smart lists. The odd thing is that they haven't used audit trails for quite some time, and they have done two server migrations and 2 upgrades since uninstalling Audit Trails. Yet, somehow that pesky trigger survived.
Hi Rob,
Did you ever managed to fix those EthoTech object issues in GP ? if so, how did you do it ?
David,
They do have GP power tools. However the security profiler doesn't show anything when I get access denied to the table. It's very odd for sure.
Hi Rob
It is GP Power Tools (or SDT) that adds extra resource info to the table.
Do they have GPPT installed?
David
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,240 Super User 2024 Season 2
Martin Dráb 230,149 Most Valuable Professional
nmaenpaa 101,156