Bugs -- please use the bug tracking database for this project on SourceForge!  
REPORT BUGS HERE

Uncatagorized:

* Troy's ticket/billing updates : BILLING
* Goals (Troy #2 message)

1. CUSTOMERS will be able to:
         enter TT's via web, or email.
         Check a tickets status that he/she created.
        Recieve notification of change in ticket status ( configurable )
        add a note to an existing ticket that he/she created.
        cancel a ticket that he or she created.

2. Users ( read employees/data entry types ) will be able to:
         create TT via web.
        Check ticket status
        Check notes on tickets
        add a note on tickets
        cancel a ticket ( Requires explanation ) { Configurable }

3. Techs will be able to :
        Clock in on a ticket indicating that it is being worked on.
        make notes on a ticket
        close a ticket ( notation required )
        FREEZE a ticket ( notation required and notification is sent to...
             user? admin?)
        Clock out on a ticket ( not closed but done for day ) notation of
             work performed required.

4: Admins can
        Do anything they want with a ticket.  HOWEVER every time a ticket is
modified in anyway, regardless of who is doing it... a new note will be
generated indicating time/date, person, reason, action.

5. TT status will be displayed for all customers on main screen.
6.  TT can be searched by,  note, customer,TT#, tech, date, status.
7.  TT are Real Time.
8.  TT # schema is configurable. either from a fixed set of numeric
increments, or by a fixed default schema ( like yearmonthday# ) or juilian
or..............

Configuration options.
 Allow Ticket to be touched without note? ( Y,n)
Require Customer close ticket? ( y, N )
Notify Customer of change in ticket status ( Y, n )
Allow Customers to create tickets? ( Y, n ) ( if N module is deactivated )
Allow Tickets to be Viewed without making notation? ( Y, n )
Print admin alert for tickets over x days ( Y, n )
Print all TT ( y, N )
Print New TT ( y, N )
Include billable field in ticket window ( Y, n )  This would allow the tech
to indicate if time was billable hours
Auto Create Invoice upon ticket closure ( Y, n ) This would batchout each
morning with the billing_engine routine.  SUGGESTION.  A test should be made
against ( billable hours credit ) so that if customer has a preset number of
incidents or billable hours at no charge, then the billing_engine takes this
into consideration when running the routine, and show's both the charge, and
the credit, and modify's both records in db.  This will be required once a
GL is tacked on.  This is VERY desirable NOW from a report stand point.  As
most admins are gonna want to know why someone is/is'nt getting charged.
Might even want to have the available billable time credit allowance
showing.  I.e. 4.5 hours billable time of credit left AFTER this deduction.

TODO:

* Testing for 2.0 release
* Keep the documentation engine going.

FUTURE:

Ryan McAdams :
I'd like to modify the current table for tickets and add in an update
column to keep track of updates so that when a customer or when a
support rep wants to make an addition... the previous information cannot
be edited by the user.  I have a nice hack done for the users to enter a
ticket already but not to update them.  The problem I have is that any
user can edit the whole ticket which kind of defeats the purpose of
tracking them dont you say?  Also I would like to see a bigger numbering
system than just '1' '2' '3' for the tickets.

* General Ledger stuff to satisfy the bean counters.

* Do something more with doc_gen.pl, its a great start.

* Update forms to look for GET/POST requests rather than checking
  for single variables.

* Check for SSL to enable/disable password viewing/access.

* Add a $msg field to DBreport to allow more messages to be printed.
  IE: After entering a resource, it allows you to go to more than
      one place.  For example: Admin or to enter another resource.
 
* Adding users: Usernames can be duplicated?  ANS: Depends.
  Option to force usernames to be lowercase.  Default: allow mixed case.
  Make UNIQUE in DB structure.

* Figure out a way to allow dynamic changes to database type, connection,
  database name.  A local database is still necessary for login info, etc.

* Update/merge data from remote databases.

* Allow Users or some other database to accept and define several
  different access types, define a string of 0 and 1s to allow access
  to various forms: Admin, Trouble Ticket, EditCustomer, Billing, etc.

* Further update DB API with a cleaner implementation: 
  PEAR::DB for PHP
  See: http://vulcanonet.com/soft/index.php?pack=pear_tut
  Author: Tomas V.V.Cox (cox@php.net)