Hi Ken, On Fri, 2009-06-12 at 15:55 -0500, Info wrote: > Tim, > > Looks like it depends on which state your member is in - when in the > 'new' or 'new_private' states, Anonymous (and therefore the member) has > the permission to edit the ID, but not in the 'private' or 'public' states.
Yeah I noticed this too but this is happening in the 'new' state when you click on the '/join_form' link and in this state the user does have the EDIT_ID_PERMISSION afaict. > > Not sure if that's what you were running into or not, but suspect it is, > if using a different permission (rendering the EDIT_ID_PERMISSION > useless) fixed your issue. > > If that was it, you might want to rather go back and edit the > state-specific permissions the way you need them (and keeping this > separate permission in tact.) Depends on your needs. Yeah, I'll have another look at this but everything does seem cocher as far as I can tell. Thanks again, Tim > > Ken > > Tim Knapp wrote: > > Hi Ken, > > > > That worked a treat and was something I had thought I'd try today too as > > I had thought permissions was the only issue I could think of. Weird > > thing is I'm using the default member_auto_workflow so the user should > > have the 'membrane: edit id' (or whatever it's called) permission. Oh > > well, it works now. > > > > Thanks again, > > Tim > > > > On Fri, 2009-06-12 at 09:38 -0500, Info wrote: > > > >> I believe that the macro is smart enough to apply > >> validations/permissions/etc. defined for the field and that you have a > >> security restriction preventing editing of the id field. > >> > >> If you take a look at member_schema.py of the remember product, you'll > >> see that there are two different permissions specified for read vs. > >> write access to the id field. > >> > >> If you don't want to enforce this, you can override these attributes in > >> your custom class, such that your id.write_permission= whatever > >> permission you want to apply. It currently applies EDIT_ID_PERMISSION, > >> but you might want to apply EDIT_PROPERTIES_PERMISSION (used by > >> 'fullname' field for write permission), or might want to apply > >> EDIT_SECURITY_PERMISSION. > >> > >> -Ken > >> > >> Tim Knapp wrote: > >> > >>> Ok, further test results: > >>> > >>> If I do the following in reg_form: > >>> <span tal:content="python: schematas[fieldset]['id']"/> > >>> > >>> I can see the id field object appear in the reg_form. > >>> > >>> > >>> If I then do the following: > >>> <metal:fieldMacro use-macro="python: > >>> here.widget(schematas[fieldset]['id'].getName(), mode='view')"/> > >>> > >>> I see the autogenerated id. So far so good. > >>> > >>> > >>> If I then do: > >>> <metal:fieldMacro use-macro="python: > >>> here.widget(schematas[fieldset]['id'].getName(), mode='edit')"/> > >>> > >>> the field disappears. > >>> > >>> > >>> If I then edit remember/skins/remember/memid.pt and edit the 'edit > >>> macro' as follows: > >>> > >>> <metal:define define-macro="edit"> > >>> <metal:use use-macro="here/widgets/field/macros/edit"> > >>> Blah blah blah > >>> </metal:use> > >>> </metal:define> > >>> > >>> the field disappears again. But if I remove the 'use-macro' line, the > >>> edit macro renders fine on the reg_form. So it appears that something is > >>> going wrong in the field 'edit macro'. I had a look through this code > >>> but couldn't see anything obvious that would've been causing issues > >>> (lots of boiler plate code in there). > >>> > >>> Any more ideas on what could be causing the id field to 'disappear'? > >>> > >>> Thanks again, > >>> Tim > >>> > >>> On Fri, 2009-06-12 at 21:29 +1200, Tim Knapp wrote: > >>> > >>> > >>>> Doh, forgot to include the link: > >>>> http://www.openplans.org/projects/remember/lists/remember/archive/2006/12/1166184414100 > >>>> > >>>> -Tim > >>>> > >>>> On Fri, 2009-06-12 at 21:24 +1200, Tim Knapp wrote: > >>>> > >>>> > >>>>> Hello again, > >>>>> > >>>>> I found this post in the remember mailing list archives and thought it > >>>>> might be related to my issue so I checked my classes and I don't have > >>>>> any BaseObject classes overriding the remember ones. I also tried > >>>>> manually setting up the schema by importing the schema from > >>>>> member_schema and assembling it as per the member module in remember but > >>>>> still no 'id' field :( > >>>>> > >>>>> All the other fields appear fine. > >>>>> > >>>>> -Tim > >>>>> > >>>>> On Fri, 2009-06-12 at 20:35 +1200, Tim Knapp wrote: > >>>>> > >>>>> > >>>>>> On Thu, 2009-06-11 at 16:14 -0500, Info wrote: > >>>>>> > >>>>>> > >>>>>>> Tim, > >>>>>>> > >>>>>>> In your custom member class, try overriding the showPasswordField() > >>>>>>> method that membrane or remember defines and be sure to return True. > >>>>>>> Just paste this into your class definition in the area where you > >>>>>>> define > >>>>>>> your custom methods: > >>>>>>> > >>>>>>> def showPasswordField(self): > >>>>>>> #If this method returns True, then the password entry field > >>>>>>> is > >>>>>>> made visible on the edit form. > >>>>>>> return True > >>>>>>> > >>>>>>> > >>>>>>> I think that's the secret little gotcha you're running into. I've > >>>>>>> had > >>>>>>> to use this before, myself. > >>>>>>> > >>>>>>> > >>>>>> Thanks Ken, this worked a treat and now the password fields show > >>>>>> (funnily enough I had tried this earlier but it didn't work, which was > >>>>>> probably related to another issue in my Remember-based class). > >>>>>> > >>>>>> Now, though, the username (id) field still doesn't show. I've edited > >>>>>> the > >>>>>> reg_form.cpt and got it to show 'all' the fields (i.e. remove the > >>>>>> regfield check) and even then it doesn't show the username field. I > >>>>>> debugged the initialisation of the remember-based class and the 'id' > >>>>>> field is definitely in the schema. Any further clues? > >>>>>> > >>>>>> /me carries on debugging. > >>>>>> > >>>>>> Thanks, > >>>>>> Tim > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Ken Wasetis > >>>>>>> > >>>>>>> > >>>>>>> Tim Knapp wrote: > >>>>>>> > >>>>>>> > >>>>>>>> Reporting again from the front-line ;) > >>>>>>>> > >>>>>>>> After having a look back over my remember modules it occurred to me > >>>>>>>> that > >>>>>>>> the problem may well be in the way I've set them up as I realised > >>>>>>>> that > >>>>>>>> none of the standard remember fields were showing on the reg_form, > >>>>>>>> e.g. > >>>>>>>> username, password, although email was, which is a default one. > >>>>>>>> > >>>>>>>> I've setup my remember-based classes as follows: I have a > >>>>>>>> 'base' (Products.subscribemember.content.basesubscribemember), which > >>>>>>>> contains the base schema (a bunch of fields that are shared between > >>>>>>>> the > >>>>>>>> 2 remember classes), and a > >>>>>>>> 'Individual' (Products.subscribemember.content.individual) and an > >>>>>>>> 'Organization' type (Products.subscribemember.content.organization). > >>>>>>>> At > >>>>>>>> this stage I put a 'BaseSubscribemember' class in the 'individual' > >>>>>>>> module with its InitializeClass method being called (as per the > >>>>>>>> standard > >>>>>>>> BaseMember class in remember). This subclasses > >>>>>>>> Products.remember.content.member.Member and then the 'Individual' > >>>>>>>> class > >>>>>>>> subclasses the BaseSubscribemember class (copied here[1] for your > >>>>>>>> viewing pleasure). The classes are also defined in a configure.zcml > >>>>>>>> in > >>>>>>>> the 'content' folder (just the Individual and Organization classes > >>>>>>>> mind > >>>>>>>> you, not the BaseSubscribemember class). But as I say, the username > >>>>>>>> and > >>>>>>>> password fields don't show. Any clues on what I'm doing wrong? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Tim > >>>>>>>> > >>>>>>>> [1] http://duffyd.pastebin.com/f6ba0ca55 > >>>>>>>> > >>>>>>>> P.S. I've not had these kind of issues on Plone 3.2.2 with remember > >>>>>>>> 1.1. > >>>>>>>> > >>>>>>>> On Thu, 2009-06-11 at 17:50 +1200, Tim Knapp wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Hello again, > >>>>>>>>> > >>>>>>>>> Just further to this thread, is this branch[1] the one to use for > >>>>>>>>> the > >>>>>>>>> latest updates to the Plone 2.5-compatible version of remember? > >>>>>>>>> Just I > >>>>>>>>> note that the last changes to this branch was 10 months ago, which > >>>>>>>>> in > >>>>>>>>> the scale of things isn't really too old :) > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Tim > >>>>>>>>> > >>>>>>>>> [1] http://dev.plone.org/collective/browser/remember/branches/1.0 > >>>>>>>>> > >>>>>>>>> On Thu, 2009-06-11 at 16:50 +1200, Tim Knapp wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I've tried to set the validate_email value to False in both the GS > >>>>>>>>>> profile and in code as follows (in the test fixture setup): > >>>>>>>>>> > >>>>>>>>>> # don't send emails out by default > >>>>>>>>>> ptool = getToolByName(self.portal, 'portal_properties') > >>>>>>>>>> ptool.site_properties.validate_email = False > >>>>>>>>>> self.portal.validate_email = False > >>>>>>>>>> > >>>>>>>>>> As you can see I've set both the property in site_properties and > >>>>>>>>>> on the > >>>>>>>>>> portal root itself as it seems that these values changed between > >>>>>>>>>> Plone > >>>>>>>>>> 2.5 and 3 and the code checks both. But no matter how I set it, the > >>>>>>>>>> password fields don't show up on the reg_form. All my other fields > >>>>>>>>>> are > >>>>>>>>>> fine. > >>>>>>>>>> > >>>>>>>>>> I also put a pdb in the showPasswordField in > >>>>>>>>>> remember.content.member but > >>>>>>>>>> this code doesn't even get called. Any clues? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Tim > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Archive: > >>>>>>>>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244695860553 > >>>>>>>>>> To unsubscribe send an email with subject "unsubscribe" to > >>>>>>>>>> [email protected]. Please contact > >>>>>>>>>> [email protected] for questions. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Archive: > >>>>>>>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244699451588 > >>>>>>>>> To unsubscribe send an email with subject "unsubscribe" to > >>>>>>>>> [email protected]. Please contact > >>>>>>>>> [email protected] for questions. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> -- > >>>>>>>> Archive: > >>>>>>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244750366059 > >>>>>>>> To unsubscribe send an email with subject "unsubscribe" to > >>>>>>>> [email protected]. Please contact > >>>>>>>> [email protected] for questions. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> -- > >>>>>>> Archive: > >>>>>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244754879212 > >>>>>>> To unsubscribe send an email with subject "unsubscribe" to > >>>>>>> [email protected]. Please contact > >>>>>>> [email protected] for questions. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> Archive: > >>>>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244795841989 > >>>>>> To unsubscribe send an email with subject "unsubscribe" to > >>>>>> [email protected]. Please contact > >>>>>> [email protected] for questions. > >>>>>> > >>>>>> > >>>>>> > >>>>> -- > >>>>> Archive: > >>>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244798735364 > >>>>> To unsubscribe send an email with subject "unsubscribe" to > >>>>> [email protected]. Please contact > >>>>> [email protected] for questions. > >>>>> > >>>>> > >>>>> > >>>> -- > >>>> Archive: > >>>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244799008921 > >>>> To unsubscribe send an email with subject "unsubscribe" to > >>>> [email protected]. Please contact > >>>> [email protected] for questions. > >>>> > >>>> > >>>> > >>> > >>> -- > >>> Archive: > >>> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244802503393 > >>> To unsubscribe send an email with subject "unsubscribe" to > >>> [email protected]. Please contact > >>> [email protected] for questions. > >>> > >>> > >>> > >>> > >>> > >>> > >> -- > >> Archive: > >> http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244817529836 > >> To unsubscribe send an email with subject "unsubscribe" to > >> [email protected]. Please contact > >> [email protected] for questions. > >> > >> > > > > > > > > -- > > Archive: > > http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244839237340 > > To unsubscribe send an email with subject "unsubscribe" to > > [email protected]. Please contact > > [email protected] for questions. > > > > > > > > > > > > > -- > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244840142894 > To unsubscribe send an email with subject "unsubscribe" to > [email protected]. Please contact > [email protected] for questions. > -- Archive: http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1244868431920 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
