*********************************************************
*							*
*			BUGGER V2			*
*		      User Amendment 			*
*							*
*		Document Date: 20 May 2011		*
*							*
*********************************************************


Introduction
--------------

BUGGER V1 utilised individual pages for each process/task.
Whilst this does what is required, single entry points for
each task is preferable in order to reduce the workload
required when creating templates (amongst other tasks)

This document details the planned implementation of BUGGER V2's
user amendment processes.



User Addition
--------------

User Addition is currently handled by the page adduser.php
(available to Administrators only), and opens in a Pop-up
window launched from the Admin Settings Panel of BUGGER v2.




User Editing/Deletion
----------------------

In order to implement User Editing, the administrator will
require the ability to view a list of users in order to 
select which user to edit (an option to directly enter the
username is also planned).

It is proposed that the function used in User Addition is
adjusted to accept a variable defining whether to use display
a blank form, or to pre-populate with a users details (the 
username will, of course, also need to be passed).

If a username is passed, a 'Delete User' button should also
be displayed.




Post Processing
----------------

User addition currently utilises the function add_user to
process the supplied data. As the underlying SQL utilises
an INSERT statement, it is ill-suited for updating a users
record.


Its is proposed that the function add_user be updated to
pass the submitted data to either db_insert_add_user or a
new function (db_insert_update_user?) depending on the
type of transaction being performed by the user.

This can be identified in the POST data through use of 
a hidden field (form generation function will need updating
to implement support for this).




User Deletion
--------------

In order to implement user deletion, the proposed solution
is a checkbox marked "Delete" displayed on the User Amendment
form.

This box will be set to default to unchecked, and will have an
OnUpdate event associated with it to request that the user 
confirm the deletion before they can proceed.

The user would then save the changes as they would if they were 
simply amending the record.

POST processing functions should be updated to check whether the
Delete flag has been set, and then proceed accordingly.


Notes
-----

User Deletion policy needs to be decided upon, there are two options;

Deleting a user will;

- Simply delete the users account
- Delete all input provided by the user (Comments, Bugs, Posts etc.)

Although the latter is more privacy friendly, it may also deprive
other users of important resources (Bug Reports etc.). 

It's proposed that the former is implemented as the default action,
but that administrators may also have the option to action the 
latter through a seperate menu (for combating spam etc.)

When implementing the latter option, it's suggested that the 
interface allow the Administrator to select which element types
to delete. So a checkbox would be provided (and ticked by default?)
for Bugs, Documents, Releases, Comments etc.



Password Changes
-----------------

Provision has not yet been made for users to amend their login
password. This can be implemented as a pop-up window and the option
should be displayed as part of function display_login_menu





*********************************************************
*							*
*	        Copyright (C) 2011 B Tasker		*
*		      DOCUMENT END			*
*							*
*********************************************************