[freeside] Radius Check Items

[ivan]

On Fri, Jul 07, 2000 at 08:44:11PM -0500, Kenny Elliott wrote:
> > > Any prefix would work really. I would suggest though that
> > the radius_
> > > fields be renamed to follow along with the new fields. rr_ and rc_
> > > perhaps
> > > or maybe radrep_ and radchk_.
> >
> > Ok, I needed this for a current customer so I went ahead
> > and added it.
> > The new RADIUS check fields are prefixed with `rc_' but I
> > left the reply
> > fields as `radius_' for now (you're welcome to submit a
> > patch to change
> > them too).
> 
> Yeah I noticed. Thanks!
> 
> I'll gladly submit a patch as soon as I can get my freeside and the
> cvs into some sort of alignment :)
> 
> > > > > Are there
> > > > > any reasons  you would not like to do it this way and
> > > > perhaps do it
> > > > > another.
> > > >
> > > > 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.

-- 
meow
_ivan