[Remember Mailing List] Re: remember on Plone4?
2 views
Skip to first unread message
Felipe Roquette
Oct 9, 2010, 9:51:59 AM10/9/10
to remember
hello!
ken, I got your brunch, installed the latest membrane, installed your remember, installed a basic product to use both and got the same error when I tried to create a new custom member:
AttributeError: 'NoneType' object has no attribute 'getProperty'
I need to get this working, so I am going to see what I can fix.
ken, I got your brunch, installed the latest membrane, installed your remember, installed a basic product to use both and got the same error when I tried to create a new custom member:
AttributeError: 'NoneType' object has no attribute 'getProperty'
I need to get this working, so I am going to see what I can fix.
|
--
Archive: http://www.coactivate.org/[…]/1286632564517
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.
ken manheimer
Oct 9, 2010, 11:09:37 AM10/9/10
to reme...@lists.coactivate.org, fel...@krei.com.br
On Sat, Oct 9, 2010 at 9:51 AM, Felipe Roquette <fel...@krei.com.br> wrote:
hello!
ken, I got your brunch, installed the latest membrane, installed your remember, installed a basic product to use both and got the same error when I tried to create a new custom member:
AttributeError: 'NoneType' object has no attribute 'getProperty'
I need to get this working, so I am going to see what I can fix.
hi, felipe!
first of all, you're the first person who has returned a report, confirming the behavior i'm seeing - thanks for the valuable info.
secondly, i've resumed working on this and the problem is clearly connected with the membrane tool's catalog of the member objects. in both the 2.0 membrane version and the prior one the tool's catalog is configured (Products/membrane/profiles/default/membrane_tool.xml) with FieldIndexes that duplicate getUserid, getUserName, and get getGroupId to be used for exact lookups on those values:
<index name="exact_getUserName" meta_type="FieldIndex"><indexed_attr value="getUserName"/></index><index name="getUserId" meta_type="ZCTextIndex"><indexed_attr value="getUserId"/><extra name="index_type" value="Cosine Measure"/><extra name="lexicon_id" value="lexicon"/></index><index name="exact_getGroupId" meta_type="FieldIndex"><indexed_attr value="getGroupId"/></index>
i haven't yet tracked down why this is happening in the older versions but not in the newer ones. the membrane tool configuration hasn't changed at all between versions, and the member objects are showing up in the membrane tool's catalog, they're just missing a value for that particular field. (the lack of that field is causing member workflow transitions' retrieval of the member, in doActionFor, to come up empty, seeking a member property on an empty - None - retrieval, hence the traceback.)
my next task is to identify where the catalog implements the FieldIndex "indexed_attr value=", so i could try to determine what's missing or disrupting the process. any ideas about what could be causing this problem, and/or other ways to zero in on it, are welcome.
as a bonus for those of you who have read this far, you actually can run remember in plone 4 if you checkout specific versions of remember: 124585 and membrane: 123246 . i've been running with those the whole time, and switching between them and trunk checkouts to try to track down the solution to this problem.
(incidentally, you can elicit this problem with the remember unit tests. i had to explicitly include collective.testcaselayer in my buildout - the inclusion in remembers egg info "requires.txt" doesn't cause it to be included, for me. once i did that, and fixed the call to send mail in the tests, they ran for me in the working versions and fail in setup, with that traceback, with the new versions.)
i hope this helps - and hope those of you looking to go forward with remember don't just settle for the above specific versions, and wait for the rest of us to solve the problems. we need to get unstuck, so it can develop further.
Felipe Roquette
Oct 9, 2010, 1:04:59 PM10/9/10
to remember
Em Sáb, 2010-10-09 às 11:09 -0400, ken manheimer escreveu:
secondly, i've resumed working on this and the problem is clearly connected with the membrane tool's catalog of the member objects. in both the 2.0 membrane version and the prior one the tool's catalog is configured (Products/membrane/profiles/default/membrane_tool.xml) with FieldIndexes that duplicate getUserid, getUserName, and get getGroupId to be used for exact lookups on those values:
<index name="exact_getUserName" meta_type="FieldIndex">the problem is that running with the latest versions of membrane and remember the exact_getUserId is not getting into the membrane tool's member catalog entries, yet the exact_getUserName value is.
<indexed_attr value="getUserName"/>
</index>
<index name="getUserId" meta_type="ZCTextIndex">
<indexed_attr value="getUserId"/>
<extra name="index_type" value="Cosine Measure"/>
<extra name="lexicon_id" value="lexicon"/>
</index>
<index name="exact_getGroupId" meta_type="FieldIndex">
<indexed_attr value="getGroupId"/>
</index>
Yea, i saw that happening...
I don't know how you saw that, but to see in the ZMI I commit the transaction on the middle of a pdb:
(Pdb) import transaction transaction.commit()
I think that it is not very good approach :) .
How membrane interacts with portal_membership? How it is suppose to tell to portal_membership that it needs to use the membrane_tool data?
Where membrane update its catalog when creating a new user?
I don't know how you saw that, but to see in the ZMI I commit the transaction on the middle of a pdb:
(Pdb) import transaction transaction.commit()
I think that it is not very good approach :) .
How membrane interacts with portal_membership? How it is suppose to tell to portal_membership that it needs to use the membrane_tool data?
Where membrane update its catalog when creating a new user?
|
-- |
|
|
ken manheimer
Oct 9, 2010, 1:26:08 PM10/9/10
to reme...@lists.coactivate.org
On Sat, Oct 9, 2010 at 1:04 PM, Felipe Roquette <fel...@krei.com.br> wrote:
Em Sáb, 2010-10-09 às 11:09 -0400, ken manheimer escreveu:Yea, i saw that happening...
secondly, i've resumed working on this and the problem is clearly connected with the membrane tool's catalog of the member objects. in both the 2.0 membrane version and the prior one the tool's catalog is configured (Products/membrane/profiles/default/membrane_tool.xml) with FieldIndexes that duplicate getUserid, getUserName, and get getGroupId to be used for exact lookups on those values:
<index name="exact_getUserName" meta_type="FieldIndex">the problem is that running with the latest versions of membrane and remember the exact_getUserId is not getting into the membrane tool's member catalog entries, yet the exact_getUserName value is.
<indexed_attr value="getUserName"/>
</index>
<index name="getUserId" meta_type="ZCTextIndex">
<indexed_attr value="getUserId"/>
<extra name="index_type" value="Cosine Measure"/>
<extra name="lexicon_id" value="lexicon"/>
</index>
<index name="exact_getGroupId" meta_type="FieldIndex">
<indexed_attr value="getGroupId"/>
</index>
I don't know how you saw that, but to see in the ZMI I commit the transaction on the middle of a pdb:
(Pdb) import transaction transaction.commit()
I think that it is not very good approach :) .
a variety of ways, but the main one is to run my client in the foreground:
bin/client2 fg
i then try to register a client. (my zeo client2 is built with some debugging add-ons, but they're not necessary to see the traceback.) i also use the tests - but they're not easy to arrange.
How membrane interacts with portal_membership? How it is suppose to tell to portal_membership that it needs to use the membrane_tool data?
membrane is constructed to plug-in to the pluggable authentication service, PAS.
Where membrane update its catalog when creating a new user?
membrane types are registered to use the portal catalog and also the membrane tool (which is a derivative of ZCatalog). i don't remember where that registration happens, but it is by type (using archetypes services), and it is propertly registered - you can confirm that in the portal archetypes tool.
--
Felipe Roquette
felipe@krei.com.br
www.krei.com.br
+55 11 3431.0303
.
--
Archive: http://www.coactivate.org/[…]/1286644145164
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.
--
ken
http://myriadicity.net
ken manheimer
Oct 9, 2010, 1:31:40 PM10/9/10
to reme...@lists.coactivate.org
whoops - typo correction below:
ken
http://myriadicity.net
a variety of ways, but the main one is to run my client in the foreground:
bin/client2 fgi then try to register a client. (my zeo client2 is built with some debugging add-ons, but they're not
i meant to say, "i then try to register a member."
i'm gone for the rest of the day, but wanted to respond to your questions before that.
--
http://myriadicity.net
Felipe Roquette
Oct 9, 2010, 4:58:26 PM10/9/10
to reme...@lists.coactivate.org
I also noted that remember was always overriding the @@usergroup-userprefs, even if it was uninstalled (not actived).
To correct this behavior I added a browser layer to remember.
Can I upload this? Or sent to someone?
To correct this behavior I added a browser layer to remember.
Can I upload this? Or sent to someone?
ken manheimer
Oct 9, 2010, 9:54:29 PM10/9/10
to reme...@lists.coactivate.org
send me the diffs, if you can. if it's not too elaborate, i can include it on my branch, in which i'm hoping to have a fix for the cataloging problem, the updated authentication and other adjustments for use with membrane 2, the login-with-email fix from another branch, and miscellaneous other things. i'm going to be away for part of most of this week, so i won't have time to include it immediately, but will do so soon after i return.
(i also noticed that remember does not cleanly uninstall, and even regular installation adversely affects portals in the same zope instance. i'm not sure about that, but i do know that uninstalling remember fouls things up so you can't reinstall it. i don't think i'm going to be able to look into that any time soon, but would love to see it addressed...)
--
ken
http://myriadicity.net
--
ken
http://myriadicity.net
On Sat, Oct 9, 2010 at 4:58 PM, Felipe Roquette <fel...@krei.com.br> wrote:
I also noted that remember was always overriding the @@usergroup-userprefs, even if it was uninstalled (not actived).
To correct this behavior I added a browser layer to remember.
Can I upload this? Or sent to someone?
Felipe Roquette
Oct 9, 2010, 10:00:34 PM10/9/10
to remember
Em Sáb, 2010-10-09 às 11:09 -0400, ken manheimer escreveu:
my next task is to identify where the catalog implements the FieldIndex "indexed_attr value=", so i could try to determine what's missing or disrupting the process. any ideas about what could be causing this problem, and/or other ways to zero in on it, are welcome.
What should be the difference between "getId", "getUserId" and "getUserName"?
I saw that "getUserName" is defined at content/member.py but there is no 'def getUserId' so I added:
def getUserId(self):
"""Return the id of the user.
"""
return self.getId()
It seems that it is now working.
This method should be called here content/useridprovider.py , but I don't know it does not work there.
Now I am getting another error... for the pwreset_action.
I saw that "getUserName" is defined at content/member.py but there is no 'def getUserId' so I added:
def getUserId(self):
"""Return the id of the user.
"""
return self.getId()
It seems that it is now working.
This method should be called here content/useridprovider.py , but I don't know it does not work there.
Now I am getting another error... for the pwreset_action.
|
-- |
|
|
Felipe Roquette
Oct 9, 2010, 10:03:43 PM10/9/10
to reme...@lists.coactivate.org
Em Sáb, 2010-10-09 às 21:54 -0400, ken manheimer escreveu:
send me the diffs, if you can. if it's not too elaborate, i can include it on my branch, in which i'm hoping to have a fix for the cataloging problem, the updated authentication and other adjustments for use with membrane 2, the login-with-email fix from another branch, and miscellaneous other things. i'm going to be away for part of most of this week, so i won't have time to include it immediately, but will do so soon after i return.
Great!
I will send as soon as I finish.
I will send as soon as I finish.
(i also noticed that remember does not cleanly uninstall, and even regular installation adversely affects portals in the same zope instance. i'm not sure about that, but i do know that uninstalling remember fouls things up so you can't reinstall it. i don't think i'm going to be able to look into that any time soon, but would love to see it addressed...)
I will work on that too.
|
-- |
|
|
ken manheimer
Oct 10, 2010, 12:03:03 AM10/10/10
to reme...@lists.coactivate.org
On Sat, Oct 9, 2010 at 10:00 PM, Felipe Roquette <fel...@krei.com.br> wrote:
Em Sáb, 2010-10-09 às 11:09 -0400, ken manheimer escreveu:
my next task is to identify where the catalog implements the FieldIndex "indexed_attr value=", so i could try to determine what's missing or disrupting the process. any ideas about what could be causing this problem, and/or other ways to zero in on it, are welcome.What should be the difference between "getId", "getUserId" and "getUserName"?
I saw that "getUserName" is defined at content/member.py but there is no 'def getUserId' so I added:
def getUserId(self):
"""Return the id of the user.
"""
return self.getId()
It seems that it is now working.
great! this works for me, too, and i think i understand what was happening.
.getUserId() is required by the IMembraneUserObject interface, which (among others) the remember member is supposed to be implementing. i guess the catalog omitted the field because the method was missing, and i didn't notice that.
i've checked in this fix.
This method should be called here content/useridprovider.py , but I don't know it does not work there.
Now I am getting another error... for the pwreset_action.
me, too.
the user manager (probably one of the provisions for the PAS authentication machinery) .doChangeUser() looks for something that provides IMembraneUserChanger for the user. in the old, working remember version, it would find the right adapter, RememberUserChanger.doChangeUser(), from content/rememberuserchanger.py. in the new version, it's eventually finding the user / member object and trying to invoke .doChangeUser on that - and it doesn't have that method.
since it doesn't have that method, the remember object shouldn't be claiming to be implement IRememberUserChanger, so i'm removing that definition. now the adapter in RememberUserChanger is being found, and the password is successfully changed. (i'm not sure why the old version worked - the memer object there also claimed to implement IRememberUserChanger. perhaps it wound up later in sequence in the search results, so never got used?) anyway, i've checked in this change, too.
there's more work to do. for one thing, the refactored authentication scheme, with .authenticateCredentials() in the remember object, is not working right - logins work, but disabling membership isn't disabling the ability to log in. i'll look at that, hopefully before i'm travelling, but if not, then the week after.
thanks much for your help - i'd been looking at the problem for a while without noticing the missing getUserId() method. it's great to be unstuck from that!
Felipe Roquette
Oct 10, 2010, 12:37:31 AM10/10/10
to reme...@lists.coactivate.org
Em Dom, 2010-10-10 às 00:03 -0400, ken manheimer escreveu:
.getUserId() is required by the IMembraneUserObject interface, which (among others) the remember member is supposed to be implementing. i guess the catalog omitted the field because the method was missing, and i didn't notice that.
I think that the catalog should warned us about this.
the user manager (probably one of the provisions for the PAS authentication machinery) .doChangeUser() looks for something that provides IMembraneUserChanger for the user. in the old, working remember version, it would find the right adapter, RememberUserChanger.doChangeUser(), from content/rememberuserchanger.py. in the new version, it's eventually finding the user / member object and trying to invoke .doChangeUser on that - and it doesn't have that method.
since it doesn't have that method, the remember object shouldn't be claiming to be implement IRememberUserChanger, so i'm removing that definition. now the adapter in RememberUserChanger is being found, and the password is successfully changed. (i'm not sure why the old version worked - the memer object there also claimed to implement IRememberUserChanger. perhaps it wound up later in sequence in the search results, so never got used?) anyway, i've checked in this change, too.
great!
I was trying to solve this without success.
I was trying to solve this without success.
there's more work to do. for one thing, the refactored authentication scheme, with .authenticateCredentials() in the remember object, is not working right - logins work, but disabling membership isn't disabling the ability to log in. i'll look at that, hopefully before i'm travelling, but if not, then the week after.
Ok, I will see if I can help.
thanks much for your help - i'd been looking at the problem for a while without noticing the missing getUserId() method. it's great to be unstuck from that!
I think remember will soon be ready for plone4 :D
If there is something more, let me know.
Tomorrow I am going to work on this.
I'm at #plone , my name there is "roq_".
Thanks for all your effort!
For the browser layer to work (and to be able to use the plone without remember) you just need to add this at Products/remember/interfaces.py :
class IrememberCustomization(Interface):
"""This interface is registered in profiles/default/browserlayer.xml,
and is referenced in the 'layer' option of various browser resources.
When the product is installed, this marker interface will be applied
to every request, allowing layer-specific customisation.
"""
this at Products/remember/profiles/default/browserlayer.xml
<?xml version="1.0"?>
<!-- Register the package-specific browser layer, so that it will be activated
when this product is installed. -->
<layers>
<layer name="remember.customization.layer"
interface="Products.remember.interfaces.IrememberCustomization" />
this at the top of Products/remember/configure.zcml
<include package="plone.browserlayer" />
and add the layer attribute to Products/remember/browser/overrides.zcml to
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:zcml="http://namespaces.zope.org/zcml"
xmlns:browser="http://namespaces.zope.org/browser">
<browser:page
zcml:condition="installed plone.app.users"
name="usergroup-userprefs"
for="Products.CMFPlone.interfaces.IPloneSiteRoot"
class="plone.app.controlpanel.usergroups.UsersOverviewControlPanel"
permission="zope2.ManageUsers"
template="usergroups_usersoverview.pt"
layer="..interfaces.IrememberCustomization"
/>
</configure>
(Fill free to change any names.)
If there is something more, let me know.
Tomorrow I am going to work on this.
I'm at #plone , my name there is "roq_".
Thanks for all your effort!
For the browser layer to work (and to be able to use the plone without remember) you just need to add this at Products/remember/interfaces.py :
class IrememberCustomization(Interface):
"""This interface is registered in profiles/default/browserlayer.xml,
and is referenced in the 'layer' option of various browser resources.
When the product is installed, this marker interface will be applied
to every request, allowing layer-specific customisation.
"""
this at Products/remember/profiles/default/browserlayer.xml
<?xml version="1.0"?>
<!-- Register the package-specific browser layer, so that it will be activated
when this product is installed. -->
<layers>
<layer name="remember.customization.layer"
interface="Products.remember.interfaces.IrememberCustomization" />
this at the top of Products/remember/configure.zcml
<include package="plone.browserlayer" />
and add the layer attribute to Products/remember/browser/overrides.zcml to
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:zcml="http://namespaces.zope.org/zcml"
xmlns:browser="http://namespaces.zope.org/browser">
<browser:page
zcml:condition="installed plone.app.users"
name="usergroup-userprefs"
for="Products.CMFPlone.interfaces.IPloneSiteRoot"
class="plone.app.controlpanel.usergroups.UsersOverviewControlPanel"
permission="zope2.ManageUsers"
template="usergroups_usersoverview.pt"
layer="..interfaces.IrememberCustomization"
/>
</configure>
(Fill free to change any names.)
|
Best regards, |
|
|
ken manheimer
Oct 10, 2010, 4:09:18 AM10/10/10
to reme...@lists.coactivate.org
i realized i was mistaken about fixing the pwreset_form problem - it's not yet settled.
On Sun, Oct 10, 2010 at 12:37 AM, Felipe Roquette <fel...@krei.com.br> wrote:
Em Dom, 2010-10-10 às 00:03 -0400, ken manheimer escreveu:I think that the catalog should warned us about this.
.getUserId() is required by the IMembraneUserObject interface, which (among others) the remember member is supposed to be implementing. i guess the catalog omitted the field because the method was missing, and i didn't notice that.
i had the same thought.
great!the user manager (probably one of the provisions for the PAS authentication machinery) .doChangeUser() looks for something that provides IMembraneUserChanger for the user. in the old, working remember version, it would find the right adapter, RememberUserChanger.doChangeUser(), from content/rememberuserchanger.py. in the new version, it's eventually finding the user / member object and trying to invoke .doChangeUser on that - and it doesn't have that method.
since it doesn't have that method, the remember object shouldn't be claiming to be implement IRememberUserChanger, so i'm removing that definition. now the adapter in RememberUserChanger is being found, and the password is successfully changed. (i'm not sure why the old version worked - the memer object there also claimed to implement IRememberUserChanger. perhaps it wound up later in sequence in the search results, so never got used?) anyway, i've checked in this change, too.
I was trying to solve this without success.
unfortunately, i was mistaken - the adapter is not being found. not yet sure why...
--
ken
http://myriadicity.net
Felipe Roquette
Oct 11, 2010, 11:46:03 AM10/11/10
to reme...@lists.coactivate.org
Em Dom, 2010-10-10 às 04:09 -0400, ken manheimer escreveu:
i realized i was mistaken about fixing the pwreset_form problem - it's not yet settled.
This is what I did:
1) need to use Products.PasswordResetTool 2.0.3, older versions has a bug (string exceptions, similar to http://dev.plone.org/plone/ticket/9743 )
2) I was studying the code and there are a lot of interface, adapter, implementation stuff (man, that's confusing!).
I realized that
IRememberUserChanger is a subclass of IMembraneUserChanger (Products/remember/interfaces.py) and not of IUserChanger (Products/membrane/at/interfaces.py) so I change Products/remember/interfaces.py from
class IRememberUserChanger(IReferenceable,
IMembraneUserChanger):
to
class IRememberUserChanger(at_ifaces.IUserChanger):
(IUserChange already is a subclass of IReferenceable).
That did the trick....
I am testing it now.
1) need to use Products.PasswordResetTool 2.0.3, older versions has a bug (string exceptions, similar to http://dev.plone.org/plone/ticket/9743 )
2) I was studying the code and there are a lot of interface, adapter, implementation stuff (man, that's confusing!).
I realized that
IRememberUserChanger is a subclass of IMembraneUserChanger (Products/remember/interfaces.py) and not of IUserChanger (Products/membrane/at/interfaces.py) so I change Products/remember/interfaces.py from
class IRememberUserChanger(IReferenceable,
IMembraneUserChanger):
to
class IRememberUserChanger(at_ifaces.IUserChanger):
(IUserChange already is a subclass of IReferenceable).
That did the trick....
I am testing it now.
|
-- |
|
Felipe Roquette
Oct 11, 2010, 12:54:39 PM10/11/10
to reme...@lists.coactivate.org
Em Dom, 2010-10-10 às 00:03 -0400, ken manheimer escreveu:
there's more work to do. for one thing, the refactored authentication scheme, with .authenticateCredentials() in the remember object, is not working right - logins work, but disabling membership isn't disabling the ability to log in. i'll look at that, hopefully before i'm travelling, but if not, then the week after.
I think the problem is that authenticateCredentials() from remember is never called.
Membrane is calling authenticateCredentials from Products/membrane/at/authentication.py
Membrane is calling authenticateCredentials from Products/membrane/at/authentication.py
|
|
|
|
ken manheimer
Oct 11, 2010, 1:07:14 PM10/11/10
to reme...@lists.coactivate.org
On Mon, Oct 11, 2010 at 12:54 PM, Felipe Roquette <fel...@krei.com.br> wrote:
Em Dom, 2010-10-10 às 00:03 -0400, ken manheimer escreveu:
there's more work to do. for one thing, the refactored authentication scheme, with .authenticateCredentials() in the remember object, is not working right - logins work, but disabling membership isn't disabling the ability to log in. i'll look at that, hopefully before i'm travelling, but if not, then the week after.
I think the problem is that authenticateCredentials() from remember is never called.
Membrane is calling authenticateCredentials from Products/membrane/at/authentication.py
right - as with the pwreset_form problem, the issue is having the right things found according to interface lookup. we have to work that out for .authenticateCredentials() and the pwreset_form - it was working for IRememberUserChanger to derive from IMembraneUserChanger in the prior version, i think we need to find why it's not working wiht that arrangement in the new version. i hope to get to this later today, or maybe tomorrow, not sure i'll find the time...
--
Archive: http://www.coactivate.org/[…]/1286816369248
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.
--
ken
http://myriadicity.net
Felipe Roquette
Oct 11, 2010, 4:39:36 PM10/11/10
to reme...@lists.coactivate.org
Em Seg, 2010-10-11 às 13:07 -0400, ken manheimer escreveu:
right - as with the pwreset_form problem, the issue is having the right things found according to interface lookup. we have to work that out for .authenticateCredentials() and the pwreset_form - it was working for IRememberUserChanger to derive from IMembraneUserChanger in the prior version, i think we need to find why it's not working wiht that arrangement in the new version. i hope to get to this later today, or maybe tomorrow, not sure i'll find the time...
I think that remember is somehow confusing... because there a places it adapts something, in other places it directly implements... it seems that remember is not so organized as membrane.
As for now, it's probably easier to get a new reliable custom member using only membrane as using remember.
ken, what do you think?
As for now, it's probably easier to get a new reliable custom member using only membrane as using remember.
ken, what do you think?
|
-- |
|
ken manheimer
Oct 11, 2010, 4:53:42 PM10/11/10
to reme...@lists.coactivate.org
On Mon, Oct 11, 2010 at 4:39 PM, Felipe Roquette <fel...@krei.com.br> wrote:
Em Seg, 2010-10-11 às 13:07 -0400, ken manheimer escreveu:I think that remember is somehow confusing... because there a places it adapts something, in other places it directly implements... it seems that remember is not so organized as membrane.
right - as with the pwreset_form problem, the issue is having the right things found according to interface lookup. we have to work that out for .authenticateCredentials() and the pwreset_form - it was working for IRememberUserChanger to derive from IMembraneUserChanger in the prior version, i think we need to find why it's not working wiht that arrangement in the new version. i hope to get to this later today, or maybe tomorrow, not sure i'll find the time...
As for now, it's probably easier to get a new reliable custom member using only membrane as using remember.
ken, what do you think?
i think that membrane is significantly more carefully/thoroughly crafted than remember - the latter has a lot of rough edges. unfortunately, i'm not well versed enough in programming via interface adaptation to judge the specifics, but if you can implement your product based directly on membrane, making do without the features remember layers on top, than i would recommend doing so. i specifically need a number of the pieces remember offers, so am trying to reconcile it with wichert's membrane changes, and hopefully will be settling some of remember's rough edges in the process.
--
Felipe Roquette
felipe@krei.com.br
www.krei.com.br
+55 11 3431.0303
.
--
Archive: http://www.coactivate.org/[…]/1286829823580
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.
ken
http://myriadicity.net
Tim Knapp
Oct 12, 2010, 1:41:49 AM10/12/10
to reme...@lists.coactivate.org
I'd second this and also add to this that a lot of sites out 'in the
wild' use Remember so it is worth anyones while keeping it maintained
and working.
-Tim
>
> --
> Felipe Roquette
> fel...@krei.com.br
>
> www.krei.com.br
> +55 11 3431.0303
>
>
> .
>
>
> --
> Archive: http://www.coactivate.org/[…]/1286829823580
>
> To unsubscribe send an email with subject "unsubscribe" to
> reme...@lists.coactivate.org. Please contact
> remember...@lists.coactivate.org for questions.
> --
> ken
> http://myriadicity.net
>
>
>
> --
> Archive: http://www.coactivate.org/[…]/1286830439490
> To unsubscribe send an email with subject "unsubscribe" to
> reme...@lists.coactivate.org. Please contact
> remember...@lists.coactivate.org for questions.
>
--
Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2010/10/1286862113788
ken manheimer
Oct 13, 2010, 2:00:02 PM10/13/10
to reme...@lists.coactivate.org
incorporating what felipe found, i've checked into my remember branch further adjustments to accommodate wichert's membrane2 changes, so that the password reset form now works. it's now possible to for remember-based members to register/be registered, set and reset their password, and log in.
(the changes are not exactly what i would expect is necessary to get things working, so i'm not completely comfortable with them, but i wanted to get them out there for people to exercise, and possibly explain - wichert, ross?)
one problem that i know is still pending is making a member's login inhibited when their membership is disabled. that may be part of fixing the implementation of the .authenticateCredentials() method in the remember object - i have the rough code in place, but only now am to the point of using and resolving it. i'll be away for several days, and will be working on it when i return.
Felipe Roquette
Oct 13, 2010, 3:30:43 PM10/13/10
to reme...@lists.coactivate.org
Em Qua, 2010-10-13 às 14:00 -0400, ken manheimer escreveu:
(the changes are not exactly what i would expect is necessary to get things working, so i'm not completely comfortable with them, but i wanted to get them out there for people to exercise, and possibly explain - wichert, ross?)
I'm not comfortable either. There are a lot o interfaces and it is difficult to understand where each interface is and should be implemented.
I think we can/should comment more the source.
I think we can/should comment more the source.
one problem that i know is still pending is making a member's login inhibited when their membership is disabled. that may be part of fixing the implementation of the .authenticateCredentials() method in the remember object - i have the rough code in place, but only now am to the point of using and resolving it. i'll be away for several days, and will be working on it when i return.
Did you get the remember' .authenticateCredentials() to be called? Here somehow the .authenticateCredentials() of the membrane (I think "at" implementation inside membrane) was being called.
thanks for all your support, ken!
thanks for all your support, ken!
|
-- |
|
ken manheimer
Oct 23, 2010, 4:50:28 PM10/23/10
to reme...@lists.coactivate.org
i have settled all the major membrane2-interoperation remember issues identified so far, checked into my membrane2-reconciliation branch. you must update your membrane_tool catalog if you are upgrading a site with existing remember member objects - see instructions for doing so in the docs/HISTORY.txt entry.
the upshot is that you should be able to use this branch with membrane 2 in plone 4. i do not know that this will cover all the issues of the migration, so i would not yet recommend using it on a production site, however. it would a big help if people would try it out, though, to expose any further issues.
(felipe, i hope to soon include your much appreciated customization layer code, but wanted to get the membrane2 fixes out there for people to exercise first.)
i still have some questions about some of the fixes, and plan to post those questions soon. in any case, i expect that further implementation changes will be compatible with, or having simple migration paths for objects using this version.
ken manheimer
Oct 25, 2010, 3:03:44 PM10/25/10
to reme...@lists.coactivate.org, Wichert Akkerman, Ross Patterson
i've mentioned a few times (on the remember mailing list) having questions about some fixes i've applied to reconcile Products.remember with wichert's Products.membrane v2 changes. i'd like to describe those questions. i'm cc'ing wichert and ross directly, in the hopes that they - and any interested developers - would take a look and see if they can help clarify whether or not i'm heading in the right direction. this quandry - about getting feedback, and attention to Products.remember - also leads to a more general question about the disposition of Products.remember and its future. i'll describe what i mean after the more specific question.
the most overt changes in membrane 2 were removal of the I*Avail interfaces. after obvious Product.remember adjustments for that, password reset was failing with a traceback in (new and old) remember members because the RememberUserChanger adapter was not being engaged. we got it working by changes to the IRememberUserChanger interface and inclusion of the IRememberUserChanger interface directly among what remember's BaseMember provides. though these changes solve the problem, i'm not why they were necessary after the membrane 2 changes and not before, and generally unsure that they're the correct way to get it working.
i would love just a sanity check here. something as simple as "that looks fine" or "omg, that's completely wrong" - and, if the latter, some hints about what should work instead would be much appreciated.
the more general question concerns the future of remember. i gather that ross has been Products.remember's primary developer, and it appears, from the lack of responses for a long while, that he has moved on. i consider the ability to workflow membership status as crucial for manage otherwise self-service sites, which is of primary interest to me, and see Products.remember as a decent approach to providing that. i think i can get enough of a handle on Products.remember to continue to work with and advance it, but i would not want to invest my attention if there are other, better ways to get this functionality.
ross, could you take a moment to say whether you are just occupied with other things, or whether you would recommend something instead of remember? as i'm making the transition to plone 4 i'd like to go with a viable option, and i'm willing to help make Products.remember viable if it's the best course, but i can't afford to spend my efforts on it if it's a dead end!
ross, wichert, are you following this? can you help understand what's going on here, on either/both the specific and general questions?
On Wed, Oct 13, 2010 at 2:00 PM, ken manheimer <ken.ma...@gmail.com> wrote:
incorporating what felipe found, i've checked into my remember branch further adjustments to accommodate wichert's membrane2 changes, so that the password reset form now works. it's now possible to for remember-based members to register/be registered, set and reset their password, and log in.
(the changes are not exactly what i would expect is necessary to get things working, so i'm not completely comfortable with them, but i wanted to get them out there for people to exercise, and possibly explain - wichert, ross?)
one problem that i know is still pending is making a member's login inhibited when their membership is disabled. that may be part of fixing the implementation of the .authenticateCredentials() method in the remember object - i have the rough code in place, but only now am to the point of using and resolving it. i'll be away for several days, and will be working on it when i return.
On Mon, Oct 11, 2010 at 1:07 PM, ken manheimer <ken.ma...@gmail.com> wrote:
On Mon, Oct 11, 2010 at 12:54 PM, Felipe Roquette <fel...@krei.com.br> wrote:Em Dom, 2010-10-10 às 00:03 -0400, ken manheimer escreveu:there's more work to do. for one thing, the refactored authentication scheme, with .authenticateCredentials() in the remember object, is not working right - logins work, but disabling membership isn't disabling the ability to log in. i'll look at that, hopefully before i'm travelling, but if not, then the week after.
I think the problem is that authenticateCredentials() from remember is never called.
Membrane is calling authenticateCredentials from Products/membrane/at/authentication.py
right - as with the pwreset_form problem, the issue is having the right things found according to interface lookup. we have to work that out for .authenticateCredentials() and the pwreset_form - it was working for IRememberUserChanger to derive from IMembraneUserChanger in the prior version, i think we need to find why it's not working wiht that arrangement in the new version. i hope to get to this later today, or maybe tomorrow, not sure i'll find the time...
Felipe Roquette
felipe@krei.com.br
www.krei.com.br
+55 11 3431.0303.
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.
--
ken
http://myriadicity.net
Reply all
Reply to author
Forward
0 new messages