System Administrator rights (OpenInsight 32-Bit)
At 03 JUL 2006 09:23:40AM Gerald Lovel wrote:
Using the Database Manager's User Management… option, I define new user GERALD as a System Administrator for the ATLAS application. When I open the ATLAS application as user GERALD and go to the Application Manager Entity menu, all options are greyed out. When I open the ATLAS application as use ATLAS, Entity menu options are enabled.
Is there a spot in the documentation which adequately explains this behavior? Or are non-administrative System Administrators a bug?
At 03 JUL 2006 09:54AM Warren Auyong wrote:
Did you give GERALD create permissions?
At 03 JUL 2006 11:30AM Gerald Lovel wrote:
In that the application create permissions were $PUBLIC, I think I did.
I also created SYSPROG in the ATLAS account and then noted that the Access permission of System Administrator cannot be changed, nor can the SYSPROG user be deleted from child applications once added. However, SYSPROG works just like GERALD in the child applications – Entity menu options are disabled.
Incidentally, can anyone explain how to remove the SYSPROG user from a child application?
At 03 JUL 2006 11:55AM Warren Auyong wrote:
In the Application Manager -] File -] Application Properties is "GERALD" in the list of "Create Permit"? Otherwise the Entity Menu will be disabled for user "GERALD".
At 03 JUL 2006 02:21PM Gerald Lovel wrote:
In the "Creation Permit", one may either explicitly list users or specify PUBLIC$ which is the result of adding all users. I agree with you, adding users by name does give them create permissions and enable the Entity menu selections. However, if you say "Add all" in setting permissions then the program uses PUBLIC$ and prohibits adding users by name. And in this case, none of the users actually have creation rights.
Now back to my original question: What is the basis for this and where is this documented?
At 04 JUL 2006 12:44PM Warren Auyong wrote:
Fascinating. I never saw a need to give create permissions to all except in a pure development environment, but even then it has its advantages of creating users of various access levels for testing purposes.
As to the anomalous behavior with ALL & PUBLIC$ I would suspect an oversight or "bug" if you wish, but it could well be by design.
In regards to "SYSPROG" I would hazard to guess that "SYSPROG" is hard coded into much of the system code as it is in ARev or Rev. You are probably running up against some of the safeguards associated with this "reserved" name. Most systems have a "God" account/user and messing with that usually has fatal consequences.