We've just got out LDAP bridge up and running (with the help of Squiz). I would now like to create an Asset Listing that displays the LDAP Users alphabetically, regardless of which group they happen to be in. (Our Active Directory seems very vast and complicated with out-of-date department names and so on which are not important for this application)
I have an Asset Listing that will display normal User assets, and the sub types, but not LDAP Users or LDAP Backend Users.
Is there any fundamental problem with this?
Robert
P.S. Things look a little different 'round here - I like it!
Asset listings will display ldap users as long as the bridge is the root node and you Direct Link Only is on. Search page will never find LDAP users because the Matrix search does not index external data.
[quote]
Asset listings will display ldap users as long as the bridge is the root node and you Direct Link Only is on. Search page will never find LDAP users because the Matrix search does not index external data.
[/quote]
Whoa, so you couldn't run an employee directory based on the ldap users where you could search for a name or phone number etc?
[quote]
No, you can't search an LDAP directory from within Matrix.
[/quote]
Oh.
How have people been building intranet employee directories? I was going to base it all off the ldap because I don't want to have yet another password for people to remember in order to update their own profile.
We are also working on a solution for our migrated intranet. Once we get over the hurdle of not being able to setup a group for all staff read access to our site (squiz support gave up! but i blame our novell ldap directory).
My initial thought would be to hold all the staff details in a separate database table (probably mysql but postgres/oracle will do just as well). We have the staff member's login name and that should be enough to restrict queries to individuals when they login. Then its a matter of working out what fields are needed (location, phone, job title etc etc) and use remote/database module to query/update the database via a series of php files.
The real power in any staff directory (internal at least) is getting staff to update their own info. Im hoping to construct a useful organisational structure this way. I know, everyone hates updating info, but my approach will be to throw up a simple jquery dialog when they login and ask them for one item at a time (ie, one week if they don't have a phone number stored in the db they cant get past the dialog an into the intranet until they enter their phone number - over weeks/months its possible to build up a considerable amount of info this way).
Most of this solution will be outside the matrix application but using the data/remote module i'm confident we can make it transparent to the user.
[quote]
We are also working on a solution for our migrated intranet. Once we get over the hurdle of not being able to setup a group for all staff read access to our site (squiz support gave up! but i blame our novell ldap directory).
[/quote]
Oh dear, maybe I should be attacking this problem first!!
[quote]
My initial thought would be to hold all the staff details in a separate database table (probably mysql but postgres/oracle will do just as well). We have the staff member's login name and that should be enough to restrict queries to individuals when they login. Then its a matter of working out what fields are needed (location, phone, job title etc etc) and use remote/database module to query/update the database via a series of php files.
[/quote]
Sounds like that may work out well for you, but I don't know anything about databases. I thought the point of Matrix was simplifying things for non-developers.
[quote]
The real power in any staff directory (internal at least) is getting staff to update their own info. Im hoping to construct a useful organisational structure this way. I know, everyone hates updating info, but my approach will be to throw up a simple jquery dialog when they login and ask them for one item at a time (ie, one week if they don't have a phone number stored in the db they cant get past the dialog an into the intranet until they enter their phone number - over weeks/months its possible to build up a considerable amount of info this way).
[/quote]
That is a really good idea for getting them to update it!
[quote]
Asset listings will display ldap users as long as the bridge is the root node and you Direct Link Only is on. Search page will never find LDAP users because the Matrix search does not index external data.
[/quote]
Thanks Greg, but I can't get the Asset Listing to work.
Here's an example of out Active Directory's structure. Could this be preventing the assets from listing? I also tried setting the root node to an LDAP User Group within the Bridge, but it doesn't seem to work.
I have realised that my Asset Listing is "working" (I had presumed the blank page I was getting was a broswer time-out or something), but it appears it's just that the Keyword Replacement %asset_name_linked% wasnt working for LDAP Backend Users.
Of course this meant the Asset Listing was showing one blank entry for every user!
I'm still working out the rest though - can anyone shed some light on why I can set 'Direct Links Only' to 'No' in order that the Asset Listing will pick up users that live in sub-groups?
[quote]
I'm still working out the rest though - can anyone shed some light on why I can set 'Direct Links Only' to 'No' in order that the Asset Listing will pick up users that live in sub-groups?
[/quote]
Greg will have to confirm this, but I a pretty sure the reason is that LDAP users and groups are shadow assets, so listing them is not the same as listing normal assets, there are more restrictions to how it works.
[quote]
Greg will have to confirm this, but I a pretty sure the reason is that LDAP users and groups are shadow assets, so listing them is not the same as listing normal assets, there are more restrictions to how it works.
[/quote]
You are 100% correct. LDAP works per-level so it doesn't work with direct links only set to No.
Thanks for your help, I now have a working asset-listing.
I'm still ironing out a couple of bugs though so I'd appreciate any advice.
Firstly, the listing is painfully slow to come up - is there a caching option that might help to make it more responsive? Setting the number-of-results-per-page value doesn't seem to make a difference. (Viewing the LDAP Bridge in the back-end is a bit clunky, but much fater than the asset listing of the same info.) Directly accessing an arbitrary LDAP user via an AssetID is instant (both back-end and front-end).
Also the page reports several PHP errors "Invalid argument supplied for foreach()", but still shows the results.
I wondered if the errors might be caused where a user in out Active Directory doesn't have all the expected properties set.
