But, he can see that in the SAME list. Having the same value in the
RadConfigs and RadATConfigs would not be evident if they were both
combined. What we will be adding to Emerald is the ability to pull the
default attributes from the RadATConfigs when you are editing the
specifics. Therefore one click would get you all the basics and you
can add the rest you want (or change/remove one of the defaults).
A better UI would solve the problem w/out making radical changes to
RadiusNT.
> Similarly, you could (by default) just let the user make the mistake and
> figure out what's wrong. You could then add the explicit alternatives to
> that of 1: Custom attributes override defaults; and 2) Defaults always
> prevail.
But WE have to listen to them complain when THEY make the mistake. Being
pro-active and trying to NOT let the customer hang themselves is
a better approach than "yep, you hung yourself and its your fault".
We are looking into the option of combing the two. For now, you could
easily update the RadGetConfigs stored procedure to do whatever you
want. Many people have done this and it works fine. The main reason
why we have been moving to stored procs is that that you can do whatever
you want to RadiusNT.
For example (and this is off the top of my head):
CREATE PROCEDURE RadGetConfigs @AccountID int AS
Select ra.RadAttributeID, Name, Data, Value, Type, rc.RadVendorID,
rc.RadVendorType, rc.RadCheck