Quanah Gibson-Mount wrote:
> --On Friday, November 02, 2007 12:15 PM -0400 Steve Linberg
> <[EMAIL PROTECTED]> wrote:
>
>> If there's a different way to approach this, I'm open to it, but so far
>> Frank's solution seems to be the cleanest, and I did produce a workable
>> test of this yesterday un
On Nov 2, 2007, at 11:15 AM, Steve Linberg wrote:
The other possibility I was considering was to have a new object
type for a "location role", with a location code, a role code, and
an employee ID to map back to the person record, but the fact that
each of these would have to have a uniq
--On Friday, November 02, 2007 12:15 PM -0400 Steve Linberg
<[EMAIL PROTECTED]> wrote:
If there's a different way to approach this, I'm open to it, but so far
Frank's solution seems to be the cleanest, and I did produce a workable
test of this yesterday under AD. It means I have to parse the va
Unless there's a different method that I'm missing, there would just
be too many groups to do this manageably with. I need to store pairs
of values from a list of about 20 from one group (locations), and 50
from another (roles), from which any combinations are possible, and
they have to be
Unless I'm missing something this is best solved using group membership.
Why are we forcing an attribute for this? The only reason I'd use the
attribute method is if I needed to support unknown values, which doesn't
seem to be the case here.
--
Puryear Information Technology, LLC
Baton Rouge, LA *
On Oct 31, 2007, at 6:53 PM, Frank Swasey wrote:
Steve,
You are absolutely correct that LDAP is very flat and goes out of
its way to tell you not to count on order of values.
That being said, what the developers have done when they cared
about order was to use a "list" type attribute. T
Active Directory does not natively offer this capability. You'll need to
define and handle the value structure yourself. Sorry L
Aside -- I initially thought you were referring to a form of linked-values
(which are supported) but, having re-read your requirements, this technology
doesn't appl
Steve,
You are absolutely correct that LDAP is very flat and goes out of its
way to tell you not to count on order of values.
That being said, what the developers have done when they cared about
order was to use a "list" type attribute. Take a look at the
postalAddress attribute which takes
