Just a quick one… Is it possible with the new LDAP VCard provider to have the xml reference a database query… My reason for asking is I’'m not sure how to get Active Directory to store the Avatar… And I am fortunate enough to work for a company that would allow such customization adn would like to get it to work… I had noticed in the Jira atricle that there was talk of something like this but did not find anything in the docs…
So to summarize card I have Jive use the “Avatar” field of the vcard from it’'s database and the rest from LDAP…
I’‘ve actually be looking to do this (just haven’'t had time). I was planning to try and store the avatar in the LDAP data store (AD). I was going to see if I could hijack an existing field, or otherwise extend the schema and create my own field to store the avatar.
It would be cool to have that fix loaded into Jive for all ‘‘Octect’’ type fields. Is there any way to emit PHOTO/TYPE = ‘‘image/png’’ if LDAP photo exists, and PHOTO/TYPE=’‘image/jpeg’’ if LDAP jpegPhoto exists? or should I just create an LDAP string field for photoType?
Dont do a seperate field for type unless you can be 100% sure the field wont have multiple values (a pefectly valid thing to do). I would suggest doing like how the userPassword field works:
{mime/type}AABASE64IMAGEBBBB…
Also, be aware that the StringUtils base64 operations have some problems. Jivesoft guys seem to be moving towards using the implementation from here: http://iharder.sourceforge.net/base64/
Both LDAP’‘s photo and jpegPhoto fields allow mutliple values (of AD Type Octet String). You can’‘t use a combined format like that because, the vcard format, doesn’'t allow you to split it out as-far-as-I-know.
I’‘m tempted to use the extentionAttributeX fields from exchange, purely because they have a frontend in the normal Users and Computers frontend, but it’'s an ugly hack. I guess that ADSI Edit is the only way to go until I have found/built a frontend for uploading pics.
You would have to parse the field before using it. If no other applications are using that field, you are safe. Just grab the attribute, tokenize it into two pieces, and use the base64 for the image part. If other applications use the fields, then the only safe method is to only use a single image format type.
The problem with using a second field for attribute type is order is not known, as the ldap protocol does not support ordered retrieval of multi-valued attributes. If you could restrict the photo fields to a single attribute, then it would be fine.
You’‘re getting ahead of what I’'m trying to achieve here: Adding photos into vCard with zero codebase changes. When I said a second field, I meant one with a different name. That way I can always know that type is in field ‘‘xyz1’’ and the data is in field ‘‘xyz2’’.
Unfortunatly it seems that wildfire can’‘t read binary LDAP fields at the moment, and that if I want to get anything working - I’'ll have to store the base64 encoded data in a string field. MS AD with Exchange schema add a number of ‘‘use these for anything you want’’ fields. I was thinking of just piggy-backing on two of those.
It does mean that the industry standard LDAP ‘‘jepgPhoto’’ and ‘‘photo’’, ‘‘thumbnailPhoto’’ fields go unused