[freeside] I think I have this down....

[Ivan Kohler]

On Sun, Jul 18, 1999 at 11:38:46PM -0600, Tech Account wrote:
> > No, the instructions are skeletal at best.  Thanks; hopefully your outline
> > will be useful!
> 
> The thing about the instructions is that they only cover the physical
> software installation and not it's proper intent and use. If I get this
> thing working, and have a chance to test it, I will write some docs which
> will hopefully more clearly outline the way to use it correctly.

A couple other people have expressed interest in helping out with this so
you might want to coordinate with them on the list.

> > Err, no.  You should not have to edit Conf.pm
> 
> Well, to put it simply, the shells config file doesn't work at all on EITHER
> of my installations. They are both completely up to date with perl, apache,
> and freeside. I found this hard path for the config files which points to
> /config/directory
> Which isn't correct, since such a thing doesn't exist in any form on either
> box, nor is mentioned anywhere in the docs. In a desperate attempt to get
> the thing working, I changed this path to /usr/etc/freeside and things
> started to work better. That was the ONLY change that I made. However,
> Shells still didn't work, and since your error message doesn't tell me
> WHERE it is actually looking for the shells file, all I could do was
> change a simple line of code to kludge around it.
> No, of course this isn't the proper thing to do, but it actually works.

I was responding to that as part of an outline for installation
instructions.  You are of course free to do whatever you like to the
source.  :)

The config file locations in 1.2 confused a lot of people as things had to
be moved to support multiple configurations on a single box.  It wasn't
documented very well.

> 
> > Reporting them is still useful; it helps me make the error messages more
> > informative.  :)
> 
> Freeside suffers from but one problem, freeside reports the same error no matter
> WHAT is wrong. Making the error useful and easy to debug is matter of passing
> some of the variables in the program out to the real world, then people could
> tell you exactly whats wrong without any effort at all. Saying that someone
> has a bad shell for example, without telling them shell not found in:
> /usr/local/etc/freeside/shells isn't of much use, since they could have a 
> number of errors, a bad shell entry, a missing shells file, a bad shells
> path, or another problem.

Okay; this now returns the shell you typed, the full pathname of the file
Freeside looked in, and the shells that were in this file.

> Currently, if you have a package problem you can
> still add a user without a package, but if you go to order one, the order
> cancel screen can be blank, when it should report that no packages are
> currently configured for use. Specifically I hadn't linked any packages
> to agents!

Okay; it now does.

> Without docs to know that I had to have working agents to sell
> packages, and that if I added a package AFTER I had the agent around then
> I could not use the package, life is very difficult. With terribly generic
> error messages it's very hard to find such issues.

Let me know any other suggestions you have for better error messages.

> In any case, I'll try to document more fully such things.
> I'm still interested in a solution to add onetime charges to a given
> customer account...

You can use the `Customize Pricing' link on each package, on the main
customer view screen.

>Freeside appears to have most of the setup and
> config account work done, and much less flexibility in the billing side.

Well, all prices are Perl expressions, so we should be able to implement
any billing scheme.

-- 
Ivan Kohler <ivan at sisd.com> - finger for PGP key - <moc.dsis at navi> Relhok Navi
Open-source billing and administration for ISPs - http://www.sisd.com/freeside
20 4,16 * * * saytime # please don't be surprised if you find me dreaming too