PlonePAS portrait handling
Locked
 
|
Jens W. klein-2 |
PlonePAS portrait handling
|
Products.PlonePAS handles every user data as some property on a
propertysheet, except the portrait photo. The portrait is stored at portal_memberdata - which is fine - but it is not exposed on the property sheet nor is it fetched as such. In my opinion its a must to handle the portrait photo the same way as all userdata. Exposing a photo from a different source - i.e. ldap, sql, remember - means now to patch PlonePAS - and this is ugly and error-prone. I'd like to change PlonePAS in a way to support this, but before I start I'd like to read your opinions. My proposed changes are: - add a new mutable propertysheet dealing with one property 'portrait' and use current portal_memberdata storage - change the methods used to fetch, store and delete the portrait on portal_membership and portal_memberdata to use the propertysheet. - add a traverser to the photo to support non-zodb data. - add tests Code using the current API would not be affected. Supporting a different data source for the photo would follow the usal PAS API. What do you think? Do we need a PLIP for this? regards Jens -- Klein & Partner KG, member of BlueDynamics Alliance ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
Eric Steele |
Re: PlonePAS portrait handling
|
|
On Wednesday, April 11, 2012 at 5:28 PM, Jens W. Klein wrote:
Yes, please! This has been on my todo list for a while.
I'm going back-and-forth on that one. Conservative me says 'yes/. Eric
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
Elizabeth Leddy-2 |
Re: PlonePAS portrait handling
|
|
In reply to this post by Jens W. klein-2
On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote: > Products.PlonePAS handles every user data as some property on a > propertysheet, except the portrait photo. > > The portrait is stored at portal_memberdata - which is fine - but it is > not exposed on the property sheet nor is it fetched as such. > > In my opinion its a must to handle the portrait photo the same way as > all userdata. Exposing a photo from a different source - i.e. ldap, sql, > remember - means now to patch PlonePAS - and this is ugly and error-prone. > > I'd like to change PlonePAS in a way to support this, but before I start > I'd like to read your opinions. > > My proposed changes are: > > - add a new mutable propertysheet dealing with one property 'portrait' > and use current portal_memberdata storage > > - change the methods used to fetch, store and delete the portrait on > portal_membership and portal_memberdata to use the propertysheet. > > - add a traverser to the photo to support non-zodb data. I would like this but, how would this work? How does the PAS story fit in here? > > - add tests > > Code using the current API would not be affected. Supporting a different > data source for the photo would follow the usal PAS API. > > What do you think? > > Do we need a PLIP for this? I'm all for this idea. I feel like a plip would just help with the review process more than anything. I wouldn't mind deprecating the old way either and making a plip would help this happen. I doubt the FWT would say no to this and I know I have a project that could use this functionality. Liz > > regards Jens > -- > Klein & Partner KG, member of BlueDynamics Alliance > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Plone-developers mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/plone-developers ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
Asko Soukka |
Re: PlonePAS portrait handling
|
|
In reply to this post by Jens W. klein-2
Jens W. Klein wrote:
> - add a new mutable propertysheet dealing with one property 'portrait' > and use current portal_memberdata storage Hi, "a new mutable propertysheet" reminds me of plone.app.memberschema: http://pypi.python.org/pypi/plone.app.memberschema I wonder, if it contains re-usable parts for this. I remember using it successfully to save portraits as plone.namedfile-images. Best Regards, Asko ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
|
Jens W. klein-2 |
PlonePAS portrait handling PLIP DRAFT (RFC) (was Re: PlonePAS portrait handling)
|
|
In reply to this post by Jens W. klein-2
Hi all,
thanks for the additional infos. I started to dig through the code and sketched a first implementation. Now its time for a plip, but i'd like to read your opinion before i add a ticket. Thanks for any comments. regards Jens ---- snip -------------------------------------------------------------- Handle Portraits using PAS and PropertySheets only =================================================== Proposer: Jens Klein Seconder: <anyone interested?> Motivation ---------- Plone handles user properties with PAS - except portraits. Now any pas-plugin providing portrait images need to monkey patch Products.PlonePAS. Prominent examples are Products.Remember or LDAP plugins. The root of the problem: Plone stores portraits in portal_memberdata and uses its API (and at some part portal_membership) everywhere portraits are involved. It is in no way connected to the usual MutablePropertySheet. Assumptions ----------- Also methods of MembershipTool and MemberdataTool starting with an underscore may be used outside of this class and can not be considered private. Proposal & Implementation ------------------------- Proposal: - in future all portrait images are read (and stored) on (from) PropertySheets. - images not located in ZODB are exposed using a named traverser. - new clean API is introduced (adapter or utility) handling all tasks around portrait images. - current API on MembershipTool and MemberdataTool is kept but code replaced to use the new API, deprecation makes sense (opinions?). - adapters on PropertySheet are responsible for sheet specific implemenations. - add migration functionality Implementation: The Products.PlonePAS.sheet.MutablePropertySheet gets a new default property ```portrait```. The name of the portrait property could be customizable (opinions? could cause confusion too) A new view ``portrait_image``` and a slighly modified subclass of OFS.Image (implementing a modified getPhysicalPath to point to the view) are provided to display images not located in the ZODB. View checks permission if needed. Or usage of plone.namedfile to display images not located in the ZODB. Permission needed (evaluation need to be done first). A new API is provided as a utility ```IPortraitUtility``` with methods ```get(userid)```, ```set(userid, image)``` and ```delete(userid)```. The utility is responsible to get the propertysheet providing the ```portrait``` property. It iterates over the available sheets and stops at the first sheet providing a readable (get) or writable (set, delete) property. If no writable property was found it returns the first mutable propertysheet. After a suitable propertysheet was found an IPortraitHandler is adapted to it. By default PlonePAS provide two types of IPortraitHandler-adpaters: One for propertysheets such as the default Products.PlonePAS.sheet.MutablePropertySheet enabled to store Persistent objects such as OFS.Images. And another one able to deal with propertysheets able to store binary data only, such as ldap or sql integrations. Plugins-authors may use this or built upon it. On MembershipTool the following methods are modified to use the new portrait API: - deletePersonalPortrait - changeMemberPortrait - getPersonalPortrait - default_portrait (property on module and class, slighly different!?) - getBadMembers (do we still need to keep this?) - manage_portrait_fix (property - dtml using getBadMembers) On MembershipTool the following methods are modified to use the new portrait API: - portraits (property, at the moment a BTreeFolder) - _getPortrait - _setPortrait - _deletePortrait - pruneMemberDataContents Risks ----- - Currently existing plugins may patch methods of MembershipTool and MemberdataTool. Such plugins probably break, but OTOH proposed change simplifies those plugins and is made for them. - if there is in a customized plone already a property ```portrait``` for whatever reason, it may result in data loss or weird behaviour. - on sites with lots of users there are lots of portraits to migrate. Participants ------------ Who is signed up to do the work? - Jens W. Klein Progress -------- draft being discussed ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
Lennart Regebro-2 |
Re: PlonePAS portrait handling PLIP DRAFT (RFC) (was Re: PlonePAS portrait handling)
|
|
On Fri, Apr 27, 2012 at 17:39, Jens W. Klein <[hidden email]> wrote:
> Hi all, > > thanks for the additional infos. I started to dig through the code and > sketched a first implementation. Now its time for a plip, but i'd like > to read your opinion before i add a ticket. Thanks for any comments. > > regards Jens > > ---- snip -------------------------------------------------------------- > > > Handle Portraits using PAS and PropertySheets only > =================================================== > > Proposer: Jens Klein > Seconder: <anyone interested?> > > Motivation > ---------- > > Plone handles user properties with PAS - except portraits. Now any > pas-plugin providing portrait images need to monkey patch > Products.PlonePAS. Prominent examples are Products.Remember or LDAP > plugins. > > The root of the problem: Plone stores portraits in portal_memberdata and > uses its API (and at some part portal_membership) everywhere portraits > are involved. It is in no way connected to the usual MutablePropertySheet. > > Assumptions > ----------- > > Also methods of MembershipTool and MemberdataTool starting with an > underscore may be used outside of this class and can not be considered > private. > > > Proposal & Implementation > ------------------------- > > Proposal: > > - in future all portrait images are read (and stored) on (from) > PropertySheets. > - images not located in ZODB are exposed using a named traverser. > - new clean API is introduced (adapter or utility) handling all tasks > around portrait images. > - current API on MembershipTool and MemberdataTool is kept but code > replaced to use the new API, deprecation makes sense (opinions?). > - adapters on PropertySheet are responsible for sheet specific > implemenations. > - add migration functionality > > > Implementation: > > The Products.PlonePAS.sheet.MutablePropertySheet gets a new default > property ```portrait```. The name of the portrait property could be > customizable (opinions? could cause confusion too) > > A new view ``portrait_image``` and a slighly modified subclass of > OFS.Image (implementing a modified getPhysicalPath to point to the view) > are provided to display images not located in the ZODB. View checks > permission if needed. Or usage of plone.namedfile to display images not > located in the ZODB. Permission needed (evaluation need to be done first). > > A new API is provided as a utility ```IPortraitUtility``` with methods > ```get(userid)```, ```set(userid, image)``` and ```delete(userid)```. > The utility is responsible to get the propertysheet providing the > ```portrait``` property. It iterates over the available sheets and stops > at the first sheet providing a readable (get) or writable (set, delete) > property. If no writable property was found it returns the first mutable > propertysheet. After a suitable propertysheet was found an > IPortraitHandler is adapted to it. By default PlonePAS provide two types > of IPortraitHandler-adpaters: One for propertysheets such as the default > Products.PlonePAS.sheet.MutablePropertySheet enabled to store Persistent > objects such as OFS.Images. And another one able to deal with > propertysheets able to store binary data only, such as ldap or sql > integrations. Plugins-authors may use this or built upon it. > > On MembershipTool the following methods are modified to use the new > portrait API: > > - deletePersonalPortrait > - changeMemberPortrait > - getPersonalPortrait > - default_portrait (property on module and class, slighly different!?) > - getBadMembers (do we still need to keep this?) > - manage_portrait_fix (property - dtml using getBadMembers) > > On MembershipTool the following methods are modified to use the new > portrait API: > > - portraits (property, at the moment a BTreeFolder) > - _getPortrait > - _setPortrait > - _deletePortrait > - pruneMemberDataContents > > > Risks > ----- > > - Currently existing plugins may patch methods of MembershipTool and > MemberdataTool. Such plugins probably break, but OTOH proposed change > simplifies those plugins and is made for them. > > - if there is in a customized plone already a property ```portrait``` > for whatever reason, it may result in data loss or weird behaviour. > > - on sites with lots of users there are lots of portraits to migrate. > > > > Participants > ------------ > > Who is signed up to do the work? > > - Jens W. Klein > > Progress > -------- > > draft being discussed > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Plone-developers mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/plone-developers Sounds reasonable to me. //Lennart ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
David Glick (GW) |
Re: PlonePAS portrait handling PLIP DRAFT (RFC) (was Re: PlonePAS portrait handling)
|
|
In reply to this post by Jens W. klein-2
On 4/27/12 8:39 AM, Jens W. Klein wrote:
> Hi all, > > thanks for the additional infos. I started to dig through the code and > sketched a first implementation. Now its time for a plip, but i'd like > to read your opinion before i add a ticket. Thanks for any comments. Overall this sounds like a good direction to me. > A new view ``portrait_image``` and a slighly modified subclass of > OFS.Image (implementing a modified getPhysicalPath to point to the view) > are provided to display images not located in the ZODB. View checks > permission if needed. Or usage of plone.namedfile to display images not > located in the ZODB. Permission needed (evaluation need to be done first). This is the section I have the most questions about. Would the portrait_image view only provide access to the authenticated user's portrait, or to the portraits of other users too? It would be nice if we could support image scaling via an @@images adapter like plone.app.imaging does for Archetypes image fields and plone.namedfile NamedImages. Can we use blobs by default instead of OFS.Image? plone.namedfile is available as part of the core KGS as of Plone 4.3, if that helps. David ---------- David Glick Web Developer [hidden email] 206.286.1235x32 GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire on this community-wide day of giving. http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
Radim Novotny-2 |
Re: PlonePAS portrait handling
|
|
In reply to this post by Elizabeth Leddy-2
Hi all,
I've started Plone Portraits PAS plugin work a long time ago and also created a PLIP proposal (which has been closed because of PLIP policy change - https://dev.plone.org/ticket/11323 ) It is slightly different what Jens is suggesting. It defines new PAS plugin and allows to use eg. Gravatar or LDAP. The plugin is backward comaptible with the current implementation, because implements ZODBPortraitProvider plugin. The current implementation is available on https://github.com/naro/Products.PlonePAS The example plugins are Memberdata https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portraits.py or Gravatar https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/gravatar_portrait.py or read-only LDAP https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portrait_ldap_demo.py -- Radim > > On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote: > >> Products.PlonePAS handles every user data as some property on a >> propertysheet, except the portrait photo. >> >> The portrait is stored at portal_memberdata - which is fine - but it is >> not exposed on the property sheet nor is it fetched as such. >> >> In my opinion its a must to handle the portrait photo the same way as >> all userdata. Exposing a photo from a different source - i.e. ldap, sql, >> remember - means now to patch PlonePAS - and this is ugly and error-prone. >> >> I'd like to change PlonePAS in a way to support this, but before I start >> I'd like to read your opinions. >> >> My proposed changes are: >> >> - add a new mutable propertysheet dealing with one property 'portrait' >> and use current portal_memberdata storage >> >> - change the methods used to fetch, store and delete the portrait on >> portal_membership and portal_memberdata to use the propertysheet. >> >> - add a traverser to the photo to support non-zodb data. > > I would like this but, how would this work? How does the PAS story fit in here? > >> >> - add tests >> >> Code using the current API would not be affected. Supporting a different >> data source for the photo would follow the usal PAS API. >> >> What do you think? >> >> Do we need a PLIP for this? > > I'm all for this idea. I feel like a plip would just help with the review process more than anything. I wouldn't mind deprecating the old way either and making a plip would help this happen. I doubt the FWT would say no to this and I know I have a project that could use this functionality. > > Liz > >> >> regards Jens >> -- >> Klein& Partner KG, member of BlueDynamics Alliance >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Plone-developers mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/plone-developers > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
Érico Andrei |
Re: PlonePAS portrait handling
|
|
Radim,
Is it possible to have the plugin on its own package so we can add to existing Plone sites? Best,
Érico Andrei
On Wed, May 2, 2012 at 12:32 PM, Radim Novotny <[hidden email]> wrote: Hi all, ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
|
Radim Novotny-2 |
Re: PlonePAS portrait handling
|
|
Hi,
unfortunately, it is not currently possible, because the current PlonePAS implementation of portrait handling is in Membership/MemberData tools and uses the member data property. The only option would be to patch Memberdata/Membership implementations. To make this new version work in Plone you would also need slightly modified version of plone.app.users/personalpreferences.py (the old copy is inside the package). I think you can use this version of PlonePAS if you need custom portraits implementation and you can make some fixes to plone.app.users yourself. I don't think this can be easily extracted to separate package (only if you like to create a bunch of monkey patches). Radim > Radim, > > Is it possible to have the plugin on its own package so we can add > to existing Plone sites? > > > Best, > Érico Andrei > > > On Wed, May 2, 2012 at 12:32 PM, Radim Novotny <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi all, > > I've started Plone Portraits PAS plugin work a long time ago and also > created a PLIP proposal (which has been closed because of PLIP policy > change - https://dev.plone.org/ticket/11323 ) It is slightly different > what Jens is suggesting. It defines new PAS plugin and allows to use eg. > Gravatar or LDAP. The plugin is backward comaptible with the current > implementation, because implements ZODBPortraitProvider plugin. > > The current implementation is available on > https://github.com/naro/Products.PlonePAS The example plugins are > Memberdata > https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portraits.py > or Gravatar > https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/gravatar_portrait.py > or read-only LDAP > https://github.com/naro/Products.PlonePAS/blob/master/Products/PlonePAS/plugins/portrait_ldap_demo.py > > -- > Radim > > > > > > > > > On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote: > > > >> Products.PlonePAS handles every user data as some property on a > >> propertysheet, except the portrait photo. > >> > >> The portrait is stored at portal_memberdata - which is fine - > but it is > >> not exposed on the property sheet nor is it fetched as such. > >> > >> In my opinion its a must to handle the portrait photo the same > way as > >> all userdata. Exposing a photo from a different source - i.e. > ldap, sql, > >> remember - means now to patch PlonePAS - and this is ugly and > error-prone. > >> > >> I'd like to change PlonePAS in a way to support this, but before > I start > >> I'd like to read your opinions. > >> > >> My proposed changes are: > >> > >> - add a new mutable propertysheet dealing with one property > 'portrait' > >> and use current portal_memberdata storage > >> > >> - change the methods used to fetch, store and delete the portrait on > >> portal_membership and portal_memberdata to use the propertysheet. > >> > >> - add a traverser to the photo to support non-zodb data. > > > > I would like this but, how would this work? How does the PAS > story fit in here? > > > >> > >> - add tests > >> > >> Code using the current API would not be affected. Supporting a > different > >> data source for the photo would follow the usal PAS API. > >> > >> What do you think? > >> > >> Do we need a PLIP for this? > > > > I'm all for this idea. I feel like a plip would just help with > the review process more than anything. I wouldn't mind deprecating > the old way either and making a plip would help this happen. I doubt > the FWT would say no to this and I know I have a project that could > use this functionality. > > > > Liz > > > >> > >> regards Jens > >> -- > >> Klein& Partner KG, member of BlueDynamics Alliance > >> > >> > >> > ------------------------------------------------------------------------------ > >> Better than sec? Nothing is better than sec when it comes to > >> monitoring Big Data applications. Try Boundary one-second > >> resolution app monitoring today. Free. > >> http://p.sf.net/sfu/Boundary-dev2dev > >> _______________________________________________ > >> Plone-developers mailing list > >> > [hidden email] > <mailto:[hidden email]> > >> https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Plone-developers mailing list > [hidden email] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Plone-developers mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/plone-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
|
|
Jens W. klein-2 |
New Plip 12870 Handle Portraits using PAS and PropertySheets only (was Re: PlonePAS portrait handling PLIP DRAFT (RFC) )
|
|
In reply to this post by Jens W. klein-2
Hi again,
I pliped this now and did some changes again, thanx for all the input, it helped me a lot! https://dev.plone.org/ticket/12870 Comments are again very welcome! Jens On 2012-04-27 17:39, Jens W. Klein wrote: > Hi all, > > thanks for the additional infos. I started to dig through the code and > sketched a first implementation. Now its time for a plip, but i'd like > to read your opinion before i add a ticket. Thanks for any comments. > > regards Jens > > ---- snip -------------------------------------------------------------- > > > Handle Portraits using PAS and PropertySheets only > =================================================== > > Proposer: Jens Klein > Seconder:<anyone interested?> > > Motivation > ---------- > > Plone handles user properties with PAS - except portraits. Now any > pas-plugin providing portrait images need to monkey patch > Products.PlonePAS. Prominent examples are Products.Remember or LDAP > plugins. > > The root of the problem: Plone stores portraits in portal_memberdata and > uses its API (and at some part portal_membership) everywhere portraits > are involved. It is in no way connected to the usual MutablePropertySheet. > > Assumptions > ----------- > > Also methods of MembershipTool and MemberdataTool starting with an > underscore may be used outside of this class and can not be considered > private. > > > Proposal& Implementation > ------------------------- > > Proposal: > > - in future all portrait images are read (and stored) on (from) > PropertySheets. > - images not located in ZODB are exposed using a named traverser. > - new clean API is introduced (adapter or utility) handling all tasks > around portrait images. > - current API on MembershipTool and MemberdataTool is kept but code > replaced to use the new API, deprecation makes sense (opinions?). > - adapters on PropertySheet are responsible for sheet specific > implemenations. > - add migration functionality > > > Implementation: > > The Products.PlonePAS.sheet.MutablePropertySheet gets a new default > property ```portrait```. The name of the portrait property could be > customizable (opinions? could cause confusion too) > > A new view ``portrait_image``` and a slighly modified subclass of > OFS.Image (implementing a modified getPhysicalPath to point to the view) > are provided to display images not located in the ZODB. View checks > permission if needed. Or usage of plone.namedfile to display images not > located in the ZODB. Permission needed (evaluation need to be done first). > > A new API is provided as a utility ```IPortraitUtility``` with methods > ```get(userid)```, ```set(userid, image)``` and ```delete(userid)```. > The utility is responsible to get the propertysheet providing the > ```portrait``` property. It iterates over the available sheets and stops > at the first sheet providing a readable (get) or writable (set, delete) > property. If no writable property was found it returns the first mutable > propertysheet. After a suitable propertysheet was found an > IPortraitHandler is adapted to it. By default PlonePAS provide two types > of IPortraitHandler-adpaters: One for propertysheets such as the default > Products.PlonePAS.sheet.MutablePropertySheet enabled to store Persistent > objects such as OFS.Images. And another one able to deal with > propertysheets able to store binary data only, such as ldap or sql > integrations. Plugins-authors may use this or built upon it. > > On MembershipTool the following methods are modified to use the new > portrait API: > > - deletePersonalPortrait > - changeMemberPortrait > - getPersonalPortrait > - default_portrait (property on module and class, slighly different!?) > - getBadMembers (do we still need to keep this?) > - manage_portrait_fix (property - dtml using getBadMembers) > > On MembershipTool the following methods are modified to use the new > portrait API: > > - portraits (property, at the moment a BTreeFolder) > - _getPortrait > - _setPortrait > - _deletePortrait > - pruneMemberDataContents > > > Risks > ----- > > - Currently existing plugins may patch methods of MembershipTool and > MemberdataTool. Such plugins probably break, but OTOH proposed change > simplifies those plugins and is made for them. > > - if there is in a customized plone already a property ```portrait``` > for whatever reason, it may result in data loss or weird behaviour. > > - on sites with lots of users there are lots of portraits to migrate. > > > > Participants > ------------ > > Who is signed up to do the work? > > - Jens W. Klein > > Progress > -------- > > draft being discussed > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- Klein & Partner KG, member of BlueDynamics Alliance ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
«
Return to Core Developers
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |