# $Id$ PyKota - Print Quota for CUPS and LPRng (c) 2003, 2004, 2005 Jerome Alet This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. ============================================================ TODO, in no particular order : - Allow 'external' syntax for denyduplicates : in pykota.conf, if denyduplicates is set to : - yes ==> then duplicates are denied silently (with a log) - no (or unset) ==> then duplicates are allowed (without a log) - external(some_command_here) then the command is launched and its output is parsed, it may contain only ALLOW or DENY. And it should handle the dialog with the user, if any. - Add a new external hook to allow the overwriting of the job's ticket (mainly username and billing code) at startup time : 1 - hook is launched and can do whatever it wants, like asking the user for username+password or billing code 2 - hook prints any (or all) of : USER:some_username BILLING:some_billingcode DENY if hook doesn't print anything, job processed as usual. if DENY, job is rejected. 3 - if billing code or username is invalid, and if PyKota is configured to loop in this case, hook is launched again, otherwise job is rejected. 4 - if billing code and/or username is valid, the job's billing code and/or username are overwritten with these values, and PyKota processes the job as usual. - Add a table listing all the allowed billing codes. Unknown billing codes should produce an action which is configurable (reject the job being the default). The billing codes table will contains total pages and cost, and life time pages and cost => speedup for LDAP, and allows people to cleanup the printing history in any case. A tool to manage the table of billing codes must be written, but this will be easy. - Add a way to strip off "smbprn.????????" from the left of print jobs' titles (only appear when printing as raw from Winboxes it seems) - Pass-through mode for printers : history correctly filled (including job size) but no impact on user's page counter or account balance : this is meant to be a temporary situation for a printer to be in pass-through mode, for example during an exam where the faculty pays for the printouts and we don't want our users to complain about their credits being "eaten" for mandatory printouts. - Allow several levels of administrative priviledges by allowing files like ~pykota/pykotadmin.someusername.conf (readonly by user 'someusername'), and have the database server deal with the permissions : no need for additionnal code or data in PyKota's database ! - Add a "printing denied" indicator on user print quota entries, to temporarily forbid an user to print on a particular printer. - Maybe per user "denyduplicates" : my 5 years old daughter just prints again when the printer is off... - Now that the job size is ALWAYS precomputed, add a MaxJobSize attribute to users and groups (printers as well, maybe ?) to limit each job's size if needed. - Add precomputed job size (and price) to the history for controlling purpose. - Try to talk to education based distribution coordinators (SambaEdu, SkoleLinux, K12LTSP, ...) to see how to better integrate PyKota with these. - Allow soft and hard limits to be increased/decreased. - Add most configuration directives to the database itself, while still allowing to overwrite them with the configuration files at run time. - Ink accounting ala PrintBill. - Price and statistics per page format. - Add a description field to users/groups. - Allow the admin to choose an action to take when the database is unavailable (server is down or something like that), so introduce two directives : nodb: accept|reject|hold lognodb: /path/to/file/for/later/batch/update/of/database - CUPS accepts the "STATE: ..." message as backchannel data : use this to tell CUPS what action has been taken for current job. I did some testing but wasn't able to make it work... - Think about some possible client <=> PyKota dialog possibilities, like embedding a small web server in PyKota for example, or something like that. - Log something when --add is used with existing entries. Maybe add a new command line option to force/not force modification of existing entries. - Finish implementation of quota-then-balance and balance-then-quota. - Introduce the pkusers command. pkusers --nogroup pkusers --ingroups gr1,gr2,... --outgroups gr3,gr4,... - Allow the --ingroups command line option to repykota, to report only users members of the specified groups. - Documentation... - Learn more bits of PHP to help with phpPyKotaAdmin, which is a GREAT tool ! - Multidatabase support, e.g. store users in LDAP, quota related datas in PostgreSQL, history in text file, and so on... For 2.0, probably not before. ============================================================ Please e-mail bugs to: alet@librelogiciel.com (Jerome Alet)