Hello everyone, long time lurker, first time poster here.
We are coming up on a cutover from Epicor 9/Progress to a reimplementation on Epicor 10. After the cutover, I want users to have access to our E9 environment (we’ll leave this up for a while, likely 1 year or more) but I do not want anyone to have the ability to enter new data into E9.
In testing, it seems like the “Read Only” checkbox in Menu Maintenance does this trick, even wiping out right-click open-with capabilities. Problem is, there’s a LOT of these to click through and my time is going to be tight as-is during the cutover.
Does anyone know of a way to flip all E9 menu entries to Read Only in bulk? Humbly begging for a handout at this point if anyone has any tricks up their sleeve =)
Since the old environment is not going to be updated, why bother with the read only. Any attempt at lockdown will only bring headaches and any attempt to use the transactions will be futile.
I tried that (in another life) and it was nothing but heartache.
Charlie
aidacra
(Nathan your friendly neighborhood Support Engineer)
3
I have a way that should be easy to implement–give me a few minutes to put it together. There’s a magic record that can be created that can accomplish this.
EDIT 1: might take me a little bit, I have to dust off my ABL fu. A million times easier in TSQL.
EDIT 2: I forgot how long it can take to compile Progress procedures
EDIT 3: so, magic record has to go on a table that we only included in SQL. Adding the table to my Progress DB now to test to see if it will work.
EDIT 4: I was wrong about Edit 3. It’s Friday and I haven’t had enough caffeine.
EDIT 5: I wonder how long it will take someone at work to notice that I am working on something like this when I should be doing something productive.
Hey Charlie, I’ve asked that question myself and have been told we want to maintain historical data integrity without having to worry about new data inadvertently skewing anything. Furthermore, we are DMT-ing in recent historical data (2 years) into E10. So during that 24 hour-or-so timeframe we might miss a new order, for example, if it’s entered after the cut-off of when the data is pulled for transport to E10.
All that anyone would really need access to is trackers, and I’ve considered removing menu security from everything else except a new “trackers only” menu. But that still leaves the right-click, open-with available, which our users are savvy in using.
I know, one would hope that all of the communication we’re putting out for this that users would leave well enough alone…but habits die hard, y’know?
Do you remember and would you mind sharing what issues you ran into with the read-only approach in your lockdown attempt?
NOTE: This is one of those permanent procedures. You run this against your database, it’s now in read-only forever. So, test this not in production please and thank you and only run this against the current production E905 PG db once you are live on E10.
DISCLAIMER: If someone runs this against their E905 PG db, Support will not help revert the db back to a non read-only state. Run this at your own risk.
Download the attached magic_readonly_record.bpm to your server that has the Admin Tools shortcut.
Rename file to magic_readonly_record.r.
Launch your Admin Tools.
Log in with a security manager user.
Click on Run Progress Program.
Click the Magnifying glass button, and browse to the magci_readonly_record.r file.
Wow. This is absolutely fantastic Nathan! I’ll have to sneak you a couple of beers or something at the next user group meetup—I owe ya.
Thanks for the help!
-ben
aidacra
(Nathan your friendly neighborhood Support Engineer)
11
This community is very fortunate to have someone like @josecgomez around as he was the voice of my better angels. Here is the undo_magic_readonly_record.bpm file for those that might ever need it.
Execute it the same way as the magic_readonly_record.bpm file.
All of the terms and conditions of my original post stand (use this at your own risk, back up your dbs first, blah blah blah).
If you mess up your database by making it read-only using the above process AND you didn’t backup your database first AND you didn’t test this in a non-production database first, you can correct it (maybe?) by running this.
