Ticket #11323 (closed PLIP: wontfix)
PlonePAS portrait plugin
Reported by: | naro | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.x |
Component: | General | Version: | |
Keywords: | pas portraits | Cc: |
Description (last modified by naro) (diff)
Proposer: Radim Novotny
Seconder: None as yet
Motivation
Member portraits are stored in portal_memberdata tool attribute as BTree object. It is not possible to use any other source of portraits currently. It would be nice to be able to share member portrait from LDAP (eg. jpegPhoto attribute) or use gravatar on-line service. My actual use-case is using portrait stored in SQL database.
Assumptions
Since PAS has plugins for authentication, users, groups and their properties, we need to be able to allow integrators use member portrait from shared user source as well.
Proposal & Implementation
- Create new plugin interface in PlonePAS (eg. IPortraitManagementPlugin) which defines three methods:
class IPortraitManagementPlugin(Interface): """ Portrait management plugin interface """ def getPortrait(member_id): """ return member_id's portrait if you can. Returns OFS.Image.Image instance or None """ def setPortrait(portrait, member_id): """ store portrait for particular member. portrait must be OFS.Image.Image instance """ def deletePortrait(member_id): """ remove member_id's portrait """
- implement plugin which either creates own storage for portraits or re-uses existing portal_memberdata.portraits storage
- add and implement IChangePortraitCapability interface, which allows plugin to specify if it is able to change or remove portrait (it is not possible to change/remove portrait on Gravatar, for example). This requires changes to plone.app.users - change portrait field has to be available for editing only if at least one portrait plugin supports this feature.
Deliverables
- Implementation of the plugin (done)
- changes to plone.app.users
- Unit tests (almost done)
- Documentation - part of plugin interface (done)
Risks
No risks for CMFPlone itself. Risks for third-party products are minimal and depends on the implementation of the plugin. If plugin re-uses portal_memberdata.portraits attribute, there are no risks, as far as I know. If plugin defines own portrait storage, it may cause problems for developers using portal_memberdata.portraits attribute directly. I don't know any third party product which would do such silly thing.
Default portrait plugin (part of this PLIP implementation) will work fine, but third party plugins may encounter problems with getPortrait return value. It should return OFS.Image.Image object, but it is not possible for gravatar service, which provides URL only. LDAPPortrait plugin knows raw image data (bytes string), but OFS.Image(jpegPhoto).absolute_url() won't return anything usable, probably. I implemented VirtualImage object for Gravatar plugin, which provides the most important attributes and methods only.
Security: Plone checks image validity during portrait upload in portal_membership.changeMemberPortrait. This plugin provides way, how to display possibly unsecure data from external source (in case of portrait source is not trusted and safe). It is responsibility of plugin author to check image data if they may come from unsecure source. The default plugin shipped with PlonePAS is secure in the same way as portal_memberdata.portraits storage.
Participants
Radim Novotny (naro)
Progress
There is a PlonePAS branch in collective SVN https://svn.plone.org/svn/collective/Products.PlonePAS/branches/portrait-plugin The branch implements:
- portraits plugin (uses new storage for portraits in 'portraits' attribute of the plugin). Plugin provides UI for migration from portal_memberdata.
- portraits-memberdata plugin (reuse memberdata.portraits storage attribute)
- portraits-gravatar (use Gravatar service)
memberdata and gravatar plugins are activated by default.
Questions
Use new storage for portraits or reuse portal_memberdata attribute?
How to handle non-ZODB portraits? (LDAP OFS.Image(string_data).absolute_url() or raw URL like gravatar)
Change History
comment:3 Changed 5 years ago by rossp
- Status changed from new to closed
- Resolution set to wontfix
PLEASE READ THIS AND RE-OPEN VALID PLIPS!
As we launch the new PLIP process we'd like to see which PLIPs:
- are still appropriate/needed
- still have owners/proposers/champions
- still have available implementers
If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.