After the installation process is completed, a user called admin
should be created which will have adminstrative rights.
A message should be displayed after installation showing admin
credentials. The first user of the system with administrative
privileges should be created by the user admin.
A cron job should run daily which should connect to the database
and check if there is any user other than admin who has administrative
rights. If there is such a user then the user admin is deleted and add
a system alias of admin.
There should be a set of restricted names like admin, sysadmin, etc.
which should not be allowed to be set as intranet ids.
Whenever the admin creates a user account, the entries should be
made in the database of the master server but no back-end processing
should happen to activate the various services for this new user on
any server. In other words, no entry should happen in any Cyrus IMAP
server, any /etc/passwd, any Apache user list, etc.
The account should get activated only when the user logs in using
his own username and password through the Merce user page, and
changes his password. The system will track that this user account
needs a self-change of password. When it detects that this
self-change of password has happened, it will release the account
details for back-end processing and all the slave servers will be
told about the account.
In other words, a new account will be 'created' but will not be
'active' in Merce till the user changes his own password.
If the admin deletes the created-but-inactive user's account,
deletion will be allowed. If the admin searches all the accounts,
the created-but-inactive accounts will show up just like normal
accounts, but with an inactive status.
If the admin changes the created-but-inactive user's password from
XXX to YYY, the system will allow the password change, but the
account will not be activated. The user will now have to login with
the YYY password to change his password, though. The XXX password
won't work.
This implies that even the admin can't login as a newly created user
and check the newly created user's email, unless he first logs in as
the new user and does a self-change of password.
The password change UI program must note the activation of a new
account as a special event and log it specially. Its back-end code
will of course change now, because all the back-end work that was
triggered by the user-create program earlier will now be triggered
by the change-password-self program.
This is a change to the behaviour of Merce user management which
introduces a new policy setting for the customer. This change must
be controlled by a switch controlling policy in the global params
of Merce. In other words, each installation of Merce may choose to
use the old or new behaviour, depending on their enterprise user
management policty. This switch will have one of three values:
The user of an inactive account should not be able to perform
_any_other_ action from the management UI other than
password-change-self.
When an admin resets an existing active user's password, the account
should go into the inactive state. The master server should know and
remember the new password so that the affected user can log in using
the newly-set password and do a password-change-self action. But
the services of Merce should all get deactivated; their passwords
should be set to some random string which even the admin doesn't know.
When the user does a password-change-self, the newly set password
will be propagated to all services on all slaves and the account
will become 'activated'.
When the user logs in on his user-page on the Merce management
interface, the screen should include a message somewhere giving
the date, time and IP address of the last time that he accessed the
management interface.
User presence tracking: I want to track time and IP address for the
last N occurrences of each of the following events for each user:
This must then be displayed for the admin to see against each user.
Value of N will be smallish, less than 50. This value will be a
global param.