Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Security not license for this functionaltiy

Status
Not open for further replies.

alohaakamai3

IS-IT--Management
Aug 11, 2006
482
US
Hi all-

I'm getting this when I try to use the super user password in aloha version 6.4. Is this a matter of removing a file from the BIN directory, or is this feature permanently disabled.

I need to change processors and need to be able to gain access.

Thanks!
 
Not available in 6.4.
In the newer versions your dealer can log in as a super user. They have a digital key and the password is based on time and date, so it changes every 60 seconds.

If none of your current users have access to do this then you will have them log in for you and then you can create a super user by checking everything you can for that user in the backoffice security levels. Don't let them talk you out of it.

Bo

Remember,
If the women don't find you handsome,
they should at least find you handy.
(Red Green)
 
Do you have access to Aloha 6.2? If you do, grab the seclvl.dbf from your 6.4 NEWDATA folder and copy it into your NEWDATA folder on the 6.2 installation. Use the alt-x command and edit the Back Office security level that you currently have so that you have ALL the options, save and exit AlohaMgr. Copy that .dbf back into your 6.4 NEWDATA folder and refresh. You should now have access to everything you need.
 
Thanks Bo and restguy. I'll go that route and try to find the 6.2. I was actually gonna set the processor up in a previous version and try to bring the EDC file over, but that's a lot of hassle, I'll find a 6.2 version. I really don't want to call them and pay them $125 for what they should have already done.

I have half a mind to do what Bo said make them give full access since there's really no reason to lock them out to "protect themselves" anymore, since Aloha usually prevents you from deleting dependencies nowadays.

Thanks again guys.
 
Absolutely have them set you up with all the options if you are unable to use 6.2 to fix your problem. A good rule of thumb is to not delete anything once you are up and running for a day. In the morning is the best time to delete your employees, comps, promos, items, etc... Also don't mess with day parts once you have opened for business. In my opinion the only reason why many RADIANT dealers don't give you complete access to YOUR system is to keep you on the hook for support.
 
Restguy-

That's exactly why they are doing it. Granted, part of it is about PCI security in terms of taking out the ALT X, and part of it is also about protecting users from themselves.

So many years ago, Aloha would let you delete things that were in use, like printers, menu items, etc- stuff that could screw your system up. As the source code has matured, it prevents you from doing most of the really harmful stuff.
Not to mention, they've got stuff locked down that's not a threat on the system I'm talking about. It's clearly being done so you have to call them.

I did follow your instructions, as well as a couple of variations on them, without success so far. The one thing that may have made a big difference though, I tried it on version 6.1 just because that's what I had handy at the time. Does it have to be 6.2?

The result, as near as I could tell, was that when the 6.1 file was moved backed to the 6.4, the new changes would show up in terms of access levles when the file was first dropped into newdata, but after a refresh it would return to the way it was before (I think that's what happened anyway, I tried a lot of different things so it was hard to keep track).

In any case, the problem was that the new changes wouldn't "stick" so for some reason it was reverting back the old file. I didn't try to put place the 6.1 file in both data and new data, since maybe that's where it's getting the old info from?


 
I take it back. I just tried to drop that 6.1 one file and check it out after I posted, and it doesn't ever show the changes that I made on the 6.1 system to the 6.4 security file.
 
I know that it works in 6.2. I haven't tried it with 6.1.
 
If you have an older version CD you can load that on a computer and I can get you the batch files that let you run it locally. Bring your newdata over to it, run a database upgrade or dbconfig, then make your changes. Copy it back and do update the database again. Make copies of everything first in the event something goes wrong.
With the batch files you don't have to load any of the services.

Bo

Remember,
If the women don't find you handsome,
they should at least find you handy.
(Red Green)
 
I believe you also need to copy the seclvldt.dbf file from your other version?
 
posknowitall you are absolutely correct! I am sorry alohaakamai3 it is the sclvldt.dbf that holds that information. If it doesnt work I guess you could always copy over the emp.dbf and login with 6.1 alt-x and give yourself the highest backoffice setting then copy it back into your 6.4 Newdata.
 
Thanks guys, dragging that other file over from along with the original one you mentioned, on that same 6.1 system, worked. You guys rock. My two back up options were mentioned by others as well- editing the employee file or the not so fun process of: downgrading, adding a superuser, then upgrading back.

Thanks again!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top