On Sun, 2009-06-14 at 16:23 -0700, Ross Patterson wrote: > Tim Knapp <[email protected]> writes: > > > Just an update that when I tested this TTW I noticed there were errors > > re. missing fields appearing in the console output so I double-checked > > these fields (some were present in the interface but not in the class > > itself). Once I resolved this, the username field appeared fine (i.e. > > without modifying the write_permission). > > Thanks for documenting your progress in a google-able place so that > others might benefit. :)
:) my thoughts exactly. > > Ross > > > On Sat, 2009-06-13 at 16:46 +1200, Tim Knapp wrote: > >> 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 > >> > >>>>>>>>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>>>>>>>> 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 > >> > >>>>>>>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>>>>>>> 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 > >> > >>>>>>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>>>>>> 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 > >> > >>>>>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>>>>> 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 > >> > >>>>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>>>> 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 > >> > >>>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>>> 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 > >> > >>>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>>> 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 > >> > >>> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >>> 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 > >> > >> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org > >> > >> 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 > >> > > remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org 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 > >> > remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org 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 > >> remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org for > >> questions. > >> > > > > > > > > -- > > Archive: > > http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1245016711452To > > unsubscribe send an email with subject "unsubscribe" to > > [email protected]. Please contact > > remember-manager-zwoeplungu1pszqg2b6wd0b+6bgkl...@public.gmane.org for > > questions. > > > > -- > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2009/06/1245021845107 > 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/1245022691963 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
