Enhanced PEAR::Log project

Project consists of two parts: 1. Logger engine, which should extend PEAR::Log package (can use other PEAR packages if necessary) 2. Simple log browser with entry filtering ## Deliverables Enhanced PEAR::Log project Whole project consists of two parts: 1. Logger engine, which should extend PEAR::Log package (can use other PEAR packages if necessary) 2. Simple log browser with entry filtering Detailed specification of logger engine: **Additional log data** The PEAR::Log package is friendly and useful, but it lacks of some features required by us. Our website has multiple customers and every log entry must contain reference to particular customer. Second additional parameter is name of action. Log levels from PEAR::Log should be kept. Overall, new logger method should look like this: bool log($message, $customer, $action, $priority = PEAR_LOG_INFO) **IP logging** Furthermore caller IP address should be also stored. Log methods logger should always log messages to file and MySQL database simultaneously **Component initialization** PEAR::Log constructor and composite handlers can be kept or new constructor can be used. **Log database schema** Logs should be stored in database table with schema CREATE TABLE log_table ( id INT NOT NULL, logtime TIMESTAMP NOT NULL, customerid INT NOT NULL, action CHAR(5) NOT NULL, priority INT NOT NULL, ip CHAR(15) NOT NULL, message VARCHAR(200), PRIMARY KEY (id) ); **Text log format** Format of textlog should be as follows $logtime [$customerid $action $priority $ip] $message Detailed description of browser engine As you probably guessed, log viewer should allow easy log entry database browsing. At the top of the page there should be set of filters, below should be table with filtered entries. Filters: 1. Date from - by default current date minus one week 2. Date to - by default empty (no filtering) 3. Customer - by default ALL (no filtering), also id=0 as unknown, and all valid clients sorted alphabetically (data source described below) 4. Action - by default ALL (no filtering) 5. Priority - by default ALL (no filtering) 6. IP - by default empty (no filtering) 7. Message - by default empty (no filtering) Remarks: * Date widgets should be some kind of javascript pop-up calendar, with "empty" value allowed (no filtering). Hour and minute selection within pop-up widget is nice to have but it's not a must. * Customer filter should obtain customer list with SQL query "select id, name from customers order by name" * Action filter should obtain customer list with SQL query "select distinct action from log_table order by action" * Priority filter should contain set of inclusive priority levels, as LOG_EMERG, LOG_ALERT+higher, LOG_CRIT+higher, ..., LOG_INFO+higher, ALL - by default ALL (no filtering) * IP filter should be simple textfield passed to SQL to "ip like pattern" clause, but only if it's not empty (by default it's empty, no filtering) * Message filter - same as IP filter * Filter values should be saved between succesive page views, but saving values between sessions is not necessary * Filter engine should follow basic security constraints, i.e. by using prepared queries. However, passed variables (i.e. customer id) are not needed to be validated (in sample case against customer existence). * Don't put too much logic inside filter, i.e. if date from is later than date to, just pass it to query. * Graphics or fancy layout is not needed, but filter should be arranged in order to be user-friendly