Quantcast

PlonePAS portrait handling

classic Classic list List threaded Threaded
11 messages Options
Jens W. klein-2 Jens W. klein-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Eric Steele
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PlonePAS portrait handling

On Wednesday, April 11, 2012 at 5:28 PM, Jens W. Klein wrote:
What do you think?
Yes, please! This has been on my todo list for a while. 

Do we need a PLIP for this?
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 Elizabeth Leddy-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Asko Soukka
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Jens W. klein-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Lennart Regebro-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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) David Glick (GW)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Radim Novotny-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Érico Andrei
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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,

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


------------------------------------------------------------------------------
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 Radim Novotny-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Jens W. klein-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
Loading...