[Remember Mailing List] disposition of membrane/remember w.r.t. main plone development?

[ken manheimer]

i'd like to understand better where membrane/remember fits in to the evolving plone world.  there's at least one membrane/remember feature that i consider necessary for many portal membership situations, and think it's important enough to warrant more official adoption into the plone core, or else alternative ways to implement the feature, if member/remember isn't somehow suitable.

the feature is administrative acceptance or denial of membership applications.  making the member's registration status subject to workflow is particularly good because there are other many quite useful related things that can be done, as well - it provides suitably fine-grained control.

are there other approaches people are taking to provide approval-regulated membership?  might it be that membrane/remember needs to be polished more to gain greater acceptance?  i've developed a sampleremember-based product that cleans up sampleremembers workflowed membership and provides some useful affiliated features as well.  i'd like to understand more the plone project status of membrane/remember better, though, so i know what i'm committing to with the membrane/remember approach.

anyone else grappled with these questions, and have some insights to offer?
--
ken
http://myriadicity.net

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

[Wichert Akkerman]

On 8/30/10 17:04 , ken manheimer wrote:
> i'd like to understand better where membrane/remember fits in to the
> evolving plone world. there's at least one membrane/remember feature
> that i consider necessary for many portal membership situations, and
> think it's important enough to warrant more official adoption into the
> plone core, or else alternative ways to implement the feature, if
> member/remember isn't somehow suitable.

membrane supports it easily. The common way to do that is to add a
workflow to your user type, and check the workflow state in your
authentication method. For example:

def authenticateCredentials(self):
wt=getToolByName(self, "portal_workflow")
state=wt.getInfoFor(self, "review_state")
if state!="approved":
return None
# otherwise do normal checking

Ross appears to have added a special permission to handle this
("membrane: Can authenticate") as well. I'm not entirely convinced that
should be in membrane core itself; it feels like something that should
be done in a IMembraneUserAuth implementation, so I'm tempted to rip
that out.

> are there other approaches people are taking to provide
> approval-regulated membership? might it be that membrane/remember needs
> to be polished more to gain greater acceptance?

It certainly needs some readable documentation. I've dropped a few
sphinx bits in the codebase today, but the documentation needs a lot
more work before I would consider it developer friendly.

Wichert.

--
Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2010/08/1283181106246

[ken manheimer]

On Mon, Aug 30, 2010 at 11:11 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

On 8/30/10 17:04 , ken manheimer wrote:

i'd like to understand better where membrane/remember fits in to the
evolving plone world.  there's at least one membrane/remember feature
that i consider necessary for many portal membership situations, and
think it's important enough to warrant more official adoption into the
plone core, or else alternative ways to implement the feature, if
member/remember isn't somehow suitable.

membrane supports it easily. The common way to do that is to add a workflow to your user type, and check the workflow state in your authentication method. For example:

def authenticateCredentials(self):
   wt=getToolByName(self, "portal_workflow")
   state=wt.getInfoFor(self, "review_state")
   if state!="approved":
       return None
   # otherwise do normal checking

i think i wandered through that code when debugging problems authenticating in my sampleremember-based product, and realized that this is part of what enables having disabled memberships in the system which can not be used for logging in.

 

Ross appears to have added a special permission to handle this ("membrane: Can authenticate") as well. I'm not entirely convinced that should be in membrane core itself; it feels like something that should be done in a IMembraneUserAuth implementation, so I'm tempted to rip that out.

i'm not familiar enough with the whole code path to have any insight.

 

are there other approaches people are taking to provide
approval-regulated membership?  might it be that membrane/remember needs
to be polished more to gain greater acceptance?

It certainly needs some readable documentation. I've dropped a few sphinx bits in the codebase today, but the documentation needs a lot more work before I would consider it developer friendly.

it was the sampleremember product that enabled me to do something without much understanding of the underlying system.  though it starts out as a pretty blind, cargo-cult exposure, i eventually had to get some substantial acquaintance with the system to  get my product working and adapt it to my purposes.

i can't afford to do so at the moment, but think it would be quite useful to document how sampleremember works, and how it can be adapted, to help people get a handle on the code.  i'm hoping that releasing my product, which i'll do once i've got it going with plone 4, will also be helpful towards that end...

 

Wichert.

--
ken
http://myriadicity.net

--
Archive: http://www.coactivate.org/[…]/1283182358406

[Wichert Akkerman]

On 8/30/10 17:11 , Wichert Akkerman wrote:
> Ross appears to have added a special permission to handle this
> ("membrane: Can authenticate") as well. I'm not entirely convinced that
> should be in membrane core itself; it feels like something that should
> be done in a IMembraneUserAuth implementation, so I'm tempted to rip
> that out.

I've ripped it out. As compensation I've added a FAQ page to the sphinx
with an example for implementating this.

Wichert.

--
Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2010/08/1283200959936

[ken manheimer]

On Mon, Aug 30, 2010 at 4:42 PM, Wichert Akkerman <wic...@wiggy.net> wrote:

On 8/30/10 17:11 , Wichert Akkerman wrote:

Ross appears to have added a special permission to handle this
("membrane: Can authenticate") as well. I'm not entirely convinced that
should be in membrane core itself; it feels like something that should
be done in a IMembraneUserAuth implementation, so I'm tempted to rip
that out.

I've ripped it out. As compensation I've added a FAQ page to the sphinx with an example for implementating this.

i'm looking at revising my product to adapt to your changes, and realizing that there are some backward-incompatable changes needed in Products.remember, specifically, some which will require changes to some derived product's configuration.  i'm considering implementing those changes, but would like to check whether i'm thinking along the right lines.

the method to be added to the member object is fairly simple, as outlined in your faq.rst.

complications come in, though, in reimplementing the prior mechanism for identifying active-member workflow states.

before your changes, membrane utils.py offered a function, generateCategorySetIdForType(), which is easy enough to resituate in remember's utils.py.

things get tricky when figuring where to put the registry for the active states.  prior to your changes, the settings were configured into the membrane_tool.  moving them will break configuration of remember-derived implementations that use different active states than Product.remember's.  (my product uses different active states, so i will have to change them.)

specifically, there's a membrane_tool property 'active-workflow-state' keyed to the type of member object, configured in the product's 'membrane_tool.xml'.

i suppose this all could be implemented in the 'portal_memberdata' tool.  would that be reasonable?

if so, i'll look at implementing the fixes in a branch in the Products.remember repository.  (as it currently stands, Products.remember doesn't work with the new version of membrane.)

thanks!

Wichert.

--
ken
http://myriadicity.net

--
Archive: http://www.coactivate.org/[…]/1283211205402

[Wichert Akkerman]

On 8/31/10 01:23 , ken manheimer wrote:
> complications come in, though, in reimplementing the prior mechanism for
> identifying active-member workflow states.
>
> before your changes, membrane utils.py offered a
> function, generateCategorySetIdForType(), which is easy enough
> to resituate in remember's utils.py.
>
> things get tricky when figuring where to put the registry for the active
> states. prior to your changes, the settings were configured into the
> membrane_tool.

That was not a change I made actually. The code you are referring to was
deprecated a 18 months ago, and was removed 14 months ago to be replaced
with the simple permission check which I did remove.
http://dev.plone.org/collective/changeset/88643/Products.membrane/trunk
and
http://dev.plone.org/collective/changeset/88634/Products.membrane/trunk
are the relevant changesets.

> moving them will break configuration of remember-derived
> implementations that use different active states than
> Product.remember's. (my product uses different active states, so i will
> have to change them.)

I think Ross's basic idea was sound: remember should be updated to use a
permission instead of hardcoding workflow state names. You can then
easily use a custom workflow.

Wichert.

--
Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2010/08/1283237678338