Adept is a browser-based system. As such it is inherently multi-user.
With more than one operator, the need for user management becomes
manifest. The Adept Library provides this support with a User object -
a persistent DAO. The User object contains a name and password for
authentication. Authentication is not enough. Any system that needs
user management needs a concept of authorisation. Who can access which
form. Who can update which data. Adept provides this functionality with
the concept of groups. The system holds persistent one list of group
names in the object User.Groups. The User.Groups object is quite
literally and simply an array of string group names. The User object
keep an array of indexes to groups the user belongs to. Groups can be
added but not deleted. Actually there is an exception. If a user is
added and deleted immediately, their personal group is removed. When a
new user is created, a group of the same name is also created. They are
automatically joined to the groups Everybody and the one with their own
name. A newly created system will automatically create users and groups
with the names Everybody and Administrator. It is a good idea to give
both these users passwords as soon as practical. How is it used? The
system requires that someone be logged in at all times. It can be
configured to ask or to default to Everybody for an open interface. The
log-in can be told to 'stick' so that the user need only log in once on
a single system. The Adept user is for authorisation and convenience,
not high security. Use the client operating system for that. For this
reason there is no user time-out. The User object for the current user
is attached to the session. The menu system, for example, limits
display of selections by group names. Only users in the group
Administrator, for example, can open the page to add or administer
users and groups. In a similar manner, tree nodes can be set to be
hidden or unopenable for users not is a specific set of groups.
Finally, edit components can be forced to hidden or read-only mode.
Lastly, all applications have a group. The list of available
applications on the main desktop will only include those that the
current user is in the group for. So, when creating an account for
Sally, make sure that she is in the Accounts group if she is to open
the accounts system.

--
Posted By Paul Marrington to Adept Open Source Library at 8/31/2007
11:59:00 AM

I am using Adept Bookings as a proof-of-concept system for the Adept
Development System. The first thing that became immediately obvious was
that now it is time to implement user management. Authentication Adept
user management provides authorisation, not full authentication. So,
let's start with talking authentication. Authentication is to stop
unauthorised access. It typically involves log-in and some sort of
time-out so that a workstation locks if left unused. These functions
are best done by the operating system. Adept supports operating system
authentication by allowing you to stay logged in on any user account on
any hardware. Use the optional check-box for this function. Once
checked then any time you go to Adept in the future you will continue
where you left off. Only your user account will have this ability - so
security requirements are covered. With fast user switching (available
on Windows XP/Visa, OS X and some Linux distributions), we end up with
a powerful and easily shared system. As each person moves away and the
screen-saver kicks in, the next user will need to switch to their
account. If they have Adept running it will still be available for use
- exactly where they left it. This works well in a shared front-desk
situation. If you want more security, add a swipe or proximity card to
the mix. Installation and maintenance are an operating system task and
independent of Adept. First Start When a virgin system is created - and
the installation does not create a special system - then two
users/groups are created - Administrator and Everybody. Both can be
logged in and neither has a password. Only Administrator can create or
lock out users - or change groups. Log in as Administrator and create
users for all people who will use the system. Give then access to the
groups that will be named after the applications they are using. First
Log-in The first time you go to Adept on a new system you will be
presented with a log-in screen. If the application is single-user,
choose the user you maintain and set it to stay logged in. You will not
be bothered again. If more than one person use the system the the
administrator will have created user names to suite. Resist working as
Administrator or the user with the same name as the application unless
absolutely necessary. Authorisation Once logged in the user object is
attached to the session. Each user belongs to two or more groups.
Various components recognise groups and change functionality
accordingly.
- Menu: Menu items can be displayed or hidden based on use groups. If
the node element
- element has a groups attribute, then only users in those groups will
see this menu item.
- Applications: The Desktop menu has an Application item. Valid
applications are in the configuration files. Any PROPERTIES.TXT in any
META-INF can have an entry named adept.application. This entry includes
the name and group that can run this application.
adept.application=/BookingsAdept,BookingsAdept.
- Trees: have 4 attributes - displayFor, hideFor, openFor, lockFor. The
first two allow a branch to be hidden or displayed. The latter two
specify whether the branch can be opened if it has sub-elements.
- Input: have 4 attributes - displayFor, hideFor, editFor, lockFor. The
first two allow a branch to be hidden or displayed. The latter two
define whether the branch can be edited or only displayed as read-only.

--
Posted By Paul Marrington to Adept Development System at 9/03/2007
01:21:00 PM