Please login or register to participate.
mdebus Jan 07, 2010 11:41 PM
I can't set my profile picture in my own install (working fine here). I have a read-only LDAP directory, but adding 'occupation' works fine. Any hints for this?
Replies (12)
dhiraj Jan 12, 2010 11:32 PM
Hmm... does your AD actually *have* user images or URLs available? If so, then some custom mapping will have to be investigated for it.

If not, setting your user avatar in your site will work. If it's not appearing, it's almost guaranteedly a browser cache issue. Try refreshing with Ctrl + F5 or seeing it on a different browser.

The explanation for the "why/how" it works is this: Both the in-built and the LDAP user properties plugins are typically in use together. If the LDAP properties plugin has a mapping and is installed (as instructed in the how-to) at a higher priority than the in-built one, then it will win. If it doesn't have a mapping, then the property transparently falls through to the in-built property mapping plugin of source_users, which is basically the normal profile fields in So that's how it works. :)
mdebus Jan 13, 2010 02:20 PM
Sorry, I was imprecise: Neither the 'occupation' property nor the profile picture are mapped with my OpenLDAP - they are saved in Plone.

- I can set 'occupation' and it's correctly saved (in
- I can set the profile picture but it is not saved (I never see it).
dhiraj Jan 13, 2010 02:26 PM
Hmm... weird. Try doing a purge all caches on the OpenLDAP acl plugin after you set your avatar image?

I've always seen this get reported by users - and it's *always* worked out to a browser caching issue, each and every time. :)

Still, there's always the first time. Let's try to diagnose... you tried this with a non-AD user? Try setting the avatar image for your siteadmin user, see if that works?
mdebus Jan 13, 2010 04:52 PM
Ok, it works with the siteadmin user!

Then it has to do with my usernames. The LDAP usernames are in the format ''. They have to be like that because of the multi-tenancy.

I'm not able to manually create a user in this format. Strange.
dhiraj Jan 13, 2010 06:04 PM
Yep. That's it.

Hmm... that's one of the reasons that the default registration username regex doesn't allow @ and . in the username. The avatar image URL is basically <portal_url>/portal_memberdata/portraits/<username>

Looks like the browser (or more likely itself) is not liking either the @ or the . in the username part of the URL, in your case.

Thinking... is there anything in your LDAP schema that can be used without the part? Like in MS AD, instead of using email, we typically use sAMAccountName, that usually works out okay. Plus, if all users are on the same domain, then they're happier too, they get to type a shorter username as well.
mdebus Jan 13, 2010 06:38 PM
Hmm, unfortunately there's no way to use another username. The UIN is used across every other application in our net. :(

What is the problem with @-usernames? They seem to work just fine?
dhiraj Jan 13, 2010 07:37 PM
Yes, they do for the most part, that's the saddest bit of it all. Things like avatar images and user folder areas become a bit dicey. Apart from that, email based logins generally work fine.

Another potential thing to try out (*don't* try this in your production system!) is to see what happens when you put into the mix. This is another acl plugin, it basically accepts email as input and then does a lookup/substitute for username right at the top of the authentication chain. They've recently worked on LDAP support, I'd go have a look see into this if I were you, it may be exactly what you were looking for. It works by overriding the templates for login, register, etc. so you'll possibly have to rework those areas if you want to have a common look-and-feel (and it works).

Remember to carefully check things out, especially the SSO areas and all it's minute use-cases. If you do manage to get a working solution, do tell. :)
mdebus Jan 14, 2010 10:42 AM
Hmm, that seems problematic, as I actually want to use my installation as a production system. :)

What I'm trying to do now is uploading an avatar picture to LDAP (as 'jpegPhoto') and map this to a property. But to which one? In portal.memberdata is no property named 'portrait' or the like.

Do you have an idea?
dhiraj Jan 14, 2010 01:22 PM
Hmm... that's because the avatar image is acquired through a function, called getPortraitURL(userid). What you're attempting with the image as a field in the LDAP, will require more investigation, and will probably be problematic.

Unless you can figure out a way to map a direct HTTP URL to the jpegPhoto field in your LDAP, it's going to require the LDAP plugin in to download the image from the LDAP server as a blob. I don't even know if this is possible at all, as of now.
nicolad Oct 19, 2010 06:34 PM
I'm having issues updating my profile picture in also. Again, other fields in profile update work, just not the profile image.

This worked when it was tested with a small group of site 'admins.' Now it has been set up across the organisation - and no one can update the profile pictures. I'm wondering;
1. If this is due to username issue as described above ( New usernames include a "- "character)
2. If there has been any development in resolving this issue?

Any help and advice woud be much appreciated!
romasha Oct 20, 2010 11:14 AM
Hello Nicola,

Is your integrated with your Active Directory? If yes, then does your active directory have an avatar field? This could be a possible problem, where if your active directory doesn't have an avatar field and you have mapped all the profile fields, then none of your users will be able to add a profile picture, since the AD fileds over ride the profile fields once integrated.

brownfieldc Aug 25, 2011 05:49 PM
Has anyone figured out how to fix this problem? I have AD integrated with Cynin and it will not allow one person with a hyphen in her name to add a picture. Everyone else on campus can add a portrait.