Note: the portion of the interface used by technicians to manage the various servers may be found in the ui package.
Note: the protion of the user interface which is used to log into these screens is in the pw package.
The Editor
is responsible for displaying the table of all end user
accounts. This is screen first shown when someone logs in as an administrator.
Two check boxes at the bottom of the screen control which columns are displayed
in the table: "show admin" controls whether columns only relevant to an
administrator are visible while "show user" controls whether columns which
contain data available to an end user are shown. If both are de-selected, the
table will only contain general data (user id, group, ip address, etc). The
UserTableModel contains a (hard coded) list of all the identifers which belong
to the set of administrative columns and to the set of end user columns. When
one of these boxes is toggled, the appropriate list is retrieved and the columns
at the corresponding indices are removed from the JTables TableColumnModel.
These columns are stored in a vector so they may be re-added later.
The JTable in the Editor is backed by a UserTableModel
which stores
a local copy of all the data for the end user accounts as a Vector of Vectors.
This vector always contains all the data for all the master accounts on the
server, and depending on whether the "show aliases" flag is set in the
Editor
, it may also contain data for aliases. Alias data is also stored
in the aliases
vector so they may be easily added to or removed
from the data
vector.
The UserTableModel
also contains methods which will parse and XML
file received from the provisioning server and convert it into a data vector and
similarly create an XML file from a vector. It also contains methods which will
write back the data from the vector to the provisioning server, including
generation of the appropriate contact lists and CPL scripts for that user.
The UserPanel
is the screen which allows an account for an end user
to be edited or created. This class is used both from the
StandAloneUserEditor
(which an end user sees when modifying his own
account data)and the Editor
.
The editing and display of account data shown in the EdiorPanel is actually
handled by several classes whcih implement the DataEditor
interface. These include all the Feature... classes as well as the
UserInfo
and MarshalInfo
classes. The basic idea is that the
DataEditors are responsible for knowing which pieces of data they are
responsible for handling. Data is identifed by the constants defined in
UserTableModel
. When an account file is loaded from the provisioning
server, the data is parsed and then each data element along with its identifier
is passed to all the DataEditors in turn. If the DataEditor recognizes the data
it loads it into the appropriate field and returns true to indicate the data has
been consumed. The Editor then moves on to the next piece of data. A similar
process is used to retrieve the data after editing form the DataEditors.
This package also makes use of several Task
s, each of which run in
its own thread to ensure that time consuming operations (such as loading all
user data, loading user names, deleting multiple user accounts or editing
multiple accounts) do not tie up the event processing thread.
This package also contains the PServerInterface
class which is
used by all other classes when communicating with the provisioning server. This
class forms a wrapper around the VPPTransactionWrapper
class found
in the comm
package. This class provides various convenience
methods (such as getAllAliasNames or getAllMarshalGroups, for example) which
are intended to save the other classes from having to know how to compose such
requests from the GET/PUT/DELETE/REMOVE requests understood by the
VPPTransaction classes.