[PLIP-Advisories] Re: [Plone] #9347: registration policy

2009-07-14 Thread plip-advisories
#9347: registration policy
-+--
 Reporter:  dokter   |Owner:  dokter 
 Type:  PLIP |   Status:  closed 
 Priority:  minor|Milestone:  4.0
Component:  Unknown  |   Resolution:  wontfix
 Keywords:   |  
-+--
Changes (by esteele):

  * status:  new = closed
  * resolution:  = wontfix


Comment:

 Rejected for 4.0 by FWT vote.

-- 
Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:7
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories


[PLIP-Advisories] Re: [Plone] #9347: registration policy

2009-07-08 Thread plip-advisories
#9347: registration policy
-+--
 Reporter:  dokter   |Owner:  dokter
 Type:  PLIP |   Status:  new   
 Priority:  minor|Milestone:  4.0   
Component:  Unknown  |   Resolution:
 Keywords:   |  
-+--

Comment(by erikrose):

 As I said on #9310, I like the idea.
  * We should use the existing workflow framework rather than inventing
 something new.
  * We have member data spread all over the place at the moment. Showing a
 good understanding of which way we're moving and moving with it would
 increase the chances of me voting yes on the implementation.
  * I'd like to see the config UI end up in the same configlet as, say, the
 Let members choose their own passwords setting and other member-centric
 things.
  * It's worth considering whether it makes sense to represent the pending
 users as full-fledged content objects. Consider, it, but don't consider it
 too hard; we almost certainly wouldn't want to suddenly make 50,000
 content objects in an LDAP situation, for instance. The objects could be
 deleted upon approval, but that would be a surprising behavior compared
 with what usually happens when content is approved or published.

 Assuming the above, FWT vote +1.

-- 
Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:2
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories


[PLIP-Advisories] Re: [Plone] #9347: registration policy

2009-07-08 Thread plip-advisories
#9347: registration policy
-+--
 Reporter:  dokter   |Owner:  dokter
 Type:  PLIP |   Status:  new   
 Priority:  minor|Milestone:  4.0   
Component:  Unknown  |   Resolution:
 Keywords:   |  
-+--

Comment(by alecm):

 I think only a very small percentage of sites require member approval.
 Therefore, I believe this would make a desirable add-on package, but it
 does not belong in the core at this time.  I'm not particularly passionate
 about this though:

 FWT vote: -0

-- 
Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:6
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories


[PLIP-Advisories] Re: [Plone] #9347: registration policy

2009-07-08 Thread plip-advisories
#9347: registration policy
-+--
 Reporter:  dokter   |Owner:  dokter
 Type:  PLIP |   Status:  new   
 Priority:  minor|Milestone:  4.0   
Component:  Unknown  |   Resolution:
 Keywords:   |  
-+--

Comment(by raphael):

 FWT vote: -1 for core

 but I'd appreciate this as an add-on.

-- 
Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:3
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories


[PLIP-Advisories] Re: [Plone] #9347: registration policy

2009-07-08 Thread plip-advisories
#9347: registration policy
-+--
 Reporter:  dokter   |Owner:  dokter
 Type:  PLIP |   Status:  new   
 Priority:  minor|Milestone:  4.0   
Component:  Unknown  |   Resolution:
 Keywords:   |  
-+--

Comment(by erikrose):

 Because this could be done pretty unintrusively and because the
 implementation might want change once we have dexterity's lighter-weight
 content objects (dexterity), I think we should do this as an add-on for
 now. I'd be happy to reconsider this for 5.0, when we might be able to do
 a full members-as-content implementation without such drags on performance
 or storage.

 Changing my FWT vote to -1.

-- 
Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:5
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories


[PLIP-Advisories] Re: [Plone] #9347: registration policy

2009-07-02 Thread plip-advisories
#9347: registration policy
-+--
 Reporter:  dokter   |Owner:  dokter
 Type:  PLIP |   Status:  new   
 Priority:  minor|Milestone:  4.0   
Component:  Unknown  |   Resolution:
 Keywords:   |  
-+--
Changes (by raphael):

 * cc: plip-advisor...@lists.plone.org (added)
  * owner:  = dokter


-- 
Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:1
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories