This package contains the implementation of the gui which would be used by users to configure their own avialable features and by administrators to manage (create/delete/modify) user accounts. It contains the code which displays the table of all users and the dialog which is used to edit that table.

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 UserPanelis 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 Tasks, 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.