-$Id: TODO,v 1.24 1999-02-10 08:27:55 ivan Exp $
+$Id: TODO,v 1.33 1999-07-08 11:40:40 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 --
-
-one-screen new customer entry
-
-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?
+---
+
+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!
+
+<http://www.math.fu-berlin.de/~leitner/mutt/faq.html> 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
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.
+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
+
+i10n: Apache::Language
-update web demo
+Apache::Session? Other useful Apache::* ?
--- release 1.2b1 ---
+email invoices are only sent for the BILL payby. If setup, should statements
+(since they're not invoices) be sent for COMP and CARD as well?
+
+$cgi->keywords is causing the (hard to trace) error:
+ Use of uninitialized value at (eval 5) line 5
edit/cust_main.cgi gives an uninformative error message:
> Can't call method "agentnum" without a package or object reference at
the customer lists. Put active, then suspended, then cancelled accounts.
Similar ordering on the package listing inside a single customer.
+false laziness: edit/cust_main.cgi got some parts copied from edit/svc_acct.cgi
+the web interface in general needs to be redone in a more abstract way.
+
false laziness: some of search/svc_acct_sm.cgi was copied to search/svc_domain.cgi. but web interface in general needs to be rewritten in a mucho cleaner way.
Portability: in FS::Record, $sth->execute does not return a number of rows for all DBD's. see man DBI
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!
...
(probably as part of some automated installation process?)
-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 (1.2)
-
This requires some serious magic in FS::Record:
ok, if date_type in fs-setup is to be something besides int,
now we need to create wrappers
projects / freeside.git / blobdiff