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.  :)

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.

Reply via email to