-$Id: TODO,v 1.46 2000-06-27 12:15:50 ivan Exp $
+$Id: TODO,v 1.57 2001-01-31 07:21:00 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.
---
+(future templating)
+.
+(at least) These questions need to be answered for Mason, Apache::ASP and
+eperl. If eperl becomes too much of a pain, I'm okay with forgetting
+about it - it's not well-maintained. The answers below are for Mason.
+.
+How do you interpolate a value? <% $value %>
+.
+How do you interpolate a value without escaping HTML? <% $value |n %>
+.
+How do you interpolate a (possibly non-stand-alone, non-interpolated)
+control structure? With an inital % - for example:
+.
+ % for each $value ( @values ) {
+ <OPTION><% $value %></OPTION>
+ % }
+.
+This is one of the things I worry that the webmonkey HTML editors will not
+like about Mason. That and the <%INIT> and <%PERL> tags.
+
+
+in the context of a state machine (& MySQL and Pg locking) for LDAP export:
+.
+Also note that Pg locks are for the duration of the transaction, so
+Freeside needs to start using transactions for this to happen.
+FS::UID::adminsuidsetup should explicitly set AutoCommit false and export
+some functions to begin and end transactions on $FS::UID::dbh. (Well,
+eventually FS::UID should be an overloaded subclass of a DBI handle, but
+we don't have to worry about that until perl threads + mod_perl + threaded
+Apache 2.0 is stable, i.e. quite some time).
+
+Postfix
+also supports virtual domains in a way that's somewhat similar (but not
+compatible with) the way sendmail does. In the postfix world, all virtual
+domain info is contained in one file (similar to the virtusertable), but
+is formatted as such:
+bar.com virtual
+foo@bar.com some@other.net
+quux@bar.com localuser1
+...
+and so on. After the file is generated, it gets compiled into a hash db
+using, "postmap /etc/postfix/virtual".
+
+
+steal all the play-nice-with-cache stuff back from RT
+
+Use this for email checking:
+libemail-valid-perl - Check validity of Internet email addresses
+.
+This module determines whether an email address is well-formed, and
+optionally, whether a mail host exists for the domain.
+
+
+wishlist from drenalin@ultimanet.com:
+* delete button for customers
+- 15th of the month billing
+- field for customer referrals (naming who it is) and automatically crediting
++that account
+- ability to edit referrals
+- catch expired credit cards and notify via email when they are expiring
+* show passwords
+- set default shell to /bin/false when adding ppp account
+- import list of POPs from Megapop (see www.ultimanet.com and click on locations
++from text in index page)
+
+
+wishlist wrt projects/consulting from jivko@ijs.com:
+>The other thing, which is the serious part, is the following: We do not
+>offer dial-up services and that part of the system does not have to work,
+>but we have many customer, for which we do both hosting and consulting work.
+.
+>The hosting can be handled by freeside fine, but in the little time I spent
+>on it I could not see how exactly to solve the consulting problem. What I
+>would love to see there is a way to create 'projects' for each customer and
+>ability to follow up on those (I mean to be able to add new comments,
+>descriptions, progress updates etc.). You already have the feature, which
+>allows multiple people to access the system with different access rights so
+>it should be possible to make it keep track of who and when updated given
+>'project' so we could have the developers access the database and update
+>the projects they are working on.
+.
+Hmm. Is this accurate: Each project is related to a single customer, and
+zero or more packages (billing items). Each project has a name, due date,
+and zero or more log entries consisting of date, user, and a text field
+(for "new comments, descriptions, progress updates etc." - would you like
+anything more specific?)
+
+In conjunction with that it looks like you need the ability to create
+"one-off" packages on the fly for arbitrary charges.
+
+> Additionally it would be nice to have a page, where all open projects can
+> be listed and not only that but be able list them by date too. (Say I want
+> to find out which projects are due today or two days from today, or which
+> projects are running late)
+.
+Browse/search project by date and customer.
+.
+> Finally it would be real nice if the billing script could add the cost for
+> all completed projects (or work done by the hour) to the monthly bill along
+> with the hosting information and using the description of the work from the
+> 'project' table.
+.
+Can you be more specific about your needs here?
+.
+> This is a lot of work, unless you disagree :-), and I would not expect you
+> to do all of it - we can work on it too - but I would hope for you to lead
+> the effort.
+.
+I'm trying to get a handle on specifically what you need.
+.
+> Oh, and there is one more thing, but that should be simple to do. I would
+> like to be able to give the customers access to selected information from
+> their account. I want them to be able to monitor the progress of their
+> projects and the status of their accounts.
+.
+Ok.
+.
+> Does all this make sense? It must be close to what you need at your office
+> though or at least I think so.
+.
+Yes, but we're small and have been tracking projects manually.
+.
+.
+>You may have this already .. what I have in mind is the following. Say you
+>have a customer for which you do hosting and some consulting (CGI, JAVA
+>etc) At the end of the month you need to bill the customer for the hosting,
+>35hours of Java programming and 10 hours of HTML authoring. The last two
+>are not because the project is over but because the work was done during
+>that month.
+>
+>So the way I see it, and it could be wrong, is that during the month the
+>people who work on particular project enter their comments and time spent
+>on the project. At the end of the month the billing script generates
+>invoices in which besides the hosting charges there are also charges for
+>work done during the period.
+>
+>Currently we do this in a very stupid way by maintaining a customer file,
+>in which a script saves things to be invoiced. At the end of the month a
+>script goes through these files and generates invoices with all items from
+>the files, which have not been flagged as 'paid'. The convenience of this
+>is that no one needs to worry about the invoices containing the items they
+>need to contain.
+
+
+
+first package select field in edit/cust_main.cgi isn't sticky on errors, yuck
+(also referral isn't sticky either? yuck)
+
+> 1. A Web Form to the user get his account added automatically . The
+> /etc/raddb/users and /etc/passwd would be updated automatically (these
+> file are on the same machine Freeside is). I guess the the Add
+> Customer
+> page with some customization could be the work.
+> 2. A Canceling Account Web Form available to user cancel his account
+> at
+> any time he wants.
+> 3. A Password Changing Web Form where the user could change your
+> password by sending your username, old and new password.
+> 4. Additional POP Accounts Creation where the user supply only his
+> main
+> username/password (probably provided from a PPP Account already
+> created)
+> and his POP username/password for this specific account.
+(actually need something more general i guess - probably need some way to say
+which accounts (svc_acct) can log in and make changes per customer (cust_main) )
+
+this is awfully vauge, perhaps email for more info? don't want to alientate
+someone with accounting experience, but i just don't have time right now.
+.
+Hi Ivan,
+.
+Thanks for the information. It took me a little while to figure it out, but I
++was
+able to create an invoice. As a lamer and an accountant, may I make a few
+suggestions?
+.
+On the Customer view page:
+1) Layout the information in the manner the invoicing process is conducted.
+ a) Customer information
+ b) Package Ordering
+ c) Add a "Create & Edit Invoice" section - this allows auditing of the
+invoice before it is processed.
+ d) then put the billing section to actually process the invoice
+ e) then put payment history information
+.
+Thanks,
+Mark Roberts <mroberts@iopenenterprises.com>
+
+
+new overdue code might be overzealous. test carefully.
+
+Port Freeside to use the modules that were abstracted from it:
+Net::SSH, Net::SCP, DBIx::DataSource and DBIx::DBSchema, at least.
+
+"first package" and email invoice (?) not sticky on errors in new/edit customer
+screen.
+
+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