X-Git-Url: http://git.freeside.biz/gitweb/?p=freeside.git;a=blobdiff_plain;f=TODO;h=12bacc8c54ed21ae6e336892522849bdd018143e;hp=611f83ec507967743d9ad53d49fefd5eb300d2cd;hb=6cd87c0d3b5280446301c647fa5f1ec5a593fa3f;hpb=510d2f9647c0651a82760e456b46505e8050d6ed diff --git a/TODO b/TODO index 611f83ec5..12bacc8c5 100644 --- a/TODO +++ b/TODO @@ -1,24 +1,281 @@ -$Id: TODO,v 1.25 1999-02-23 08:09:18 ivan Exp $ +$Id: TODO,v 1.37 1999-08-03 07:43:33 ivan Exp $ If you are interested in helping with any of these, please join the mailing list (send a blank message to ivan-freeside-subscribe@sisd.com) to avoid duplication of effort. --- before 1.2b1 -- +--- + +take the GPL'ed whois proxy stuff at www.geektools.com and turn it into +intelligence for Net::Whois. + +A web version of the fs_passwd stuff would be nifty. + +If you have Cistron authenticating directly from MySQL, you can replicate +in real-time instead of exporting periodically. See +. + +these go in docs: +, and + + +and http://www.sisd.com/freeside/list-archive/msg00423.html -TEST email invoices +> > 5: Is there anyway to get freeside to send a sysadmin a warning when a +> > credit card has expired? +No, but there should be. -one-screen new customer entry +Put this in the doc (quoting Mark Wells ): +>Of course, thanks to the sheer coolness of SQL and MyODBC, you can do +>whatever reports you want in basically whatever application you want. +>There's no need for Freeside itself to do any reports at all. -clean up view/cust_pkg and view/svc_* yuck (popurl and visual)! - -Lay out the forms a bit better. - -libwww regression test - since it will create sample data, can also use this -for the web demo -make fs-setup option to add sample data so you can click on "New Customer" right away? so people understand what this stuff is? -(in sample data [ AND DOCUMENT! ] all svc_acct services should have a default - or fixed shell ) +middle names and titles + +On Wed, Jul 07, 1999 at 01:11:40PM -0400, Frank Nazario wrote: +> Playing and entering information to Freeside i encountered the following +> missing reports: +> +> View Customers by Agent +> +> View Pending Invoices +> + +grep 'uncomment this to encrypt password immediately' site_perl/svc_acct.pm +Not to say that it shouldn't be a configurable option. + +in site_perl/cust_main_invoice.pm (elsewhere?), error out if mydomain config file is gone +(at least until the idea of a default domain goes away) + +FS::Record::qsearch does an eval every loop iteration (which is itself not +guaranteed to work across all DBD's and should be fixed). This has got to be +slow. Fix it. (I think recent Perls might have a way to accept a variable +there, no eval needed?) + +Could you have added /bin/sync, /sbin/shutdown, and /bin/halt to the +`shells' configuration file before importing, and removed them afterwords? +(even better if svc_acct.import did that automatically - it could just +munge and restore @FS::svc_acct::shells... hmm.) + +> BTW, Ivan, I am trying to verify in an additional database table that a +> particular user doesn't exist. This database is used to store email aliases a$ +> additional POP boxes for our customers (kinda like AOL allows). I have toyed +> with the idea of just writing the aliases to an email only svc_acct that +> doesn't write to the password file, but that isn't really how I want to do it. + +Actually, I think that's a pretty good way to do it. Cerkit contributed +support a little while back for svc_acct.pm and svc_acct.export for +multiple export targets. It needs to be cleaned up and documented, which +I'll try to get to soon. For this to work correctly, the svc_acct_sm +table should go away, along with the concept of a "default" domain. + +default setting for new packages should allow all agents to purchase them... +with a config file for the old behaviour + +replace Term::Query with Quiz::Question? + +Check config file reading stuff from CPAN + +Authorizenet module from CPAN! + + has a good y2k complience +statement! + + I'm hoping Freeside can support arbitrailly complex pricing plans + because of a simple concept: all prices are perl expressions. So if + you use `19.95' for example, perl evalates that to be `19.95'. But if + you need to do a complex pricing scheme, you just need to write an + appropriate perl expression, which will most likely pull data from the + database to return pricing. Some things will already log to SQL; for + example most RADIUS servers can or have a patch available. Getting + Freeside to bill based on any sort of data then becomes a matter of + importing the data into the database. + + There are some issues involved with pro-rating, partial month charges, + that sort of thing. Expressions will need a standard way to have the + applicable time/data ranges passed to them. Also the expressions are + currently running under the Safe perl module, and the opmask might not + be right in all situations. I'll try to spend some time working on + this if you are using it. + +> 2. can customers view their bills on-line. + +Not yet; it needs to be proxied from Freeside to a customer web server in +a secure way using something not completely unlike the fs_passwd, +fs_passwdd, fs_passwd_server trio. + + +> Lastly, if someone over pays on an invoice, the credit part does not flow +> over to other invoices.. + +The total balance flows over correctly, but individual payments don't. +The code you're looking for is in FS::cust_pay::insert + +The question of what to do with overpayments that don't have another +invoice to flow into (yet.. or possibly not) is still an open one. The +legacy system Freeside replaced long ago had a separate place for this +(payments waiting for an invoice) for each customer, and it gave our +bookeeper fits. + + +option to relax username uniqueness in favor of username+domain or mail/shell +vs. radius to ease import for isp's with namespace problems or who buy others. + +do i have to store anything for radius realms besides regular radius attributes +(which are handled fine now)? + +warn or complain or something when invoice_from is empty (and we use it) + +Right now Freeside uses the `freq' field of a package definition as a +number of months. The specific section of code you're looking for is in +FS::cust_main::bill: + + #change this bit to use Date::Manip? + #$sdate=$cust_pkg->bill || time; + #$sdate=$cust_pkg->bill || $time; + $sdate = $cust_pkg->bill || $cust_pkg->setup || $time; + my ($sec,$min,$hour,$mday,$mon,$year) = + (localtime($sdate) )[0,1,2,3,4,5]; + $mon += $part_pkg->getfield('freq'); + until ( $mon < 12 ) { $mon -= 12; $year++; } + $cust_pkg->setfield('bill', + timelocal($sec,$min,$hour,$mday,$mon,$year)); + $cust_pkg_mod_flag = 1; + +..and when I went poking for this, looks like it tells us just what needs +to be done! Hehehe... + +Date::Manip can handle cool things like "+ 1 month" (actually the current +case of /^(\d+)$/ would have to be added as a special case of "+ $1 +month") and "+ 30 days" (what you need) and even "+ 5 business days" ! + + +On Wed, Apr 28, 1999 at 08:38:16PM +0000, Kristian Hoffmann wrote: +> I can't quite seem to figure out how this exporting works. From what I +> understand, when you run svc_acct.export, it rewrites the /etc/passwd, +> /etc/shadow, etc. files. Is this only for initial setups with the +> export hooks being in the pm's? + +You can use both, or just one method. The configuration files control +this. One of the things in the TODO is to take out the last few things +that aren't customizable wrt this and put them in config files. + +http://www.daemonnews.org/199905/user-mgmt.html + +Term::Query doesn't install out of the box from CPAN. Fix it (and get it +submitted upstream!), or remove requirement from bin/svc_acct.import and +bin/svc_acct_sm.import and take it out of the install instructions. + +use this cool link to explain the Freeside API +ftp://cpan.nas.nasa.gov/pub/perl/CPAN/doc/FMTEYEWTK/easy_objects.html + +Multiple tax rates by geographic region (county, state, and county) are +supported; just choose View/Edit tax rates from the main menu. + +Multiple tax rates by package are not (yet) supported. + +On Wed, Jul 07, 1999 at 12:13:36PM -0400, Shaun Batterton wrote: +> How would you handle something like multiple tax rates and multiple +> states? For example in Connecticut, they just changed computer and/or +> data processing services to 3% (whatever that is), and everything else +> is 6%. + + +> Second, when trying to add a new user I get two types of errors; first one +> is when I place an e-mail address and select the "submit," Freeside +> complains with "Error: Unknown local account (specified literally)" +. +You probably put a (local) email address in for email invoices. Freeside +stores these as references to the database records, so (for example) they +follow username changes. +. +I'm guessing you put in the email address that you were creating, and got +that error because it didn't exist yet. Sounds like a buglet to me. I'll +try to fix that soon; in the meantime you can add the invoicing email +address afterwords. + +Postgres `money' time sucks rocks anyway. I'll probably just require 6.5 +and use the numeric types, which *finally* work right. +On Sat, Apr 24, 1999 at 12:52:00PM -0700, Mr. Poet wrote: +> Software error: +> Error creating cust_bill record: ERROR: parser: +> attribute 'charged' is of type 'money' but expression +> is of type 'float8' You will need to rewrite or cast +> the expression ! Check updated but unbilled packages +> for customer1 +. +Postgres `money' time sucks rocks anyway. I'll probably just require 6.5 +and use the numeric types, which *finally* work right (well, according to +the web site, anyway). +. +In the mean-time, this could probably be fixed with the reverse of +the kludge in FS::Record::new. This removes `$' and `,' from money fields +coming out of the database. Something which fixed up the data so Postgres +was happy with it could go in FS::Record::_quote, for data going into the +database. + +our data display problem might be a Freeside problem wrt not using +Oracle-compatible DBI syntax (uses the return value from $sth->execute as +a number of rows). Fixing this is on the TODO. + +hooks for arbitrary commands out of configuration files +svc_acct.pm svc_acct_sm.pm etc. + +Add this to a FAQ, along with doing it for middle names: + + +> What I'm finding difficult is how to easily +> customize fields. For example, I am trying to add a "middle name" field +> to the Customer Edit, view, etc. If I'm going about it right, it appears +> I have to edit the cust_main.cgi under edit and edit/process and the +> site_perl/cust_main.pm, as well as other things. Perhaps you could shed +> some light on the best way of doing this. + +You have the basic idea. To implement that completely, I would: +- Add the new field to bin/fs-setup for new users +- Document the field in htdocs/docs/schema.html +- Document the change in a new file, htdocs/docs/upgrade4.html +* Run bin/dbdef-create +* Add the new field to edit/cust_main.cgi and edit/process/cust_main.cgi + +For bonus points, I'd grep around for the various bits which use "$first +$last" or "$last, $first" and replace them with a method call in cust_main.pm, + , like search/cust_main.cgi + +document security model: +Don't forget about Apache usernames - since, via the mapsecrets file, each +user can login to the SQL database with a different username and +password, you can utitilize the security model of the SQL database as +well. Also, each username here can point to a different configuration +directory where you could store user-specific configuration info. Then +you could link each username to one-to-many agents. +(The web demo works using a trivial version of this.) + +Yes, queue processing or the equivalent via checkpoint fields on various +talbes (which you pick up via a pretty simple SELECT) would be really +nice too. + +default (and ordering) state/county/country config file +expand the +cust_main_county table to provide a preferred ordering, so the most common +entries would be at the top of the selection box. automatically, based on +recent selections? + +hmm... maybe svc_acct__shell should check off the legal shells list if +applicable? yeah... cool. + +payinfo field should me much larger than 16 + + +[Mon Apr 12 20:31:21 1999] [error] [Mon Apr 12 20:31:21 1999] null: Error closing true: Broken pipe at /usr/local/lib/site_perl/FS/cust_main.pm line 615. + +javascript (yuck!) "are you sure?" confirmation on cancelations, etc. +(view/cust_pkg and view/svc_*) + +get rid of time2str("%D") which formats dates in a non-y2k-safe looking fashion +(all the actual date handling uses UNIX timestamps and is fine) + +uncomment expire in view/cust_pkg.cgi and find the expire cron from fsold (Test this) one-time/per-customer/? changes in rates and descriptions ('remembered @@ -29,13 +286,33 @@ associated with any agent types so it won't show up for other customers to buy. with custnum and partpkg (like type_pkgs) (what happens if you hit "custom pricing" but the pricing is already custom?) -update site_perl/table_template* (pry out of date) +Lay out any remaining ugly forms better. remove "records identical" warning? gets in the way of more important stuff. - -update web demo - --- release 1.2b1 --- +or fix logic which tries to update identical records?? +1.2 should be quiet enough that the error log is useful, hopefully. + +Postgres has a maximum column length of 31 characters (but see NAMEDATALEN in +postgres_ext.h). part_svc has columns like: svc_acct__radius_Attribute_flag +(22 characters!) It seems that stuff over the limit is silently ignored, +so we get 4 characters back. So, Radius_Attributes are max 13 characters with +stock Postgres. see rfc2138 for what's affected +What's a good fix? (besides recompiling postgres with NAMEDATALEN 64) +(mysql has a 64 character max column length. others?) + +[Mon Mar 29 06:57:56 1999] -e: Use of uninitialized value at /usr/lib/perl5/Date/Format.pm line 333. +(when sending mail in cust_main.pm::bill or svc_domain.pm) + +look at DBIx::Recordset! (and Tie::DBI, and...) + +undefined conf/lpr gives this uninfomative error: +[Fri Feb 26 16:42:36 1999] bill.cgi: Can't do bidirectional pipe at +/usr/lib/per +l5/site_perl/FS/cust_main.pm line 629. +[Fri Feb 26 16:42:38 1999] bill.cgi: Error closing : Broken pipe at +/usr/lib/per +l5/site_perl/FS/cust_main.pm line 631. +So give a meaningful error! password and slipip stuff in svc_acct.pm store need to be split into two fields or something, so the silliness in svc_acct.pm and svc_acct.export with looking at the data to decide what to do with it can be fixed @@ -72,7 +349,15 @@ Portability: in FS::Record, $sth->execute does not return a number of rows for a subroutine the where clause (eventually all SQL) as OO perhaps (has anyone done this?) -add a select method to ? +add a select method to FS::Record? + +one-time/per-customer/? changes in rates and descriptions ('remembered +invoices'): implement by creating a new package on the fly... but it isn't +associated with any agent types so it won't show up for other customers to buy. +(but also... make sure they go away when the customer does! - need this? : + one-off package edits! : need a cust_pkgs or cust_part_pkgs or something table, + with custnum and partpkg (like type_pkgs) +(what happens if you hit "custom pricing" but the pricing is already custom?) You can't delete the stuff under administration yet. Add this, _including_ making sure the thing you are deleting is not in use!