Creation of development user apart from Admin User

[padmajapriy...@gmail.com]

Hi Ronald  ,

Hope you are doing well. Please help me on understanding the concept of separate Users in Schedulix.

In schedulix we have the functionality to create separate user, but for separate Web users only permission restriction is on the Schedulix GUI.

But is there any possibility that apart from the Admin User , I can create one separate user who can login with his credentials and create /execute jobs and batches separately without the changes being reflected and impacting that of the Admin User.

For example :

In Admin user I have few base RMS jobs defined.

Now another DEV user is created who logs in using his own credentials and will not be able to see these base RMS jobs in his BATCHES AND JOBS window. 

Also if he creates any new jobs and runs them or schedules them to run , it wont reflect in the RUNNING JOBS and BATCHES AND JOBS window for the Admin user when he/she logs in with their own credentials.

Regards,

Padmaja

[Ronald Jeninga]

Hi Padmaja,

first of all it is important to understand that a single Zope instance can connect to several scheduling servers and a scheduling server can be connected to multiple Zope instances.

There's a many-to-many relationship between the two.

Both in Zope and in the scheduling server you can create users.

The user as created in Zope is allowed to use the GUI. But in order to run scheduling server commands, the Zope user must create an entry in the BICsuite!Server Connections table in the Web User Dialogue.

Such an entry consists of a server name, a (scheduling server) user name and the corresponding password.

Within schedulix we've implemented a kind of all or nothing approach.

A user is either owner of an object (i.e. member of the group owning the object), or not.

If a user is owner, that user can do anything with the object. But if not, the object is often even invisible to that user.

There are owned and unowned objects.

The unowned objects are exit state definitions, exit state profiles, exit state mappings, resource state profiles, resource state mappings, resource state definitions, footprints end environments.

The rest is owned.

An unowned object can only be modified (or dropped) by a member of the ADMIN group.

Owned objects can be modified by their owners and all members of the ADMIN group. All other can't even see those objects.

I hope this helps somewhat.

Best regards,

Ronald