[Remember Mailing List] remember on Plone4?

0 views
Skip to first unread message

Mike Metcalfe

unread,
Sep 4, 2010, 3:25:00 AM9/4/10
to reme...@lists.coactivate.org
Hi,

I see that membrane now runs on Plone4 - anyone know if and when remember will?

Mike


--
Archive: http://www.coactivate.org/[…]/1283585101488
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.

ken manheimer

unread,
Sep 4, 2010, 12:31:19 PM9/4/10
to reme...@lists.coactivate.org
On Sat, Sep 4, 2010 at 3:25 AM, Mike Metcalfe <mi...@metcalfe.co.za> wrote:
Hi,

I see that membrane now runs on Plone4 - anyone know if and when remember will?

i'm working on this, in order to get a remember-based product i've developed working in plone 4.  what needs to be done, according to some guidance from wichert, is not very elaborate, but i'm encountering problems with the cataloging which i'm having trouble settling.  i'll report back when i know more.
 
Mike

--
ken manheimer
http://myriadicity.net

Mike Metcalfe

unread,
Sep 5, 2010, 4:27:25 AM9/5/10
to reme...@lists.coactivate.org
On 4 September 2010 18:31, ken manheimer <ken.ma...@gmail.com> wrote:
i'm working on this, in order to get a remember-based product i've developed working in plone 4.  what needs to be done, according to some guidance from wichert, is not very elaborate, but i'm encountering problems with the cataloging which i'm having trouble settling.  i'll report back when i know more.
Hi Ken,

If you put what you have in a branch and I can maybe help you out.  

Mike

ken manheimer

unread,
Sep 5, 2010, 12:37:13 PM9/5/10
to reme...@lists.coactivate.org
On Sun, Sep 5, 2010 at 4:27 AM, Mike Metcalfe <mi...@metcalfe.co.za> wrote:
On 4 September 2010 18:31, ken manheimer <ken.ma...@gmail.com> wrote:
i'm working on this, in order to get a remember-based product i've developed working in plone 4.  what needs to be done, according to some guidance from wichert, is not very elaborate, but i'm encountering problems with the cataloging which i'm having trouble settling.  i'll report back when i know more.
Hi Ken,

If you put what you have in a branch and I can maybe help you out.

terrific!  i was planning to create a branch soon, anyway, and will welcome the help.

i think i've tracked down the crux of the cataloging problem, though i'm still not clear how to approach rectifying it.  i'm going to try to write up the details and submit them today or first thing tomorrow.
 
Mike
--
ken
http://myriadicity.net

ken manheimer

unread,
Sep 5, 2010, 1:04:41 PM9/5/10
to reme...@lists.coactivate.org
On Sat, Sep 4, 2010 at 12:31 PM, ken manheimer <ken.ma...@gmail.com> wrote:
On Sat, Sep 4, 2010 at 3:25 AM, Mike Metcalfe <mi...@metcalfe.co.za> wrote:
Hi,

I see that membrane now runs on Plone4 - anyone know if and when remember will?

i'm working on this, in order to get a remember-based product i've developed working in plone 4.  what needs to be done, according to some guidance from wichert, is not very elaborate, but i'm encountering problems with the cataloging which i'm having trouble settling.  i'll report back when i know more.

i think i've isolated the crucial pieces of this cataloging problem, but i'm unclear how to approach rectifying it.

in membrane-based users, a special membrane-specific field, 'exact_getUserId', is used as the handle on the user, instead of getUserId (apparently to avoid getting users for which the specified id is just a prefix).  in the previous released pypi versions of membrane (1.1b5) and current remember (1.1b3), the indexing of the users included this field, with its value set the same as that of the getUserId field.  in the current trunk versions (as of yesterday) of membrane and remember, this field is not getting indexed, or getting indexed with an empty value, so PluggableAuthService._findUser() fails to find these users.

i've been unable to find exactly how membrane and remember are arranging to get the exact_getUserId field indexed with the right value, so i'm unable to say what the new versions are doing differently that fails to get this set.

through my explorations i do notice one big behavioral difference between the indexing of members in the old and new versions.  in the old version, the .indexObject() and .reindexObject() is being called on the member objects (though the invoked methods are actually supplied from somewhere in the base BaseContent class) to do the indexing, while  the methods are not being called in the new version.

it's possible - nay, likely - that there's something i missed in revising my remember trunk checkout to work with newest version of the membrane trunk.  i'm going to soon create a Products.remember branch with my revisions checked in, hopefully by tomorrow sometime, so others can look at what i'm doing.  i thought i'd immediately describe how i see the situation in case it rings any bells or provides enough info for others to investigate, in the meanwhile.
--
ken
http://myriadicity.net

ken manheimer

unread,
Sep 6, 2010, 11:47:34 AM9/6/10
to reme...@lists.coactivate.org
i've created a Products.remember branch for working on migrating remember to the new membrane version.  before getting to the details, i should note that the Products.remember trunk is already adapted to work well enough to expose the cataloging misbehavior i'm encountering.  (revision 124627 attributed to phlax on aug 31 took care of the interface changes, in a way backwards compatible with the old interfaces.)  so you can just use the Products.membrane and Product.remember trunks, and then try to create a remember member from portal_memberdata, to produce the problem - i get an AttributeError: 'NoneType' object has no attribute 'getProperty' (because the user is not found via retrieval on the missing exact_getUserId value).

that said, the branch provides a good place to share work on fixing the problem, as well as accommodating wicherts other changes.  it does have a start on adjusting to wichert's .authenticationCredentials() method changes, not yet tested.


one thing i would love at this point is confirmation (or refutation) of the problem i'm hitting.  if i'm correct, finding out the right way to get proper cataloging of the newly created member objects is the immediate goal.
Reply all
Reply to author
Forward
0 new messages