-$Id: TODO,v 1.44 2000-06-15 14:45:38 ivan Exp $
+$Id: TODO,v 1.66 2001-07-30 07:13:34 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.
---
+> Does Freeside currently support notification to the customer that their
+> credit card on file is about to expire?
+> What about notification that their
+> credit card was declined after they sign up, say like in 5 months when it
+> fails?
+
+
+random templating thoughts:
+for starters, read the "Template Syntax" section of Text::Template
+that sums up the starting philosophy pretty well
+> Text::Template is unsuitable because it's backwards, but don't worry about
++that quite yet. everything in that section applies
+..
+then ttp://forum.swarthmore.edu/epigone/modperl/frahthonbror/19990525144012.8806.qmail@plover.com
+..
+then: given that as background, freside will use a simple template syntax designed
++to interact well with the webmonkey html editors, and will export to Mason
++and Apache::ASP for starters, and eventually any "right-side-out" "eval"
++templating system
+
+
+make svc_acct.import complain if you try to use a local file
+
+make the invoices configurable such that:
+> Also, Can you change FreeSide so that it says "GST" instead of TAX?
+
+"Andrew Wafula" <awafula2000@yahoo.co.uk>:
+> Following my recent questions on money_char, i would like to suggest that
+> money_char be used as well in cust_bill.cgi and cust_main.cgi so that the
+> charges are seen in whatever money_char is used in a particular country
+> instead of the default dollar currecny. This would make it such that the
+> system has one monetary unit in its entirety rather than only for the
+> invoicing part. I guess this would be something others would appreciate as
+> well.
+
+Things that would be nice but probably won't happen: testing with
+MySQL+Sleepycat, a fix for the long-RADIUS-attributes-with Pg problem,
+passive session monitoring with RADIUS (tailing a log file or monitoring a
+database, as opposed to using a RADIUS with proper callbacks).
+
+anything doing transactions in the web interface should likely move into *.pm.
+(transactions are here woo!)
+
+write some sample billing expressions with libcflow-perl :)
+
+(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.
+.
+How do you interpolate a value?
+mason: <% $value %>
+apache-asp(don't think there is a "with-escaping-HTML" way?): <%= $value %>
+.
+How do you interpolate a value without escaping HTML?
+mason: <% $value |n %>
+apache-asp??: <%= $value %>
+.
+How do you interpolate a (possibly non-stand-alone, non-interpolated)
+control structure? With an inital % - for example:
+.
+mason:
+ % foreach $value ( @values ) {
+ <OPTION><% $value %></OPTION>
+ % }
+apache-asp:
+ <% foreach $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
+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>
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?
projects / freeside.git / blobdiff