-$Id: TODO,v 1.43 2000-05-13 21:57:56 ivan Exp $
+$Id: TODO,v 1.49 2000-08-09 11:30: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.
+If you are interested in helping with any of these, please join the
+*development* mailing list (send a blank message to
+ivan-freeside-devel-subscribe@sisd.com) to avoid duplication of effort.
---
+http://www.ipmeter.com/ integration would be useful
+
+http://tangram.sourceforge.net/
+Tie::DBI
+
+mmm, http://pootpoot.com/~dlowe/DBIx-Table/
+
+The cybercash links in htdocs/docs/config.html are b0rken.
+
+Yes. Which is what I've been trying to tell you. (destination user,
+destination domainname) would be represented by the svcnum of a record in
+svc_acct. (In retrospect, using the uid instead of the svcnum was a bad
+choice). (domuser, domain name) would be part of the svc_acct_sm record,
+as domuser and domsvc.
+.
+Upon further consideration, I'll probably eliminate the svc_acct_sm table
+completely, and just add a field for the svcnum of a domain and the svcnum
+of a destination mailbox to svc_acct (or perhaps a one-to-many
+relationship - multiple svcnum(s) for multiple destination mailboxes.
+hmm.)
+
+> > > > Longer-term, I need to do something about the length of the
+> > > > column names -
+> > > > The SQL1992 standard defines 18 character column names,
+> > > > which would be a
+> > > > reasonable goal.
+> > >
+> > > Maybe the thing to do would be to separate these out to separate
+> > > tables.
+> > > then we could simply use something like id, attrib_name,
+> > attrib_value
+> > > to
+> > > store all of the radius values.
+> >
+> > Hmm, no, that's not quite right. You don't want to store the actual
+> > strings in the records for each account. Probably need a table that
+> > corresponds to the RADIUS dictionary file, with a list of
+> > attributes and
+> > attribute id's, then reference the attribute by id and not name.
+> >
+> > The more difficult bit is handling the service definitions
+> > correctly -
+> > part_svc and it's effects.
+>
+> Yes that could be a bit tricky. Perhaps just one "radius" field in
+> part_svc that held a list of id's from the radius table that applied
+> that particular service?
+.
+No, that wouldn't let you set defaults or fixed values for each attribute,
+like part_svc currently does.
+
+
+
+hmm - if you delete an account in svc_acct somehow that a mail alias points to,
+svc_acct_sm.export will fail. make sure this can't be done using
+the web interface.
+
+Bug: during the linking process apparantly you can link too many services to
+a package. *sigh*
+
+zip code i18n is not very good :( but at least US, CA, HU, ?
+
+ut_phonen doesn't check data length. several
+orthogonal cleanup projects here. *sigh*
+
+update the cybercash links in config.html and in the homepage. add more explicit support for other payment types. etc.
+
+From "Tim Jung" <tjung@igateway.net>
+.
+Automatic CC Decline Notices via email
+Block Time billing for prepaid internet cards (400 hours or whatever block
+time of hours)
+Trouble Ticket System with simple search function for Knowledge Base feature
+Employee Timecards
+Credit Card System support for Red Hat's CCVS, and other Linux credit card
+programs
+Contact Manager/Lead Tracking
+Pre-Sale Quotes
+Cisco NetFlow Account for IP traffic billing
+VoIP and FoIP billing
+Roaming per minute billing based on Radius Proxy support or number they
+dialed into from Radius logs (800# etc)
+Support for OpenSRS Domain Registration
+Support for TUCOWS signup CDs
+
+
+dbdef-create for postgres
+
pro-rating, fiddling dates
It looks like svc_acct.import doesn't deal well with comments and
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.
+Oracle-compatible DBI syntax (fixed using the return value from $sth->execute
+as a number of rows - something else?).
hooks for arbitrary commands out of configuration files
svc_acct.pm svc_acct_sm.pm etc.
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 FS::Record?