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.

1. 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:

   • ADMINACTIVATE (the old behaviour)
   • USERACTIVATE (the new behaviour)
   • SETACTIVATE (a radio button on the user creation screen
     allowing the admin to choose, on a per-user basis, whether
     this user's account will be activated by the creation
     process or by the password-change-self process. This
     allows user-by-user flexibility for some organisations.
     The default in such cases will be USERACTIVATE unless the
     admin overrides it.)

   The user of an inactive account should not be able to perform
   _any_other_ action from the management UI other than
   password-change-self.

2. 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'.

3. 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.

4. 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:

   • the user accessed any IMAP service
   • he accessed any POP3 service
   • he did an HTTP request on any Merce proxy server
   • the user sent any SMTP email
   • the user logged into the file service
   • the user accessed the Merce management interface
   • the user logged into the Intranet
   • he logged into a Linux Merce compute server
   • he logged in and used Merce VPN service

   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.