Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Hi,
the securityext component is actually located in the application folder.
It implements the sending of the password remainder, password updated
services, permission groups etc. that we want available in the
framework-only release also.

Do we agree to change it to move it over there?
At least the labels used from ecommerce needs to be changed and some
store dependencies also.

-Bruno

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

It seems to me that a Framework+Party+Content installation would
better fit the requirements in
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution.

-Bruno

2009/12/30 Bruno Busco <br...@gmail.com>:
> Adrian,
> I think our divergence comes from how we imagine the framework-only being used.
> I imagine the framework-only installation ready to be used as soon as installed.
> Admin can login and start adding users, groups, set permissions.
> Users can start logging in, personalizing their home Portal pages,
> select their favourite Theme.
>
> Then admin plugs a new component in the hot-deploy (or in
> application), only a set of users can access it because others have no
> permission and do not even know about the new application.
> Then admin adds permission to users, new portlets became available to
> the users, more menus etc.
>
> May be "framework-only" is not the right name for this distribution
> but I definitively think it is what would best help the OFBiz users.
>
> -Bruno
>
>
> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>> I don't agree that emailing forgotten passwords is like the Webtools
>> application. As you have discovered, emailing forgotten passwords entails
>> some decision making, looking up information in various entities, selecting
>> and rendering an email body template, etc. From my perspective, all of those
>> things are outside the scope of the framework.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>>
>>> Adrian,
>>> I agree that this can be done in an application using the framework
>>> but this application should be located in the framework folder like
>>> the webtools application.
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>
>>>> All of the things you are describing could be done by an application
>>>> developer that is using the framework.
>>>>
>>>> It would be wise to draw a very distinct and strict line between
>>>> framework-level functionality and application-level functionality.
>>>>
>>>> -Adrian
>>>>
>>>> Bruno Busco wrote:
>>>>>
>>>>> Then we should have a setPrimaryEmailAddress service defined in the
>>>>> framework (that sets the userLogin.email field) and overridden in the
>>>>> Party application that sets/create the propert PArty/ContactMech.
>>>>>
>>>>> Does this make sense?
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>>>
>>>>>> Adrian,
>>>>>> the getPrimaryEmailAddress defined in the framework could return the
>>>>>> email field stored in the userLogin entity and when it is override by
>>>>>> the Party application can retrieve the address from the
>>>>>> userlLogin->Party->ContactMech chain.
>>>>>>
>>>>>> In this way we should get it working in the framawork-only also.
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>>>>
>>>>>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>>>>>> does not let the forgotPassword feature work in the framework-only
>>>>>>> installation (no party).
>>>>>>>
>>>>>>> -Bruno
>>>>>>>
>>>>>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>>>>>
>>>>>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>>>>>> framework and returns nothing. The Party application can override the
>>>>>>>> service to return the primary email address, if it exists.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> Bruno Busco wrote:
>>>>>>>>>
>>>>>>>>> One thing we need in the framework is the possibility to create a
>>>>>>>>> userLogin with an associated email address and have the possibility
>>>>>>>>> to
>>>>>>>>> have the password emailed if forgotten.
>>>>>>>>> This is actually done in
>>>>>>>>>  public static String emailPassword(HttpServletRequest request,
>>>>>>>>> HttpServletResponse response) {
>>>>>>>>> that is located in LoginEvents.java in securityext.
>>>>>>>>>
>>>>>>>>> To get the email address, emailPassword(...) checks if the
>>>>>>>>> userLoginId
>>>>>>>>> exists, then find the related party, then find a related ContactMech
>>>>>>>>> with PRIMARY_MAIL purpose.
>>>>>>>>> To get the email body and other details, emailPassword(...) starts
>>>>>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>>>>>
>>>>>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>>>>>> service needs to be in applications/securityext and cannot be
>>>>>>>>> available in a framework-only distribution.
>>>>>>>>>
>>>>>>>>> Now,
>>>>>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>>>>>> not the right implementation for the backoffice (and thus for the
>>>>>>>>> framework-only).
>>>>>>>>>
>>>>>>>>> I propose to do the following:
>>>>>>>>> 1) Put an email address in the userLogin entity. This would be used
>>>>>>>>> to
>>>>>>>>> retrieve the password.
>>>>>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>>>>>> common component (renaming it simply "EmailSetting") and transform
>>>>>>>>> the
>>>>>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore
>>>>>>>>> and
>>>>>>>>> EmailSetting.
>>>>>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>>>>>> that does things differently: using the email address in the
>>>>>>>>> userLogin
>>>>>>>>> entity and retrieving the email settings accessing to the
>>>>>>>>> EmailSetting
>>>>>>>>> entity.
>>>>>>>>>
>>>>>>>>> What do you think about?
>>>>>>>>>
>>>>>>>>> -Bruno
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>> Hi Bruno,
>>>>>>>>>>
>>>>>>>>>> The whole point of the securityext component is to allow portions
>>>>>>>>>> of
>>>>>>>>>> security related functionality to depend on the application
>>>>>>>>>> components, I
>>>>>>>>>> believe this was done as part of the effort to isolate the
>>>>>>>>>> framework
>>>>>>>>>> from
>>>>>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>>>>>> portions
>>>>>>>>>> of securityext back to the framework when there is no dependency on
>>>>>>>>>> the
>>>>>>>>>> application code but I don't necessarily think we should have a
>>>>>>>>>> goal
>>>>>>>>>> of
>>>>>>>>>> removing the securityext component altogether.
>>>>>>>>>>
>>>>>>>>>> It wouldn't be possible to remove securityext without either
>>>>>>>>>> removing
>>>>>>>>>> functionality or otherwise transferring logic that is traditionally
>>>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>> application domain back to the framework.  The more that we look at
>>>>>>>>>> doing
>>>>>>>>>> the latter the more we need to consider exactly what the needs are
>>>>>>>>>> that
>>>>>>>>>> we
>>>>>>>>>> want a framework only installation to fulfill.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> HotWax Media
>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>
>>>>>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi David, devs,
>>>>>>>>>>> I searched the SVN logs to look for a reason for those general
>>>>>>>>>>> purpose
>>>>>>>>>>> login and password stuff being in the application and not in the
>>>>>>>>>>> framework.
>>>>>>>>>>> I found they are there since the incubator time.
>>>>>>>>>>>
>>>>>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>>>>>> security component in the framework. I would like to try to do it,
>>>>>>>>>>> but
>>>>>>>>>>> please, if you see something blocking this or something that
>>>>>>>>>>> should
>>>>>>>>>>> be
>>>>>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> -Bruno
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> Scott,
>>>>>>>>>>>> from a securityext code browsing I see that there is a dependence
>>>>>>>>>>>> from
>>>>>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>>>>>
>>>>>>>>>>>> Party:
>>>>>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person,
>>>>>>>>>>>> PartyRole,
>>>>>>>>>>>> PartyContactMech entities
>>>>>>>>>>>>  -> Could be moved to Party?
>>>>>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission
>>>>>>>>>>>> in
>>>>>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>>>>>
>>>>>>>>>>>> Product:
>>>>>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to
>>>>>>>>>>>> be
>>>>>>>>>>>> used for a ProductStore. The password email should be a core
>>>>>>>>>>>> feature
>>>>>>>>>>>> not used for ProductStores only.
>>>>>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>>>>>> level part (dedicated for a ProductStore) implemented in the
>>>>>>>>>>>> Product
>>>>>>>>>>>> component?
>>>>>>>>>>>>
>>>>>>>>>>>> Ecommerce:
>>>>>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->
>>>>>>>>>>>> Since
>>>>>>>>>>>> the email password should not only be an ecommerce feature this
>>>>>>>>>>>> should
>>>>>>>>>>>> be moved to Common.
>>>>>>>>>>>>
>>>>>>>>>>>> Should we try to resolve these dependences and then merge to
>>>>>>>>>>>> security
>>>>>>>>>>>> in the framework?
>>>>>>>>>>>>
>>>>>>>>>>>> -Bruno
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess the first thing we need to understand is why it exists
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> first
>>>>>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>>>>>> components
>>>>>>>>>>>>> that
>>>>>>>>>>>>> prevent it from being in the framework (even if perhaps some of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> logic
>>>>>>>>>>>>> could be moved).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>
>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> the securityext component is actually located in the
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> folder.
>>>>>>>>>>>>>> It implements the sending of the password remainder, password
>>>>>>>>>>>>>> updated
>>>>>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>>>>>> framework-only release also.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>>>>>> At least the labels used from ecommerce needs to be changed and
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>> store dependencies also.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Bruno
>>>
>>
>

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Adrian,
I think our divergence comes from how we imagine the framework-only being used.
I imagine the framework-only installation ready to be used as soon as installed.
Admin can login and start adding users, groups, set permissions.
Users can start logging in, personalizing their home Portal pages,
select their favourite Theme.

Then admin plugs a new component in the hot-deploy (or in
application), only a set of users can access it because others have no
permission and do not even know about the new application.
Then admin adds permission to users, new portlets became available to
the users, more menus etc.

May be "framework-only" is not the right name for this distribution
but I definitively think it is what would best help the OFBiz users.

-Bruno


2009/12/30 Adrian Crum <ad...@hlmksw.com>:
> I don't agree that emailing forgotten passwords is like the Webtools
> application. As you have discovered, emailing forgotten passwords entails
> some decision making, looking up information in various entities, selecting
> and rendering an email body template, etc. From my perspective, all of those
> things are outside the scope of the framework.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> Adrian,
>> I agree that this can be done in an application using the framework
>> but this application should be located in the framework folder like
>> the webtools application.
>>
>> -Bruno
>>
>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>
>>> All of the things you are describing could be done by an application
>>> developer that is using the framework.
>>>
>>> It would be wise to draw a very distinct and strict line between
>>> framework-level functionality and application-level functionality.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
>>>>
>>>> Then we should have a setPrimaryEmailAddress service defined in the
>>>> framework (that sets the userLogin.email field) and overridden in the
>>>> Party application that sets/create the propert PArty/ContactMech.
>>>>
>>>> Does this make sense?
>>>>
>>>> -Bruno
>>>>
>>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>>
>>>>> Adrian,
>>>>> the getPrimaryEmailAddress defined in the framework could return the
>>>>> email field stored in the userLogin entity and when it is override by
>>>>> the Party application can retrieve the address from the
>>>>> userlLogin->Party->ContactMech chain.
>>>>>
>>>>> In this way we should get it working in the framawork-only also.
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>>>
>>>>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>>>>> does not let the forgotPassword feature work in the framework-only
>>>>>> installation (no party).
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>>>>
>>>>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>>>>> framework and returns nothing. The Party application can override the
>>>>>>> service to return the primary email address, if it exists.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> Bruno Busco wrote:
>>>>>>>>
>>>>>>>> One thing we need in the framework is the possibility to create a
>>>>>>>> userLogin with an associated email address and have the possibility
>>>>>>>> to
>>>>>>>> have the password emailed if forgotten.
>>>>>>>> This is actually done in
>>>>>>>>  public static String emailPassword(HttpServletRequest request,
>>>>>>>> HttpServletResponse response) {
>>>>>>>> that is located in LoginEvents.java in securityext.
>>>>>>>>
>>>>>>>> To get the email address, emailPassword(...) checks if the
>>>>>>>> userLoginId
>>>>>>>> exists, then find the related party, then find a related ContactMech
>>>>>>>> with PRIMARY_MAIL purpose.
>>>>>>>> To get the email body and other details, emailPassword(...) starts
>>>>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>>>>
>>>>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>>>>> service needs to be in applications/securityext and cannot be
>>>>>>>> available in a framework-only distribution.
>>>>>>>>
>>>>>>>> Now,
>>>>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>>>>> not the right implementation for the backoffice (and thus for the
>>>>>>>> framework-only).
>>>>>>>>
>>>>>>>> I propose to do the following:
>>>>>>>> 1) Put an email address in the userLogin entity. This would be used
>>>>>>>> to
>>>>>>>> retrieve the password.
>>>>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>>>>> common component (renaming it simply "EmailSetting") and transform
>>>>>>>> the
>>>>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore
>>>>>>>> and
>>>>>>>> EmailSetting.
>>>>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>>>>> that does things differently: using the email address in the
>>>>>>>> userLogin
>>>>>>>> entity and retrieving the email settings accessing to the
>>>>>>>> EmailSetting
>>>>>>>> entity.
>>>>>>>>
>>>>>>>> What do you think about?
>>>>>>>>
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>
>>>>>>>>> Hi Bruno,
>>>>>>>>>
>>>>>>>>> The whole point of the securityext component is to allow portions
>>>>>>>>> of
>>>>>>>>> security related functionality to depend on the application
>>>>>>>>> components, I
>>>>>>>>> believe this was done as part of the effort to isolate the
>>>>>>>>> framework
>>>>>>>>> from
>>>>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>>>>> portions
>>>>>>>>> of securityext back to the framework when there is no dependency on
>>>>>>>>> the
>>>>>>>>> application code but I don't necessarily think we should have a
>>>>>>>>> goal
>>>>>>>>> of
>>>>>>>>> removing the securityext component altogether.
>>>>>>>>>
>>>>>>>>> It wouldn't be possible to remove securityext without either
>>>>>>>>> removing
>>>>>>>>> functionality or otherwise transferring logic that is traditionally
>>>>>>>>> in
>>>>>>>>> the
>>>>>>>>> application domain back to the framework.  The more that we look at
>>>>>>>>> doing
>>>>>>>>> the latter the more we need to consider exactly what the needs are
>>>>>>>>> that
>>>>>>>>> we
>>>>>>>>> want a framework only installation to fulfill.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> HotWax Media
>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>
>>>>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>>>>
>>>>>>>>>> Hi David, devs,
>>>>>>>>>> I searched the SVN logs to look for a reason for those general
>>>>>>>>>> purpose
>>>>>>>>>> login and password stuff being in the application and not in the
>>>>>>>>>> framework.
>>>>>>>>>> I found they are there since the incubator time.
>>>>>>>>>>
>>>>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>>>>> security component in the framework. I would like to try to do it,
>>>>>>>>>> but
>>>>>>>>>> please, if you see something blocking this or something that
>>>>>>>>>> should
>>>>>>>>>> be
>>>>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> -Bruno
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>> Scott,
>>>>>>>>>>> from a securityext code browsing I see that there is a dependence
>>>>>>>>>>> from
>>>>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>>>>
>>>>>>>>>>> Party:
>>>>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person,
>>>>>>>>>>> PartyRole,
>>>>>>>>>>> PartyContactMech entities
>>>>>>>>>>>  -> Could be moved to Party?
>>>>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission
>>>>>>>>>>> in
>>>>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>>>>
>>>>>>>>>>> Product:
>>>>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to
>>>>>>>>>>> be
>>>>>>>>>>> used for a ProductStore. The password email should be a core
>>>>>>>>>>> feature
>>>>>>>>>>> not used for ProductStores only.
>>>>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>>>>> level part (dedicated for a ProductStore) implemented in the
>>>>>>>>>>> Product
>>>>>>>>>>> component?
>>>>>>>>>>>
>>>>>>>>>>> Ecommerce:
>>>>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->
>>>>>>>>>>> Since
>>>>>>>>>>> the email password should not only be an ecommerce feature this
>>>>>>>>>>> should
>>>>>>>>>>> be moved to Common.
>>>>>>>>>>>
>>>>>>>>>>> Should we try to resolve these dependences and then merge to
>>>>>>>>>>> security
>>>>>>>>>>> in the framework?
>>>>>>>>>>>
>>>>>>>>>>> -Bruno
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> I guess the first thing we need to understand is why it exists
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> first
>>>>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>>>>> components
>>>>>>>>>>>> that
>>>>>>>>>>>> prevent it from being in the framework (even if perhaps some of
>>>>>>>>>>>> the
>>>>>>>>>>>> logic
>>>>>>>>>>>> could be moved).
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Scott
>>>>>>>>>>>>
>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> the securityext component is actually located in the
>>>>>>>>>>>>> application
>>>>>>>>>>>>> folder.
>>>>>>>>>>>>> It implements the sending of the password remainder, password
>>>>>>>>>>>>> updated
>>>>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>>>>> framework-only release also.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>>>>> At least the labels used from ecommerce needs to be changed and
>>>>>>>>>>>>> some
>>>>>>>>>>>>> store dependencies also.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Bruno
>>
>

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Hi David,
inline

> Please keep in mind that is just your document. There is no such thing as implicit agreement, and if there are disagreements on the mailing list IMO that is just as valid as someone going in and changing your document (and most people would probably consider it less rude too, which is maybe why no one has made changes there).
>
> BTW, looking through those... where are the CMS related requirements? What sorts of business activities drive these requirements?
>
> Actually, to be more accurate, I wouldn't call any of the things you listed there requirements, they all look like designs to me, ie solutions to the problems rather than the problems themselves.

The end-user requirements list I have written was only intended to
start to define what the end-user will be able to do with the
framework-only.
This is what we really need right now; of course I can replace the
"can" with "shall" if you think this will help (I really don't).

The list has already been useful at least because Adrian has suggested
some changes (may be adding a comment on the Confluence page would be
better) so, please, let's continue using it and please, everybody be
rude! Add comments or even change it. I did not write having in mind
it was perfect but just a startup of the a requirements elicitation
process.

> And what about those who not only don't care either way about CMS, but really don't want to bother with CMS in the system? One way or another you're sure to get complaints...

Why should I have compliants from people that will have a CMS base
system and a set of selectable additional components that add the
functionalities they need?
The content component, as it is now, is something that cannot be
(easily) removed from OFBiz so ALL users should somehow bother with
it. Even the help system is based on the content component.

> That is an interesting opinion, and it's great that you have been looking into this. Could you share what you have based this opinion on, it might be enlightening to others too.

This comes just from what I have figured out looking a little bit at
the communities around products as Drupal, Joomla, OpenCms, Magento
etc.
I may be wrong, for sure I am far from being a web analyst. But I have
seen e-commerce modules to be pluggable into CMS products never the
other way around.

> For example, one specific idea might be to move some of the email stuff from content to the framework somewhere. Sending and receiving emails is pretty low-level, though that doesn't mean we'd want to move all of it as the CommunicationEvent stuff is definitely higher level and ties to many many other things in the system, and that's a much harder line to draw.

A similar idea is just what originated my frst mail in this thread. I
did see that the send forgotten password email is in the
application/securityext and suggested to move to framework/security.
To have the forgotten password mail in the framework we should have
the email system as well for sure. So here we are on the same page.

So moving forward now.
I have seen an even more basic item we should agree:

Do we want the framework-only to be a library only, not directly
runnable/usable without an additional application installed
or we want the framework-only to be directly usable with a few set of
functionality?

-Bruno

Re: Moving securityext to the framework

[Adrian Crum <ad...@yahoo.com>]

--- On Sun, 1/3/10, David E Jones <de...@me.com> wrote:
> On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote:
> 
> > --- On Sun, 1/3/10, David E Jones <de...@me.com>
> wrote:
> >> One way or another if we're moving things around,
> >> especially moving higher level stuff into the
> framework,
> >> then we should definitely discuss it first and
> even try to
> >> reach a consensus around it.
> >> 
> >> For example, one specific idea might be to move
> some of the
> >> email stuff from content to the framework
> somewhere. Sending
> >> and receiving emails is pretty low-level, though
> that
> >> doesn't mean we'd want to move all of it as the
> >> CommunicationEvent stuff is definitely higher
> level and ties
> >> to many many other things in the system, and
> that's a much
> >> harder line to draw.
> >> 
> >> For the most part the dividing line between
> framework and
> >> the base applications is that business-driven
> things stay in
> >> the apps, and technical facilitation and
> interfacing lives
> >> in the framework. If we want to change that, it
> would be a
> >> big change, and you can certainly expect some
> disagreement.
> > 
> > This is the same thing I tried to suggest. The
> framework should include only those things needed to get an
> application to run, and not include application code.
> > 
> > From my perspective, sending and receiving emails is
> an application. It could run on top of the framework, and
> other applications could utilize it.
> 
> Aren't most programs that run on top of an operating system
> applications? How does that help us draw the line?
> 
> Also if email is a higher level function that should only
> be supported on an application level, what about MCA rules
> and email libraries in the Java API? Aren't those both
> pretty low level things?
> 
> Doesn't that muddy the distinction more than clarify it?

I'm sure everyone has their own mental picture of where that line is drawn.

In my mind, I picture the framework composed of only the entity engine, service engine, the rendering engine, the security framework, and the webtools and example applications.

Email could be a component that runs on top of the framework and that other components use.

In my mind that is a clear distinction. There is no doubt others won't see it that way.

-Adrian



      

Re: Moving securityext to the framework

[David E Jones <de...@me.com>]

On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote:

> --- On Sun, 1/3/10, David E Jones <de...@me.com> wrote:
>> One way or another if we're moving things around,
>> especially moving higher level stuff into the framework,
>> then we should definitely discuss it first and even try to
>> reach a consensus around it.
>> 
>> For example, one specific idea might be to move some of the
>> email stuff from content to the framework somewhere. Sending
>> and receiving emails is pretty low-level, though that
>> doesn't mean we'd want to move all of it as the
>> CommunicationEvent stuff is definitely higher level and ties
>> to many many other things in the system, and that's a much
>> harder line to draw.
>> 
>> For the most part the dividing line between framework and
>> the base applications is that business-driven things stay in
>> the apps, and technical facilitation and interfacing lives
>> in the framework. If we want to change that, it would be a
>> big change, and you can certainly expect some disagreement.
> 
> This is the same thing I tried to suggest. The framework should include only those things needed to get an application to run, and not include application code.
> 
> From my perspective, sending and receiving emails is an application. It could run on top of the framework, and other applications could utilize it.

Aren't most programs that run on top of an operating system applications? How does that help us draw the line?

Also if email is a higher level function that should only be supported on an application level, what about MCA rules and email libraries in the Java API? Aren't those both pretty low level things?

Doesn't that muddy the distinction more than clarify it?

-David

Re: Moving securityext to the framework

[Adrian Crum <ad...@yahoo.com>]

--- On Sun, 1/3/10, David E Jones <de...@me.com> wrote:
> One way or another if we're moving things around,
> especially moving higher level stuff into the framework,
> then we should definitely discuss it first and even try to
> reach a consensus around it.
> 
> For example, one specific idea might be to move some of the
> email stuff from content to the framework somewhere. Sending
> and receiving emails is pretty low-level, though that
> doesn't mean we'd want to move all of it as the
> CommunicationEvent stuff is definitely higher level and ties
> to many many other things in the system, and that's a much
> harder line to draw.
> 
> For the most part the dividing line between framework and
> the base applications is that business-driven things stay in
> the apps, and technical facilitation and interfacing lives
> in the framework. If we want to change that, it would be a
> big change, and you can certainly expect some disagreement.

This is the same thing I tried to suggest. The framework should include only those things needed to get an application to run, and not include application code.

>From my perspective, sending and receiving emails is an application. It could run on top of the framework, and other applications could utilize it.

-Adrian



      

Re: Moving securityext to the framework

[David E Jones <de...@me.com>]

On Jan 3, 2010, at 3:53 AM, Bruno Busco wrote:

> When I sayd "at least me" I should have said "To implement the
> framework-only distribution end-user requirements here
> http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"
> We should agree or change what is written there and then work to implement it.

Please keep in mind that is just your document. There is no such thing as implicit agreement, and if there are disagreements on the mailing list IMO that is just as valid as someone going in and changing your document (and most people would probably consider it less rude too, which is maybe why no one has made changes there).

BTW, looking through those... where are the CMS related requirements? What sorts of business activities drive these requirements?

Actually, to be more accurate, I wouldn't call any of the things you listed there requirements, they all look like designs to me, ie solutions to the problems rather than the problems themselves.

> The framework-only work should of course generate two workproducts:
> - A standalone framework implementing the requirements
> - A set of additional components, each with its declared dependencies,
> that can be plugged in the framework-only installation.
> 
> For my next project all I would like to do is to select the newly
> needed components and plug them in the framework-only.
> 
> The sets of components framework+party+content+commonext should give
> us a basic configuration that, from the user POV should be similar to
> a CMS system but powered by OFBiz.

And what about those who not only don't care either way about CMS, but really don't want to bother with CMS in the system? One way or another you're sure to get complaints...

> This CMS configuration, IMO, should have the greatest number of
> potential users and, for this reason, should receive a greater
> contribution from a greater community.

That is an interesting opinion, and it's great that you have been looking into this. Could you share what you have based this opinion on, it might be enlightening to others too.

> This configuration is also what we would need to run the OFBiz web
> site itself (if we are still interested in getting this up and
> running).
> 
> Of course, as you say, there are some things in the selected
> components (framework, party, content, commonext) that are not
> required. These parts are, for sure, the ones that do not let the
> database to be even created because depends on other components. There
> are entities that should be moved away from party as the complete
> org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other
> that should be extended in other components.

Again, that's based on your designs which are based on requirements you haven't shared yet.

> So coming to your question: "what should we change in how we're doing things?"
> May be nothing. Just discuss/agree on the requirements for the
> framework-only and then start working on a branch.

That sounds like a change to me...

One way or another if we're moving things around, especially moving higher level stuff into the framework, then we should definitely discuss it first and even try to reach a consensus around it.

For example, one specific idea might be to move some of the email stuff from content to the framework somewhere. Sending and receiving emails is pretty low-level, though that doesn't mean we'd want to move all of it as the CommunicationEvent stuff is definitely higher level and ties to many many other things in the system, and that's a much harder line to draw.

For the most part the dividing line between framework and the base applications is that business-driven things stay in the apps, and technical facilitation and interfacing lives in the framework. If we want to change that, it would be a big change, and you can certainly expect some disagreement.

On the other hand, you can certainly work on decoupling in the base applications in order to isolate the parts that you want to. They'll stay in the applications directory, but you can certainly make changes to make things run fine in spite of deleting or disabling other components.

-David


> 2010/1/2 David E Jones <de...@me.com>:
>> 
>> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>> 
>>>> One major question is whether framework, on its own, should even be
>>>> runnable as an application. In my opinion, it is a library, not an app
>>>> and doesn't need to be operational on its own.
>>> 
>>> The more we discuss about this the more I get convinced that what we
>>> (or at least me) intend for framework-only distribution should be
>>> better named "OFBiz-core".
>>> The OFBiz-core could consist of framework + party + content + commonext.
>>> 
>>> A distribution with these components set up is somewhat similar to
>>> what I mean for a framework where developer can start building its
>>> office automation application without the necessity to disable
>>> anything but having all the power of the framework and the "core"
>>> applications.
>> 
>> Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?
>> 
>> I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.
>> 
>> Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.
>> 
>> So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.
>> 
>> Based on that, what should we change in how we're doing things?
>> 
>> -David
>> 
>> 

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

When I sayd "at least me" I should have said "To implement the
framework-only distribution end-user requirements here
http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"
We should agree or change what is written there and then work to implement it.

The framework-only work should of course generate two workproducts:
- A standalone framework implementing the requirements
- A set of additional components, each with its declared dependencies,
that can be plugged in the framework-only installation.

For my next project all I would like to do is to select the newly
needed components and plug them in the framework-only.

The sets of components framework+party+content+commonext should give
us a basic configuration that, from the user POV should be similar to
a CMS system but powered by OFBiz.
This CMS configuration, IMO, should have the greatest number of
potential users and, for this reason, should receive a greater
contribution from a greater community.

This configuration is also what we would need to run the OFBiz web
site itself (if we are still interested in getting this up and
running).

Of course, as you say, there are some things in the selected
components (framework, party, content, commonext) that are not
required. These parts are, for sure, the ones that do not let the
database to be even created because depends on other components. There
are entities that should be moved away from party as the complete
org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other
that should be extended in other components.

So coming to your question: "what should we change in how we're doing things?"
May be nothing. Just discuss/agree on the requirements for the
framework-only and then start working on a branch.

-Bruno

2010/1/2 David E Jones <de...@me.com>:
>
> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>
>>> One major question is whether framework, on its own, should even be
>>> runnable as an application. In my opinion, it is a library, not an app
>>> and doesn't need to be operational on its own.
>>
>> The more we discuss about this the more I get convinced that what we
>> (or at least me) intend for framework-only distribution should be
>> better named "OFBiz-core".
>> The OFBiz-core could consist of framework + party + content + commonext.
>>
>> A distribution with these components set up is somewhat similar to
>> what I mean for a framework where developer can start building its
>> office automation application without the necessity to disable
>> anything but having all the power of the framework and the "core"
>> applications.
>
> Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?
>
> I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.
>
> Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.
>
> So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.
>
> Based on that, what should we change in how we're doing things?
>
> -David
>
>

Re: Moving securityext to the framework

[Christopher Snow <sn...@snowconsulting.co.uk>]

David E Jones wrote:
> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>
>   
>>> One major question is whether framework, on its own, should even be
>>> runnable as an application. In my opinion, it is a library, not an app
>>> and doesn't need to be operational on its own.
>>>       
>> The more we discuss about this the more I get convinced that what we
>> (or at least me) intend for framework-only distribution should be
>> better named "OFBiz-core".
>> The OFBiz-core could consist of framework + party + content + commonext.
>>
>> A distribution with these components set up is somewhat similar to
>> what I mean for a framework where developer can start building its
>> office automation application without the necessity to disable
>> anything but having all the power of the framework and the "core"
>> applications.
>>     
>
> Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?
>
> I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.
>
> Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.
>
> So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.
>
> Based on that, what should we change in how we're doing things?
>
> -David
>
>   
David,

Your view ties in very much with my recent experiences.  My last project 
just required framework + party, whereas my current project requires 
framework + party + workeffort.

This has made me question whether it is practical to separate the 
components as you will never know what combination you may need. 

Could the problem be approached from a different angle - if unwanted 
components are commented out and there are dependency issues, rather 
than missing dependencies causing fatal startup errors at startup, how 
about a warning being issued instead?

Cheers,

Chris

Re: Moving securityext to the framework

[David E Jones <de...@me.com>]

On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:

>> One major question is whether framework, on its own, should even be
>> runnable as an application. In my opinion, it is a library, not an app
>> and doesn't need to be operational on its own.
> 
> The more we discuss about this the more I get convinced that what we
> (or at least me) intend for framework-only distribution should be
> better named "OFBiz-core".
> The OFBiz-core could consist of framework + party + content + commonext.
> 
> A distribution with these components set up is somewhat similar to
> what I mean for a framework where developer can start building its
> office automation application without the necessity to disable
> anything but having all the power of the framework and the "core"
> applications.

Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?

I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.

Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.

So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.

Based on that, what should we change in how we're doing things?

-David

Re: Moving securityext to the framework

[Tim Ruppert <ti...@hotwaxmedia.com>]

Those of us with strong Unix backgounds really don't want to see anything named "core" - so I'd say let's look for some other name.  What you're pushing for Bruno - is much needed and could be a great enhancement to the usage of OFBiz.  Anything that'll make it easier for people to build - non-eCommerce related applications without having to disable anything is a huge win in my book.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 2, 2010, at 1:42 PM, Bruno Busco wrote:

>> One major question is whether framework, on its own, should even be
>> runnable as an application. In my opinion, it is a library, not an app
>> and doesn't need to be operational on its own.
> 
> The more we discuss about this the more I get convinced that what we
> (or at least me) intend for framework-only distribution should be
> better named "OFBiz-core".
> The OFBiz-core could consist of framework + party + content + commonext.
> 
> A distribution with these components set up is somewhat similar to
> what I mean for a framework where developer can start building its
> office automation application without the necessity to disable
> anything but having all the power of the framework and the "core"
> applications.
> 
> -Bruno

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

> One major question is whether framework, on its own, should even be
> runnable as an application. In my opinion, it is a library, not an app
> and doesn't need to be operational on its own.

The more we discuss about this the more I get convinced that what we
(or at least me) intend for framework-only distribution should be
better named "OFBiz-core".
The OFBiz-core could consist of framework + party + content + commonext.

A distribution with these components set up is somewhat similar to
what I mean for a framework where developer can start building its
office automation application without the necessity to disable
anything but having all the power of the framework and the "core"
applications.

-Bruno

Re: Moving securityext to the framework

[Tim Ruppert <ti...@hotwaxmedia.com>]

Those are exactly the type of questions I was writing concurrently Adam - thanks for bringing them up.  My off the cuff response is that this isn't tomcat or jboss - it runs in the containers, but is not one itself, so what exactly would the framework do without an application sitting on top of it?  I think that we should start looking at positioning this somewhat like what a JBoss stack implementation might look like - examples for Seam, examples for Hibernate, examples of security implementations, possibly even examples of content management / use of Webslinger, etc, etc.  

This would put it up favorably against what the framework "competition" looks like - and would likely show how much easier it is to develop applications in OFBiz vs some of these other frameworks that are supposed to be simple for people to use.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 2, 2010, at 1:55 PM, Adam Heath wrote:

> Ean Schuessler wrote:
>> Adrian Crum wrote:
>>> I don't agree that emailing forgotten passwords is like the Webtools
>>> application. As you have discovered, emailing forgotten passwords
>>> entails some decision making, looking up information in various
>>> entities, selecting and rendering an email body template, etc. From my
>>> perspective, all of those things are outside the scope of the framework.
>> 
>> I agree. It is easy to imagine that some applications would not allow a
>> password to be reset via email. It might be that the application uses
>> biometrics, cryptographic signatures or who knows what. The framework
>> authentication stubs should accommodate a diversity of approaches.
>> 
>> One major question is whether framework, on its own, should even be
>> runnable as an application. In my opinion, it is a library, not an app
>> and doesn't need to be operational on its own.
> 
> What is your definition of operational?  A servlet container that is
> listing for requests on 8009, 8080?  Ready to process rmi requests?
> 
> Is framework a *pure* library, where the application that runs on top
> of it is responsible for starting any long-term, background services,
> or should framework be the application wrapper?

Re: Moving securityext to the framework

[Adam Heath <do...@brainfood.com>]

Ean Schuessler wrote:
> Adrian Crum wrote:
>> I don't agree that emailing forgotten passwords is like the Webtools
>> application. As you have discovered, emailing forgotten passwords
>> entails some decision making, looking up information in various
>> entities, selecting and rendering an email body template, etc. From my
>> perspective, all of those things are outside the scope of the framework.
> 
> I agree. It is easy to imagine that some applications would not allow a
> password to be reset via email. It might be that the application uses
> biometrics, cryptographic signatures or who knows what. The framework
> authentication stubs should accommodate a diversity of approaches.
> 
> One major question is whether framework, on its own, should even be
> runnable as an application. In my opinion, it is a library, not an app
> and doesn't need to be operational on its own.

What is your definition of operational?  A servlet container that is
listing for requests on 8009, 8080?  Ready to process rmi requests?

Is framework a *pure* library, where the application that runs on top
of it is responsible for starting any long-term, background services,
or should framework be the application wrapper?

Re: Moving securityext to the framework

[Ean Schuessler <ea...@brainfood.com>]

Adrian Crum wrote:
> I don't agree that emailing forgotten passwords is like the Webtools
> application. As you have discovered, emailing forgotten passwords
> entails some decision making, looking up information in various
> entities, selecting and rendering an email body template, etc. From my
> perspective, all of those things are outside the scope of the framework.

I agree. It is easy to imagine that some applications would not allow a
password to be reset via email. It might be that the application uses
biometrics, cryptographic signatures or who knows what. The framework
authentication stubs should accommodate a diversity of approaches.

One major question is whether framework, on its own, should even be
runnable as an application. In my opinion, it is a library, not an app
and doesn't need to be operational on its own.

Re: Moving securityext to the framework

[Adrian Crum <ad...@hlmksw.com>]

I don't agree that emailing forgotten passwords is like the Webtools 
application. As you have discovered, emailing forgotten passwords 
entails some decision making, looking up information in various 
entities, selecting and rendering an email body template, etc. From my 
perspective, all of those things are outside the scope of the framework.

-Adrian

Bruno Busco wrote:
> Adrian,
> I agree that this can be done in an application using the framework
> but this application should be located in the framework folder like
> the webtools application.
> 
> -Bruno
> 
> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>> All of the things you are describing could be done by an application
>> developer that is using the framework.
>>
>> It would be wise to draw a very distinct and strict line between
>> framework-level functionality and application-level functionality.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>> Then we should have a setPrimaryEmailAddress service defined in the
>>> framework (that sets the userLogin.email field) and overridden in the
>>> Party application that sets/create the propert PArty/ContactMech.
>>>
>>> Does this make sense?
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>> Adrian,
>>>> the getPrimaryEmailAddress defined in the framework could return the
>>>> email field stored in the userLogin entity and when it is override by
>>>> the Party application can retrieve the address from the
>>>> userlLogin->Party->ContactMech chain.
>>>>
>>>> In this way we should get it working in the framawork-only also.
>>>>
>>>> -Bruno
>>>>
>>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>>>> does not let the forgotPassword feature work in the framework-only
>>>>> installation (no party).
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>>>> framework and returns nothing. The Party application can override the
>>>>>> service to return the primary email address, if it exists.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> Bruno Busco wrote:
>>>>>>> One thing we need in the framework is the possibility to create a
>>>>>>> userLogin with an associated email address and have the possibility to
>>>>>>> have the password emailed if forgotten.
>>>>>>> This is actually done in
>>>>>>>   public static String emailPassword(HttpServletRequest request,
>>>>>>> HttpServletResponse response) {
>>>>>>> that is located in LoginEvents.java in securityext.
>>>>>>>
>>>>>>> To get the email address, emailPassword(...) checks if the userLoginId
>>>>>>> exists, then find the related party, then find a related ContactMech
>>>>>>> with PRIMARY_MAIL purpose.
>>>>>>> To get the email body and other details, emailPassword(...) starts
>>>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>>>
>>>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>>>> service needs to be in applications/securityext and cannot be
>>>>>>> available in a framework-only distribution.
>>>>>>>
>>>>>>> Now,
>>>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>>>> not the right implementation for the backoffice (and thus for the
>>>>>>> framework-only).
>>>>>>>
>>>>>>> I propose to do the following:
>>>>>>> 1) Put an email address in the userLogin entity. This would be used to
>>>>>>> retrieve the password.
>>>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>>>> common component (renaming it simply "EmailSetting") and transform the
>>>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>>>>>> EmailSetting.
>>>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>>>> that does things differently: using the email address in the userLogin
>>>>>>> entity and retrieving the email settings accessing to the EmailSetting
>>>>>>> entity.
>>>>>>>
>>>>>>> What do you think about?
>>>>>>>
>>>>>>> -Bruno
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>> Hi Bruno,
>>>>>>>>
>>>>>>>> The whole point of the securityext component is to allow portions of
>>>>>>>> security related functionality to depend on the application
>>>>>>>> components, I
>>>>>>>> believe this was done as part of the effort to isolate the framework
>>>>>>>> from
>>>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>>>> portions
>>>>>>>> of securityext back to the framework when there is no dependency on
>>>>>>>> the
>>>>>>>> application code but I don't necessarily think we should have a goal
>>>>>>>> of
>>>>>>>> removing the securityext component altogether.
>>>>>>>>
>>>>>>>> It wouldn't be possible to remove securityext without either removing
>>>>>>>> functionality or otherwise transferring logic that is traditionally
>>>>>>>> in
>>>>>>>> the
>>>>>>>> application domain back to the framework.  The more that we look at
>>>>>>>> doing
>>>>>>>> the latter the more we need to consider exactly what the needs are
>>>>>>>> that
>>>>>>>> we
>>>>>>>> want a framework only installation to fulfill.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>
>>>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>>>
>>>>>>>>> Hi David, devs,
>>>>>>>>> I searched the SVN logs to look for a reason for those general
>>>>>>>>> purpose
>>>>>>>>> login and password stuff being in the application and not in the
>>>>>>>>> framework.
>>>>>>>>> I found they are there since the incubator time.
>>>>>>>>>
>>>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>>>> security component in the framework. I would like to try to do it,
>>>>>>>>> but
>>>>>>>>> please, if you see something blocking this or something that should
>>>>>>>>> be
>>>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> -Bruno
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>>>> Scott,
>>>>>>>>>> from a securityext code browsing I see that there is a dependence
>>>>>>>>>> from
>>>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>>>
>>>>>>>>>> Party:
>>>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person,
>>>>>>>>>> PartyRole,
>>>>>>>>>> PartyContactMech entities
>>>>>>>>>>  -> Could be moved to Party?
>>>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>>>
>>>>>>>>>> Product:
>>>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to
>>>>>>>>>> be
>>>>>>>>>> used for a ProductStore. The password email should be a core
>>>>>>>>>> feature
>>>>>>>>>> not used for ProductStores only.
>>>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>>>> level part (dedicated for a ProductStore) implemented in the
>>>>>>>>>> Product
>>>>>>>>>> component?
>>>>>>>>>>
>>>>>>>>>> Ecommerce:
>>>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->
>>>>>>>>>> Since
>>>>>>>>>> the email password should not only be an ecommerce feature this
>>>>>>>>>> should
>>>>>>>>>> be moved to Common.
>>>>>>>>>>
>>>>>>>>>> Should we try to resolve these dependences and then merge to
>>>>>>>>>> security
>>>>>>>>>> in the framework?
>>>>>>>>>>
>>>>>>>>>> -Bruno
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>> I guess the first thing we need to understand is why it exists in
>>>>>>>>>>> the
>>>>>>>>>>> first
>>>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>>>> components
>>>>>>>>>>> that
>>>>>>>>>>> prevent it from being in the framework (even if perhaps some of
>>>>>>>>>>> the
>>>>>>>>>>> logic
>>>>>>>>>>> could be moved).
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> HotWax Media
>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>
>>>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> the securityext component is actually located in the application
>>>>>>>>>>>> folder.
>>>>>>>>>>>> It implements the sending of the password remainder, password
>>>>>>>>>>>> updated
>>>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>>>> framework-only release also.
>>>>>>>>>>>>
>>>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>>>> At least the labels used from ecommerce needs to be changed and
>>>>>>>>>>>> some
>>>>>>>>>>>> store dependencies also.
>>>>>>>>>>>>
>>>>>>>>>>>> -Bruno
> 

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Adrian,
I agree that this can be done in an application using the framework
but this application should be located in the framework folder like
the webtools application.

-Bruno

2009/12/30 Adrian Crum <ad...@hlmksw.com>:
> All of the things you are describing could be done by an application
> developer that is using the framework.
>
> It would be wise to draw a very distinct and strict line between
> framework-level functionality and application-level functionality.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> Then we should have a setPrimaryEmailAddress service defined in the
>> framework (that sets the userLogin.email field) and overridden in the
>> Party application that sets/create the propert PArty/ContactMech.
>>
>> Does this make sense?
>>
>> -Bruno
>>
>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>
>>> Adrian,
>>> the getPrimaryEmailAddress defined in the framework could return the
>>> email field stored in the userLogin entity and when it is override by
>>> the Party application can retrieve the address from the
>>> userlLogin->Party->ContactMech chain.
>>>
>>> In this way we should get it working in the framawork-only also.
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>
>>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>>> does not let the forgotPassword feature work in the framework-only
>>>> installation (no party).
>>>>
>>>> -Bruno
>>>>
>>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>>
>>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>>> framework and returns nothing. The Party application can override the
>>>>> service to return the primary email address, if it exists.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Bruno Busco wrote:
>>>>>>
>>>>>> One thing we need in the framework is the possibility to create a
>>>>>> userLogin with an associated email address and have the possibility to
>>>>>> have the password emailed if forgotten.
>>>>>> This is actually done in
>>>>>>   public static String emailPassword(HttpServletRequest request,
>>>>>> HttpServletResponse response) {
>>>>>> that is located in LoginEvents.java in securityext.
>>>>>>
>>>>>> To get the email address, emailPassword(...) checks if the userLoginId
>>>>>> exists, then find the related party, then find a related ContactMech
>>>>>> with PRIMARY_MAIL purpose.
>>>>>> To get the email body and other details, emailPassword(...) starts
>>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>>
>>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>>> service needs to be in applications/securityext and cannot be
>>>>>> available in a framework-only distribution.
>>>>>>
>>>>>> Now,
>>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>>> not the right implementation for the backoffice (and thus for the
>>>>>> framework-only).
>>>>>>
>>>>>> I propose to do the following:
>>>>>> 1) Put an email address in the userLogin entity. This would be used to
>>>>>> retrieve the password.
>>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>>> common component (renaming it simply "EmailSetting") and transform the
>>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>>>>> EmailSetting.
>>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>>> that does things differently: using the email address in the userLogin
>>>>>> entity and retrieving the email settings accessing to the EmailSetting
>>>>>> entity.
>>>>>>
>>>>>> What do you think about?
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> Hi Bruno,
>>>>>>>
>>>>>>> The whole point of the securityext component is to allow portions of
>>>>>>> security related functionality to depend on the application
>>>>>>> components, I
>>>>>>> believe this was done as part of the effort to isolate the framework
>>>>>>> from
>>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>>> portions
>>>>>>> of securityext back to the framework when there is no dependency on
>>>>>>> the
>>>>>>> application code but I don't necessarily think we should have a goal
>>>>>>> of
>>>>>>> removing the securityext component altogether.
>>>>>>>
>>>>>>> It wouldn't be possible to remove securityext without either removing
>>>>>>> functionality or otherwise transferring logic that is traditionally
>>>>>>> in
>>>>>>> the
>>>>>>> application domain back to the framework.  The more that we look at
>>>>>>> doing
>>>>>>> the latter the more we need to consider exactly what the needs are
>>>>>>> that
>>>>>>> we
>>>>>>> want a framework only installation to fulfill.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>>
>>>>>>>> Hi David, devs,
>>>>>>>> I searched the SVN logs to look for a reason for those general
>>>>>>>> purpose
>>>>>>>> login and password stuff being in the application and not in the
>>>>>>>> framework.
>>>>>>>> I found they are there since the incubator time.
>>>>>>>>
>>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>>> security component in the framework. I would like to try to do it,
>>>>>>>> but
>>>>>>>> please, if you see something blocking this or something that should
>>>>>>>> be
>>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>>>
>>>>>>>>> Scott,
>>>>>>>>> from a securityext code browsing I see that there is a dependence
>>>>>>>>> from
>>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>>
>>>>>>>>> Party:
>>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person,
>>>>>>>>> PartyRole,
>>>>>>>>> PartyContactMech entities
>>>>>>>>>  -> Could be moved to Party?
>>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>>
>>>>>>>>> Product:
>>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to
>>>>>>>>> be
>>>>>>>>> used for a ProductStore. The password email should be a core
>>>>>>>>> feature
>>>>>>>>> not used for ProductStores only.
>>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>>> level part (dedicated for a ProductStore) implemented in the
>>>>>>>>> Product
>>>>>>>>> component?
>>>>>>>>>
>>>>>>>>> Ecommerce:
>>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->
>>>>>>>>> Since
>>>>>>>>> the email password should not only be an ecommerce feature this
>>>>>>>>> should
>>>>>>>>> be moved to Common.
>>>>>>>>>
>>>>>>>>> Should we try to resolve these dependences and then merge to
>>>>>>>>> security
>>>>>>>>> in the framework?
>>>>>>>>>
>>>>>>>>> -Bruno
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>> I guess the first thing we need to understand is why it exists in
>>>>>>>>>> the
>>>>>>>>>> first
>>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>>> components
>>>>>>>>>> that
>>>>>>>>>> prevent it from being in the framework (even if perhaps some of
>>>>>>>>>> the
>>>>>>>>>> logic
>>>>>>>>>> could be moved).
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> HotWax Media
>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>
>>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> the securityext component is actually located in the application
>>>>>>>>>>> folder.
>>>>>>>>>>> It implements the sending of the password remainder, password
>>>>>>>>>>> updated
>>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>>> framework-only release also.
>>>>>>>>>>>
>>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>>> At least the labels used from ecommerce needs to be changed and
>>>>>>>>>>> some
>>>>>>>>>>> store dependencies also.
>>>>>>>>>>>
>>>>>>>>>>> -Bruno
>>
>

Re: Moving securityext to the framework

[Adrian Crum <ad...@hlmksw.com>]

I would recommend changing #6 to:

#6 users can change their password

and then drop 7 through 9.

But that's just my opinion.

-Adrian

Bruno Busco wrote:
> OK,
> back to requirements.
> 
> I tryed to write down a list of requirements here:
> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
> 
> Could we have a discussion and possibly change them as and refine them
> as required?
> 
> -Bruno
> 
> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>> All of the things you are describing could be done by an application
>> developer that is using the framework.
>>
>> It would be wise to draw a very distinct and strict line between
>> framework-level functionality and application-level functionality.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>> Then we should have a setPrimaryEmailAddress service defined in the
>>> framework (that sets the userLogin.email field) and overridden in the
>>> Party application that sets/create the propert PArty/ContactMech.
>>>
>>> Does this make sense?
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>> Adrian,
>>>> the getPrimaryEmailAddress defined in the framework could return the
>>>> email field stored in the userLogin entity and when it is override by
>>>> the Party application can retrieve the address from the
>>>> userlLogin->Party->ContactMech chain.
>>>>
>>>> In this way we should get it working in the framawork-only also.
>>>>
>>>> -Bruno
>>>>
>>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>>>> does not let the forgotPassword feature work in the framework-only
>>>>> installation (no party).
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>>>> framework and returns nothing. The Party application can override the
>>>>>> service to return the primary email address, if it exists.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> Bruno Busco wrote:
>>>>>>> One thing we need in the framework is the possibility to create a
>>>>>>> userLogin with an associated email address and have the possibility to
>>>>>>> have the password emailed if forgotten.
>>>>>>> This is actually done in
>>>>>>>   public static String emailPassword(HttpServletRequest request,
>>>>>>> HttpServletResponse response) {
>>>>>>> that is located in LoginEvents.java in securityext.
>>>>>>>
>>>>>>> To get the email address, emailPassword(...) checks if the userLoginId
>>>>>>> exists, then find the related party, then find a related ContactMech
>>>>>>> with PRIMARY_MAIL purpose.
>>>>>>> To get the email body and other details, emailPassword(...) starts
>>>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>>>
>>>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>>>> service needs to be in applications/securityext and cannot be
>>>>>>> available in a framework-only distribution.
>>>>>>>
>>>>>>> Now,
>>>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>>>> not the right implementation for the backoffice (and thus for the
>>>>>>> framework-only).
>>>>>>>
>>>>>>> I propose to do the following:
>>>>>>> 1) Put an email address in the userLogin entity. This would be used to
>>>>>>> retrieve the password.
>>>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>>>> common component (renaming it simply "EmailSetting") and transform the
>>>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>>>>>> EmailSetting.
>>>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>>>> that does things differently: using the email address in the userLogin
>>>>>>> entity and retrieving the email settings accessing to the EmailSetting
>>>>>>> entity.
>>>>>>>
>>>>>>> What do you think about?
>>>>>>>
>>>>>>> -Bruno
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>> Hi Bruno,
>>>>>>>>
>>>>>>>> The whole point of the securityext component is to allow portions of
>>>>>>>> security related functionality to depend on the application
>>>>>>>> components, I
>>>>>>>> believe this was done as part of the effort to isolate the framework
>>>>>>>> from
>>>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>>>> portions
>>>>>>>> of securityext back to the framework when there is no dependency on
>>>>>>>> the
>>>>>>>> application code but I don't necessarily think we should have a goal
>>>>>>>> of
>>>>>>>> removing the securityext component altogether.
>>>>>>>>
>>>>>>>> It wouldn't be possible to remove securityext without either removing
>>>>>>>> functionality or otherwise transferring logic that is traditionally
>>>>>>>> in
>>>>>>>> the
>>>>>>>> application domain back to the framework.  The more that we look at
>>>>>>>> doing
>>>>>>>> the latter the more we need to consider exactly what the needs are
>>>>>>>> that
>>>>>>>> we
>>>>>>>> want a framework only installation to fulfill.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>
>>>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>>>
>>>>>>>>> Hi David, devs,
>>>>>>>>> I searched the SVN logs to look for a reason for those general
>>>>>>>>> purpose
>>>>>>>>> login and password stuff being in the application and not in the
>>>>>>>>> framework.
>>>>>>>>> I found they are there since the incubator time.
>>>>>>>>>
>>>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>>>> security component in the framework. I would like to try to do it,
>>>>>>>>> but
>>>>>>>>> please, if you see something blocking this or something that should
>>>>>>>>> be
>>>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> -Bruno
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>>>> Scott,
>>>>>>>>>> from a securityext code browsing I see that there is a dependence
>>>>>>>>>> from
>>>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>>>
>>>>>>>>>> Party:
>>>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person,
>>>>>>>>>> PartyRole,
>>>>>>>>>> PartyContactMech entities
>>>>>>>>>>  -> Could be moved to Party?
>>>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>>>
>>>>>>>>>> Product:
>>>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to
>>>>>>>>>> be
>>>>>>>>>> used for a ProductStore. The password email should be a core
>>>>>>>>>> feature
>>>>>>>>>> not used for ProductStores only.
>>>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>>>> level part (dedicated for a ProductStore) implemented in the
>>>>>>>>>> Product
>>>>>>>>>> component?
>>>>>>>>>>
>>>>>>>>>> Ecommerce:
>>>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->
>>>>>>>>>> Since
>>>>>>>>>> the email password should not only be an ecommerce feature this
>>>>>>>>>> should
>>>>>>>>>> be moved to Common.
>>>>>>>>>>
>>>>>>>>>> Should we try to resolve these dependences and then merge to
>>>>>>>>>> security
>>>>>>>>>> in the framework?
>>>>>>>>>>
>>>>>>>>>> -Bruno
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>> I guess the first thing we need to understand is why it exists in
>>>>>>>>>>> the
>>>>>>>>>>> first
>>>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>>>> components
>>>>>>>>>>> that
>>>>>>>>>>> prevent it from being in the framework (even if perhaps some of
>>>>>>>>>>> the
>>>>>>>>>>> logic
>>>>>>>>>>> could be moved).
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> HotWax Media
>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>
>>>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> the securityext component is actually located in the application
>>>>>>>>>>>> folder.
>>>>>>>>>>>> It implements the sending of the password remainder, password
>>>>>>>>>>>> updated
>>>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>>>> framework-only release also.
>>>>>>>>>>>>
>>>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>>>> At least the labels used from ecommerce needs to be changed and
>>>>>>>>>>>> some
>>>>>>>>>>>> store dependencies also.
>>>>>>>>>>>>
>>>>>>>>>>>> -Bruno
> 

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

OK,
back to requirements.

I tryed to write down a list of requirements here:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution

Could we have a discussion and possibly change them as and refine them
as required?

-Bruno

2009/12/30 Adrian Crum <ad...@hlmksw.com>:
> All of the things you are describing could be done by an application
> developer that is using the framework.
>
> It would be wise to draw a very distinct and strict line between
> framework-level functionality and application-level functionality.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> Then we should have a setPrimaryEmailAddress service defined in the
>> framework (that sets the userLogin.email field) and overridden in the
>> Party application that sets/create the propert PArty/ContactMech.
>>
>> Does this make sense?
>>
>> -Bruno
>>
>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>
>>> Adrian,
>>> the getPrimaryEmailAddress defined in the framework could return the
>>> email field stored in the userLogin entity and when it is override by
>>> the Party application can retrieve the address from the
>>> userlLogin->Party->ContactMech chain.
>>>
>>> In this way we should get it working in the framawork-only also.
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>>>
>>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>>> does not let the forgotPassword feature work in the framework-only
>>>> installation (no party).
>>>>
>>>> -Bruno
>>>>
>>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>>>
>>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>>> framework and returns nothing. The Party application can override the
>>>>> service to return the primary email address, if it exists.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Bruno Busco wrote:
>>>>>>
>>>>>> One thing we need in the framework is the possibility to create a
>>>>>> userLogin with an associated email address and have the possibility to
>>>>>> have the password emailed if forgotten.
>>>>>> This is actually done in
>>>>>>   public static String emailPassword(HttpServletRequest request,
>>>>>> HttpServletResponse response) {
>>>>>> that is located in LoginEvents.java in securityext.
>>>>>>
>>>>>> To get the email address, emailPassword(...) checks if the userLoginId
>>>>>> exists, then find the related party, then find a related ContactMech
>>>>>> with PRIMARY_MAIL purpose.
>>>>>> To get the email body and other details, emailPassword(...) starts
>>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>>
>>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>>> service needs to be in applications/securityext and cannot be
>>>>>> available in a framework-only distribution.
>>>>>>
>>>>>> Now,
>>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>>> not the right implementation for the backoffice (and thus for the
>>>>>> framework-only).
>>>>>>
>>>>>> I propose to do the following:
>>>>>> 1) Put an email address in the userLogin entity. This would be used to
>>>>>> retrieve the password.
>>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>>> common component (renaming it simply "EmailSetting") and transform the
>>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>>>>> EmailSetting.
>>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>>> that does things differently: using the email address in the userLogin
>>>>>> entity and retrieving the email settings accessing to the EmailSetting
>>>>>> entity.
>>>>>>
>>>>>> What do you think about?
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> Hi Bruno,
>>>>>>>
>>>>>>> The whole point of the securityext component is to allow portions of
>>>>>>> security related functionality to depend on the application
>>>>>>> components, I
>>>>>>> believe this was done as part of the effort to isolate the framework
>>>>>>> from
>>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>>> portions
>>>>>>> of securityext back to the framework when there is no dependency on
>>>>>>> the
>>>>>>> application code but I don't necessarily think we should have a goal
>>>>>>> of
>>>>>>> removing the securityext component altogether.
>>>>>>>
>>>>>>> It wouldn't be possible to remove securityext without either removing
>>>>>>> functionality or otherwise transferring logic that is traditionally
>>>>>>> in
>>>>>>> the
>>>>>>> application domain back to the framework.  The more that we look at
>>>>>>> doing
>>>>>>> the latter the more we need to consider exactly what the needs are
>>>>>>> that
>>>>>>> we
>>>>>>> want a framework only installation to fulfill.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>>
>>>>>>>> Hi David, devs,
>>>>>>>> I searched the SVN logs to look for a reason for those general
>>>>>>>> purpose
>>>>>>>> login and password stuff being in the application and not in the
>>>>>>>> framework.
>>>>>>>> I found they are there since the incubator time.
>>>>>>>>
>>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>>> security component in the framework. I would like to try to do it,
>>>>>>>> but
>>>>>>>> please, if you see something blocking this or something that should
>>>>>>>> be
>>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>>>
>>>>>>>>> Scott,
>>>>>>>>> from a securityext code browsing I see that there is a dependence
>>>>>>>>> from
>>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>>
>>>>>>>>> Party:
>>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person,
>>>>>>>>> PartyRole,
>>>>>>>>> PartyContactMech entities
>>>>>>>>>  -> Could be moved to Party?
>>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>>
>>>>>>>>> Product:
>>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to
>>>>>>>>> be
>>>>>>>>> used for a ProductStore. The password email should be a core
>>>>>>>>> feature
>>>>>>>>> not used for ProductStores only.
>>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>>> level part (dedicated for a ProductStore) implemented in the
>>>>>>>>> Product
>>>>>>>>> component?
>>>>>>>>>
>>>>>>>>> Ecommerce:
>>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->
>>>>>>>>> Since
>>>>>>>>> the email password should not only be an ecommerce feature this
>>>>>>>>> should
>>>>>>>>> be moved to Common.
>>>>>>>>>
>>>>>>>>> Should we try to resolve these dependences and then merge to
>>>>>>>>> security
>>>>>>>>> in the framework?
>>>>>>>>>
>>>>>>>>> -Bruno
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>> I guess the first thing we need to understand is why it exists in
>>>>>>>>>> the
>>>>>>>>>> first
>>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>>> components
>>>>>>>>>> that
>>>>>>>>>> prevent it from being in the framework (even if perhaps some of
>>>>>>>>>> the
>>>>>>>>>> logic
>>>>>>>>>> could be moved).
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> HotWax Media
>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>
>>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> the securityext component is actually located in the application
>>>>>>>>>>> folder.
>>>>>>>>>>> It implements the sending of the password remainder, password
>>>>>>>>>>> updated
>>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>>> framework-only release also.
>>>>>>>>>>>
>>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>>> At least the labels used from ecommerce needs to be changed and
>>>>>>>>>>> some
>>>>>>>>>>> store dependencies also.
>>>>>>>>>>>
>>>>>>>>>>> -Bruno
>>
>

Re: Moving securityext to the framework

[Adrian Crum <ad...@hlmksw.com>]

All of the things you are describing could be done by an application 
developer that is using the framework.

It would be wise to draw a very distinct and strict line between 
framework-level functionality and application-level functionality.

-Adrian

Bruno Busco wrote:
> Then we should have a setPrimaryEmailAddress service defined in the
> framework (that sets the userLogin.email field) and overridden in the
> Party application that sets/create the propert PArty/ContactMech.
> 
> Does this make sense?
> 
> -Bruno
> 
> 2009/12/30 Bruno Busco <br...@gmail.com>:
>> Adrian,
>> the getPrimaryEmailAddress defined in the framework could return the
>> email field stored in the userLogin entity and when it is override by
>> the Party application can retrieve the address from the
>> userlLogin->Party->ContactMech chain.
>>
>> In this way we should get it working in the framawork-only also.
>>
>> -Bruno
>>
>> 2009/12/30 Bruno Busco <br...@gmail.com>:
>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>> does not let the forgotPassword feature work in the framework-only
>>> installation (no party).
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>>> framework and returns nothing. The Party application can override the
>>>> service to return the primary email address, if it exists.
>>>>
>>>> -Adrian
>>>>
>>>> Bruno Busco wrote:
>>>>> One thing we need in the framework is the possibility to create a
>>>>> userLogin with an associated email address and have the possibility to
>>>>> have the password emailed if forgotten.
>>>>> This is actually done in
>>>>>    public static String emailPassword(HttpServletRequest request,
>>>>> HttpServletResponse response) {
>>>>> that is located in LoginEvents.java in securityext.
>>>>>
>>>>> To get the email address, emailPassword(...) checks if the userLoginId
>>>>> exists, then find the related party, then find a related ContactMech
>>>>> with PRIMARY_MAIL purpose.
>>>>> To get the email body and other details, emailPassword(...) starts
>>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>>
>>>>> So, being dependent from both party and product, emailPassword(...)
>>>>> service needs to be in applications/securityext and cannot be
>>>>> available in a framework-only distribution.
>>>>>
>>>>> Now,
>>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>>> ecommerce application (that depends on party and product) but IMO is
>>>>> not the right implementation for the backoffice (and thus for the
>>>>> framework-only).
>>>>>
>>>>> I propose to do the following:
>>>>> 1) Put an email address in the userLogin entity. This would be used to
>>>>> retrieve the password.
>>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>>> common component (renaming it simply "EmailSetting") and transform the
>>>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>>>> EmailSetting.
>>>>> 3) Define a new emailPassword(...) service in the common component
>>>>> that does things differently: using the email address in the userLogin
>>>>> entity and retrieving the email settings accessing to the EmailSetting
>>>>> entity.
>>>>>
>>>>> What do you think about?
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>>
>>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>> Hi Bruno,
>>>>>>
>>>>>> The whole point of the securityext component is to allow portions of
>>>>>> security related functionality to depend on the application components, I
>>>>>> believe this was done as part of the effort to isolate the framework from
>>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>>> portions
>>>>>> of securityext back to the framework when there is no dependency on the
>>>>>> application code but I don't necessarily think we should have a goal of
>>>>>> removing the securityext component altogether.
>>>>>>
>>>>>> It wouldn't be possible to remove securityext without either removing
>>>>>> functionality or otherwise transferring logic that is traditionally in
>>>>>> the
>>>>>> application domain back to the framework.  The more that we look at doing
>>>>>> the latter the more we need to consider exactly what the needs are that
>>>>>> we
>>>>>> want a framework only installation to fulfill.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>>
>>>>>>> Hi David, devs,
>>>>>>> I searched the SVN logs to look for a reason for those general purpose
>>>>>>> login and password stuff being in the application and not in the
>>>>>>> framework.
>>>>>>> I found they are there since the incubator time.
>>>>>>>
>>>>>>> What I think should be done is to merge the securityext to the
>>>>>>> security component in the framework. I would like to try to do it, but
>>>>>>> please, if you see something blocking this or something that should be
>>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> -Bruno
>>>>>>>
>>>>>>>
>>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>> Scott,
>>>>>>>> from a securityext code browsing I see that there is a dependence from
>>>>>>>> Party, Product and Ecommerce.
>>>>>>>>
>>>>>>>> Party:
>>>>>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>>>>>> PartyContactMech entities
>>>>>>>>  -> Could be moved to Party?
>>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>>> always update a password, even not knowing the current password.
>>>>>>>>  -> An admin permission should be checked here.
>>>>>>>>
>>>>>>>> Product:
>>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>>>>>> used for a ProductStore. The password email should be a core feature
>>>>>>>> not used for ProductStores only.
>>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>>>>>> component?
>>>>>>>>
>>>>>>>> Ecommerce:
>>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>>>>>> the email password should not only be an ecommerce feature this should
>>>>>>>> be moved to Common.
>>>>>>>>
>>>>>>>> Should we try to resolve these dependences and then merge to security
>>>>>>>> in the framework?
>>>>>>>>
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>> I guess the first thing we need to understand is why it exists in the
>>>>>>>>> first
>>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>>> components
>>>>>>>>> that
>>>>>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>>>>>> logic
>>>>>>>>> could be moved).
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> HotWax Media
>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>
>>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> the securityext component is actually located in the application
>>>>>>>>>> folder.
>>>>>>>>>> It implements the sending of the password remainder, password updated
>>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>>> framework-only release also.
>>>>>>>>>>
>>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>>>>>> store dependencies also.
>>>>>>>>>>
>>>>>>>>>> -Bruno
> 

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.

Does this make sense?

-Bruno

2009/12/30 Bruno Busco <br...@gmail.com>:
> Adrian,
> the getPrimaryEmailAddress defined in the framework could return the
> email field stored in the userLogin entity and when it is override by
> the Party application can retrieve the address from the
> userlLogin->Party->ContactMech chain.
>
> In this way we should get it working in the framawork-only also.
>
> -Bruno
>
> 2009/12/30 Bruno Busco <br...@gmail.com>:
>> Having the getPrimaryEmailAddress in the framework returning nothing
>> does not let the forgotPassword feature work in the framework-only
>> installation (no party).
>>
>> -Bruno
>>
>> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>> framework and returns nothing. The Party application can override the
>>> service to return the primary email address, if it exists.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
>>>>
>>>> One thing we need in the framework is the possibility to create a
>>>> userLogin with an associated email address and have the possibility to
>>>> have the password emailed if forgotten.
>>>> This is actually done in
>>>>    public static String emailPassword(HttpServletRequest request,
>>>> HttpServletResponse response) {
>>>> that is located in LoginEvents.java in securityext.
>>>>
>>>> To get the email address, emailPassword(...) checks if the userLoginId
>>>> exists, then find the related party, then find a related ContactMech
>>>> with PRIMARY_MAIL purpose.
>>>> To get the email body and other details, emailPassword(...) starts
>>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>>
>>>> So, being dependent from both party and product, emailPassword(...)
>>>> service needs to be in applications/securityext and cannot be
>>>> available in a framework-only distribution.
>>>>
>>>> Now,
>>>> the emailPassword(...) sevice in the securityext is OK for the
>>>> ecommerce application (that depends on party and product) but IMO is
>>>> not the right implementation for the backoffice (and thus for the
>>>> framework-only).
>>>>
>>>> I propose to do the following:
>>>> 1) Put an email address in the userLogin entity. This would be used to
>>>> retrieve the password.
>>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>>> common component (renaming it simply "EmailSetting") and transform the
>>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>>> EmailSetting.
>>>> 3) Define a new emailPassword(...) service in the common component
>>>> that does things differently: using the email address in the userLogin
>>>> entity and retrieving the email settings accessing to the EmailSetting
>>>> entity.
>>>>
>>>> What do you think about?
>>>>
>>>> -Bruno
>>>>
>>>>
>>>>
>>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>
>>>>> Hi Bruno,
>>>>>
>>>>> The whole point of the securityext component is to allow portions of
>>>>> security related functionality to depend on the application components, I
>>>>> believe this was done as part of the effort to isolate the framework from
>>>>> any application dependencies.  I think it is perfectly fine to move
>>>>> portions
>>>>> of securityext back to the framework when there is no dependency on the
>>>>> application code but I don't necessarily think we should have a goal of
>>>>> removing the securityext component altogether.
>>>>>
>>>>> It wouldn't be possible to remove securityext without either removing
>>>>> functionality or otherwise transferring logic that is traditionally in
>>>>> the
>>>>> application domain back to the framework.  The more that we look at doing
>>>>> the latter the more we need to consider exactly what the needs are that
>>>>> we
>>>>> want a framework only installation to fulfill.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>>
>>>>>> Hi David, devs,
>>>>>> I searched the SVN logs to look for a reason for those general purpose
>>>>>> login and password stuff being in the application and not in the
>>>>>> framework.
>>>>>> I found they are there since the incubator time.
>>>>>>
>>>>>> What I think should be done is to merge the securityext to the
>>>>>> security component in the framework. I would like to try to do it, but
>>>>>> please, if you see something blocking this or something that should be
>>>>>> done first, or even a reason for not to do this, please advice.
>>>>>>
>>>>>> Thank you,
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>>
>>>>>>> Scott,
>>>>>>> from a securityext code browsing I see that there is a dependence from
>>>>>>> Party, Product and Ecommerce.
>>>>>>>
>>>>>>> Party:
>>>>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>>>>> PartyContactMech entities
>>>>>>>  -> Could be moved to Party?
>>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>>> always update a password, even not knowing the current password.
>>>>>>>  -> An admin permission should be checked here.
>>>>>>>
>>>>>>> Product:
>>>>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>>>>> used for a ProductStore. The password email should be a core feature
>>>>>>> not used for ProductStores only.
>>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>>>>> component?
>>>>>>>
>>>>>>> Ecommerce:
>>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>>>>> the email password should not only be an ecommerce feature this should
>>>>>>> be moved to Common.
>>>>>>>
>>>>>>> Should we try to resolve these dependences and then merge to security
>>>>>>> in the framework?
>>>>>>>
>>>>>>> -Bruno
>>>>>>>
>>>>>>>
>>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>> I guess the first thing we need to understand is why it exists in the
>>>>>>>> first
>>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>>> components
>>>>>>>> that
>>>>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>>>>> logic
>>>>>>>> could be moved).
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>
>>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> the securityext component is actually located in the application
>>>>>>>>> folder.
>>>>>>>>> It implements the sending of the password remainder, password updated
>>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>>> framework-only release also.
>>>>>>>>>
>>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>>>>> store dependencies also.
>>>>>>>>>
>>>>>>>>> -Bruno
>>>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Adrian,
the getPrimaryEmailAddress defined in the framework could return the
email field stored in the userLogin entity and when it is override by
the Party application can retrieve the address from the
userlLogin->Party->ContactMech chain.

In this way we should get it working in the framawork-only also.

-Bruno

2009/12/30 Bruno Busco <br...@gmail.com>:
> Having the getPrimaryEmailAddress in the framework returning nothing
> does not let the forgotPassword feature work in the framework-only
> installation (no party).
>
> -Bruno
>
> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>> Or have a service - getPrimaryEmailAddress - that is defined in the
>> framework and returns nothing. The Party application can override the
>> service to return the primary email address, if it exists.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>>
>>> One thing we need in the framework is the possibility to create a
>>> userLogin with an associated email address and have the possibility to
>>> have the password emailed if forgotten.
>>> This is actually done in
>>>    public static String emailPassword(HttpServletRequest request,
>>> HttpServletResponse response) {
>>> that is located in LoginEvents.java in securityext.
>>>
>>> To get the email address, emailPassword(...) checks if the userLoginId
>>> exists, then find the related party, then find a related ContactMech
>>> with PRIMARY_MAIL purpose.
>>> To get the email body and other details, emailPassword(...) starts
>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>
>>> So, being dependent from both party and product, emailPassword(...)
>>> service needs to be in applications/securityext and cannot be
>>> available in a framework-only distribution.
>>>
>>> Now,
>>> the emailPassword(...) sevice in the securityext is OK for the
>>> ecommerce application (that depends on party and product) but IMO is
>>> not the right implementation for the backoffice (and thus for the
>>> framework-only).
>>>
>>> I propose to do the following:
>>> 1) Put an email address in the userLogin entity. This would be used to
>>> retrieve the password.
>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>> common component (renaming it simply "EmailSetting") and transform the
>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>> EmailSetting.
>>> 3) Define a new emailPassword(...) service in the common component
>>> that does things differently: using the email address in the userLogin
>>> entity and retrieving the email settings accessing to the EmailSetting
>>> entity.
>>>
>>> What do you think about?
>>>
>>> -Bruno
>>>
>>>
>>>
>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>>
>>>> Hi Bruno,
>>>>
>>>> The whole point of the securityext component is to allow portions of
>>>> security related functionality to depend on the application components, I
>>>> believe this was done as part of the effort to isolate the framework from
>>>> any application dependencies.  I think it is perfectly fine to move
>>>> portions
>>>> of securityext back to the framework when there is no dependency on the
>>>> application code but I don't necessarily think we should have a goal of
>>>> removing the securityext component altogether.
>>>>
>>>> It wouldn't be possible to remove securityext without either removing
>>>> functionality or otherwise transferring logic that is traditionally in
>>>> the
>>>> application domain back to the framework.  The more that we look at doing
>>>> the latter the more we need to consider exactly what the needs are that
>>>> we
>>>> want a framework only installation to fulfill.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>
>>>>> Hi David, devs,
>>>>> I searched the SVN logs to look for a reason for those general purpose
>>>>> login and password stuff being in the application and not in the
>>>>> framework.
>>>>> I found they are there since the incubator time.
>>>>>
>>>>> What I think should be done is to merge the securityext to the
>>>>> security component in the framework. I would like to try to do it, but
>>>>> please, if you see something blocking this or something that should be
>>>>> done first, or even a reason for not to do this, please advice.
>>>>>
>>>>> Thank you,
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>>
>>>>>> Scott,
>>>>>> from a securityext code browsing I see that there is a dependence from
>>>>>> Party, Product and Ecommerce.
>>>>>>
>>>>>> Party:
>>>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>>>> PartyContactMech entities
>>>>>>  -> Could be moved to Party?
>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>> always update a password, even not knowing the current password.
>>>>>>  -> An admin permission should be checked here.
>>>>>>
>>>>>> Product:
>>>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>>>> used for a ProductStore. The password email should be a core feature
>>>>>> not used for ProductStores only.
>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>>>> component?
>>>>>>
>>>>>> Ecommerce:
>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>>>> the email password should not only be an ecommerce feature this should
>>>>>> be moved to Common.
>>>>>>
>>>>>> Should we try to resolve these dependences and then merge to security
>>>>>> in the framework?
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> I guess the first thing we need to understand is why it exists in the
>>>>>>> first
>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>> components
>>>>>>> that
>>>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>>>> logic
>>>>>>> could be moved).
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> the securityext component is actually located in the application
>>>>>>>> folder.
>>>>>>>> It implements the sending of the password remainder, password updated
>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>> framework-only release also.
>>>>>>>>
>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>>>> store dependencies also.
>>>>>>>>
>>>>>>>> -Bruno
>>>>>>>
>>>>
>>>
>>
>

Re: Moving securityext to the framework

[Adrian Crum <ad...@hlmksw.com>]

Like Scott said, that feature is appropriate for applications, not for 
the framework. So we can create framework services for the feature that 
do nothing - which can then be overridden by applications, or we can 
remove the feature from the framework and implement it entirely in the 
Party application (or some other application).

-Adrian

Bruno Busco wrote:
> Having the getPrimaryEmailAddress in the framework returning nothing
> does not let the forgotPassword feature work in the framework-only
> installation (no party).
> 
> -Bruno
> 
> 2009/12/30 Adrian Crum <ad...@hlmksw.com>:
>> Or have a service - getPrimaryEmailAddress - that is defined in the
>> framework and returns nothing. The Party application can override the
>> service to return the primary email address, if it exists.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>> One thing we need in the framework is the possibility to create a
>>> userLogin with an associated email address and have the possibility to
>>> have the password emailed if forgotten.
>>> This is actually done in
>>>    public static String emailPassword(HttpServletRequest request,
>>> HttpServletResponse response) {
>>> that is located in LoginEvents.java in securityext.
>>>
>>> To get the email address, emailPassword(...) checks if the userLoginId
>>> exists, then find the related party, then find a related ContactMech
>>> with PRIMARY_MAIL purpose.
>>> To get the email body and other details, emailPassword(...) starts
>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>
>>> So, being dependent from both party and product, emailPassword(...)
>>> service needs to be in applications/securityext and cannot be
>>> available in a framework-only distribution.
>>>
>>> Now,
>>> the emailPassword(...) sevice in the securityext is OK for the
>>> ecommerce application (that depends on party and product) but IMO is
>>> not the right implementation for the backoffice (and thus for the
>>> framework-only).
>>>
>>> I propose to do the following:
>>> 1) Put an email address in the userLogin entity. This would be used to
>>> retrieve the password.
>>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>>> common component (renaming it simply "EmailSetting") and transform the
>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>> EmailSetting.
>>> 3) Define a new emailPassword(...) service in the common component
>>> that does things differently: using the email address in the userLogin
>>> entity and retrieving the email settings accessing to the EmailSetting
>>> entity.
>>>
>>> What do you think about?
>>>
>>> -Bruno
>>>
>>>
>>>
>>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>> Hi Bruno,
>>>>
>>>> The whole point of the securityext component is to allow portions of
>>>> security related functionality to depend on the application components, I
>>>> believe this was done as part of the effort to isolate the framework from
>>>> any application dependencies.  I think it is perfectly fine to move
>>>> portions
>>>> of securityext back to the framework when there is no dependency on the
>>>> application code but I don't necessarily think we should have a goal of
>>>> removing the securityext component altogether.
>>>>
>>>> It wouldn't be possible to remove securityext without either removing
>>>> functionality or otherwise transferring logic that is traditionally in
>>>> the
>>>> application domain back to the framework.  The more that we look at doing
>>>> the latter the more we need to consider exactly what the needs are that
>>>> we
>>>> want a framework only installation to fulfill.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>>
>>>>> Hi David, devs,
>>>>> I searched the SVN logs to look for a reason for those general purpose
>>>>> login and password stuff being in the application and not in the
>>>>> framework.
>>>>> I found they are there since the incubator time.
>>>>>
>>>>> What I think should be done is to merge the securityext to the
>>>>> security component in the framework. I would like to try to do it, but
>>>>> please, if you see something blocking this or something that should be
>>>>> done first, or even a reason for not to do this, please advice.
>>>>>
>>>>> Thank you,
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>> Scott,
>>>>>> from a securityext code browsing I see that there is a dependence from
>>>>>> Party, Product and Ecommerce.
>>>>>>
>>>>>> Party:
>>>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>>>> PartyContactMech entities
>>>>>>  -> Could be moved to Party?
>>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>>> the updatePassword service. This is to be sure that an admin can
>>>>>> always update a password, even not knowing the current password.
>>>>>>  -> An admin permission should be checked here.
>>>>>>
>>>>>> Product:
>>>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>>>> used for a ProductStore. The password email should be a core feature
>>>>>> not used for ProductStores only.
>>>>>>  -> Could we split this method in a framework one and an higher
>>>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>>>> component?
>>>>>>
>>>>>> Ecommerce:
>>>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>>>> the email password should not only be an ecommerce feature this should
>>>>>> be moved to Common.
>>>>>>
>>>>>> Should we try to resolve these dependences and then merge to security
>>>>>> in the framework?
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>> I guess the first thing we need to understand is why it exists in the
>>>>>>> first
>>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>>> components
>>>>>>> that
>>>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>>>> logic
>>>>>>> could be moved).
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> the securityext component is actually located in the application
>>>>>>>> folder.
>>>>>>>> It implements the sending of the password remainder, password updated
>>>>>>>> services, permission groups etc. that we want available in the
>>>>>>>> framework-only release also.
>>>>>>>>
>>>>>>>> Do we agree to change it to move it over there?
>>>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>>>> store dependencies also.
>>>>>>>>
>>>>>>>> -Bruno
> 

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).

-Bruno

2009/12/30 Adrian Crum <ad...@hlmksw.com>:
> Or have a service - getPrimaryEmailAddress - that is defined in the
> framework and returns nothing. The Party application can override the
> service to return the primary email address, if it exists.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> One thing we need in the framework is the possibility to create a
>> userLogin with an associated email address and have the possibility to
>> have the password emailed if forgotten.
>> This is actually done in
>>    public static String emailPassword(HttpServletRequest request,
>> HttpServletResponse response) {
>> that is located in LoginEvents.java in securityext.
>>
>> To get the email address, emailPassword(...) checks if the userLoginId
>> exists, then find the related party, then find a related ContactMech
>> with PRIMARY_MAIL purpose.
>> To get the email body and other details, emailPassword(...) starts
>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>
>> So, being dependent from both party and product, emailPassword(...)
>> service needs to be in applications/securityext and cannot be
>> available in a framework-only distribution.
>>
>> Now,
>> the emailPassword(...) sevice in the securityext is OK for the
>> ecommerce application (that depends on party and product) but IMO is
>> not the right implementation for the backoffice (and thus for the
>> framework-only).
>>
>> I propose to do the following:
>> 1) Put an email address in the userLogin entity. This would be used to
>> retrieve the password.
>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>> common component (renaming it simply "EmailSetting") and transform the
>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>> EmailSetting.
>> 3) Define a new emailPassword(...) service in the common component
>> that does things differently: using the email address in the userLogin
>> entity and retrieving the email settings accessing to the EmailSetting
>> entity.
>>
>> What do you think about?
>>
>> -Bruno
>>
>>
>>
>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>
>>> Hi Bruno,
>>>
>>> The whole point of the securityext component is to allow portions of
>>> security related functionality to depend on the application components, I
>>> believe this was done as part of the effort to isolate the framework from
>>> any application dependencies.  I think it is perfectly fine to move
>>> portions
>>> of securityext back to the framework when there is no dependency on the
>>> application code but I don't necessarily think we should have a goal of
>>> removing the securityext component altogether.
>>>
>>> It wouldn't be possible to remove securityext without either removing
>>> functionality or otherwise transferring logic that is traditionally in
>>> the
>>> application domain back to the framework.  The more that we look at doing
>>> the latter the more we need to consider exactly what the needs are that
>>> we
>>> want a framework only installation to fulfill.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>
>>>> Hi David, devs,
>>>> I searched the SVN logs to look for a reason for those general purpose
>>>> login and password stuff being in the application and not in the
>>>> framework.
>>>> I found they are there since the incubator time.
>>>>
>>>> What I think should be done is to merge the securityext to the
>>>> security component in the framework. I would like to try to do it, but
>>>> please, if you see something blocking this or something that should be
>>>> done first, or even a reason for not to do this, please advice.
>>>>
>>>> Thank you,
>>>> -Bruno
>>>>
>>>>
>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>
>>>>> Scott,
>>>>> from a securityext code browsing I see that there is a dependence from
>>>>> Party, Product and Ecommerce.
>>>>>
>>>>> Party:
>>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>>> PartyContactMech entities
>>>>>  -> Could be moved to Party?
>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>> the updatePassword service. This is to be sure that an admin can
>>>>> always update a password, even not knowing the current password.
>>>>>  -> An admin permission should be checked here.
>>>>>
>>>>> Product:
>>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>>> used for a ProductStore. The password email should be a core feature
>>>>> not used for ProductStores only.
>>>>>  -> Could we split this method in a framework one and an higher
>>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>>> component?
>>>>>
>>>>> Ecommerce:
>>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>>> the email password should not only be an ecommerce feature this should
>>>>> be moved to Common.
>>>>>
>>>>> Should we try to resolve these dependences and then merge to security
>>>>> in the framework?
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> I guess the first thing we need to understand is why it exists in the
>>>>>> first
>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>> components
>>>>>> that
>>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>>> logic
>>>>>> could be moved).
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> the securityext component is actually located in the application
>>>>>>> folder.
>>>>>>> It implements the sending of the password remainder, password updated
>>>>>>> services, permission groups etc. that we want available in the
>>>>>>> framework-only release also.
>>>>>>>
>>>>>>> Do we agree to change it to move it over there?
>>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>>> store dependencies also.
>>>>>>>
>>>>>>> -Bruno
>>>>>>
>>>
>>
>

Re: Moving securityext to the framework

[Adrian Crum <ad...@hlmksw.com>]

Or have a service - getPrimaryEmailAddress - that is defined in the 
framework and returns nothing. The Party application can override the 
service to return the primary email address, if it exists.

-Adrian

Bruno Busco wrote:
> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility to
> have the password emailed if forgotten.
> This is actually done in
>     public static String emailPassword(HttpServletRequest request,
> HttpServletResponse response) {
> that is located in LoginEvents.java in securityext.
> 
> To get the email address, emailPassword(...) checks if the userLoginId
> exists, then find the related party, then find a related ContactMech
> with PRIMARY_MAIL purpose.
> To get the email body and other details, emailPassword(...) starts
> from a ProductStore and gets the related ProductStoreEmailSetting.
> 
> So, being dependent from both party and product, emailPassword(...)
> service needs to be in applications/securityext and cannot be
> available in a framework-only distribution.
> 
> Now,
> the emailPassword(...) sevice in the securityext is OK for the
> ecommerce application (that depends on party and product) but IMO is
> not the right implementation for the backoffice (and thus for the
> framework-only).
> 
> I propose to do the following:
> 1) Put an email address in the userLogin entity. This would be used to
> retrieve the password.
> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
> common component (renaming it simply "EmailSetting") and transform the
> actual "ProductStoreEmailSetting" into a link between ProductStore and
> EmailSetting.
> 3) Define a new emailPassword(...) service in the common component
> that does things differently: using the email address in the userLogin
> entity and retrieving the email settings accessing to the EmailSetting
> entity.
> 
> What do you think about?
> 
> -Bruno
> 
> 
> 
> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>> Hi Bruno,
>>
>> The whole point of the securityext component is to allow portions of
>> security related functionality to depend on the application components, I
>> believe this was done as part of the effort to isolate the framework from
>> any application dependencies.  I think it is perfectly fine to move portions
>> of securityext back to the framework when there is no dependency on the
>> application code but I don't necessarily think we should have a goal of
>> removing the securityext component altogether.
>>
>> It wouldn't be possible to remove securityext without either removing
>> functionality or otherwise transferring logic that is traditionally in the
>> application domain back to the framework.  The more that we look at doing
>> the latter the more we need to consider exactly what the needs are that we
>> want a framework only installation to fulfill.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>
>>> Hi David, devs,
>>> I searched the SVN logs to look for a reason for those general purpose
>>> login and password stuff being in the application and not in the
>>> framework.
>>> I found they are there since the incubator time.
>>>
>>> What I think should be done is to merge the securityext to the
>>> security component in the framework. I would like to try to do it, but
>>> please, if you see something blocking this or something that should be
>>> done first, or even a reason for not to do this, please advice.
>>>
>>> Thank you,
>>> -Bruno
>>>
>>>
>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>> Scott,
>>>> from a securityext code browsing I see that there is a dependence from
>>>> Party, Product and Ecommerce.
>>>>
>>>> Party:
>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>> PartyContactMech entities
>>>>  -> Could be moved to Party?
>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>> the updatePassword service. This is to be sure that an admin can
>>>> always update a password, even not knowing the current password.
>>>>  -> An admin permission should be checked here.
>>>>
>>>> Product:
>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>> used for a ProductStore. The password email should be a core feature
>>>> not used for ProductStores only.
>>>>  -> Could we split this method in a framework one and an higher
>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>> component?
>>>>
>>>> Ecommerce:
>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>> the email password should not only be an ecommerce feature this should
>>>> be moved to Common.
>>>>
>>>> Should we try to resolve these dependences and then merge to security
>>>> in the framework?
>>>>
>>>> -Bruno
>>>>
>>>>
>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>> I guess the first thing we need to understand is why it exists in the
>>>>> first
>>>>> place?  I'm assuming it has some dependencies on application components
>>>>> that
>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>> logic
>>>>> could be moved).
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>
>>>>>> Hi,
>>>>>> the securityext component is actually located in the application
>>>>>> folder.
>>>>>> It implements the sending of the password remainder, password updated
>>>>>> services, permission groups etc. that we want available in the
>>>>>> framework-only release also.
>>>>>>
>>>>>> Do we agree to change it to move it over there?
>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>> store dependencies also.
>>>>>>
>>>>>> -Bruno
>>>>>
>>
> 

Re: Moving securityext to the framework

[Adam Heath <do...@brainfood.com>]

Bruno Busco wrote:
> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility to
> have the password emailed if forgotten.
> This is actually done in
>     public static String emailPassword(HttpServletRequest request,
> HttpServletResponse response) {
> that is located in LoginEvents.java in securityext.
> 
> To get the email address, emailPassword(...) checks if the userLoginId
> exists, then find the related party, then find a related ContactMech
> with PRIMARY_MAIL purpose.
> To get the email body and other details, emailPassword(...) starts
> from a ProductStore and gets the related ProductStoreEmailSetting.

Why not move ContactMech(and children, but not PartyContactMech*) to
framework, then have a join table between UserLogin and ContactMech?

Re: Moving securityext to the framework

[Bilgin Ibryam <bi...@gmail.com>]

Bruno Busco wrote:
> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility to
> have the password emailed if forgotten.
> This is actually done in
>     public static String emailPassword(HttpServletRequest request,
> HttpServletResponse response) {
> that is located in LoginEvents.java in securityext.
>
> To get the email address, emailPassword(...) checks if the userLoginId
> exists, then find the related party, then find a related ContactMech
> with PRIMARY_MAIL purpose.
> To get the email body and other details, emailPassword(...) starts
> from a ProductStore and gets the related ProductStoreEmailSetting.
>
> So, being dependent from both party and product, emailPassword(...)
> service needs to be in applications/securityext and cannot be
> available in a framework-only distribution.
>
> Now,
> the emailPassword(...) sevice in the securityext is OK for the
> ecommerce application (that depends on party and product) but IMO is
> not the right implementation for the backoffice (and thus for the
> framework-only).
>
> I propose to do the following:
> 1) Put an email address in the userLogin entity. This would be used to
> retrieve the password.
>  
What about if someone wants to implement retrieving forgotten passwords 
through sms (short messaging service) instead of email? Are we going to 
add telephone number to userLogin entity?
So my vote is to let forgotten password feature in applications or move 
the related entities to framework.

Bilgin

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

In the framework-only there will be the webtools, the example and the
MyPortal applications.
So it is something that should allow defining new users (userLogins)
to be defined with their permissions.
As soon as I have a new user defined I need the forgot password feature working.
This is why we need it.

-Bruno

2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
> My first question is why do we need this functionality in the framework?  At
> what point do we draw the line between framework and application?  Emailing
> passwords sounds very much like an application feature to me.
>
> Regards
> Scott
>
> On 30/12/2009, at 11:50 AM, Bruno Busco wrote:
>
>> One thing we need in the framework is the possibility to create a
>> userLogin with an associated email address and have the possibility to
>> have the password emailed if forgotten.
>> This is actually done in
>>   public static String emailPassword(HttpServletRequest request,
>> HttpServletResponse response) {
>> that is located in LoginEvents.java in securityext.
>>
>> To get the email address, emailPassword(...) checks if the userLoginId
>> exists, then find the related party, then find a related ContactMech
>> with PRIMARY_MAIL purpose.
>> To get the email body and other details, emailPassword(...) starts
>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>
>> So, being dependent from both party and product, emailPassword(...)
>> service needs to be in applications/securityext and cannot be
>> available in a framework-only distribution.
>>
>> Now,
>> the emailPassword(...) sevice in the securityext is OK for the
>> ecommerce application (that depends on party and product) but IMO is
>> not the right implementation for the backoffice (and thus for the
>> framework-only).
>>
>> I propose to do the following:
>> 1) Put an email address in the userLogin entity. This would be used to
>> retrieve the password.
>> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
>> common component (renaming it simply "EmailSetting") and transform the
>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>> EmailSetting.
>> 3) Define a new emailPassword(...) service in the common component
>> that does things differently: using the email address in the userLogin
>> entity and retrieving the email settings accessing to the EmailSetting
>> entity.
>>
>> What do you think about?
>>
>> -Bruno
>>
>>
>>
>> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>>>
>>> Hi Bruno,
>>>
>>> The whole point of the securityext component is to allow portions of
>>> security related functionality to depend on the application components, I
>>> believe this was done as part of the effort to isolate the framework from
>>> any application dependencies.  I think it is perfectly fine to move
>>> portions
>>> of securityext back to the framework when there is no dependency on the
>>> application code but I don't necessarily think we should have a goal of
>>> removing the securityext component altogether.
>>>
>>> It wouldn't be possible to remove securityext without either removing
>>> functionality or otherwise transferring logic that is traditionally in
>>> the
>>> application domain back to the framework.  The more that we look at doing
>>> the latter the more we need to consider exactly what the needs are that
>>> we
>>> want a framework only installation to fulfill.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>
>>>> Hi David, devs,
>>>> I searched the SVN logs to look for a reason for those general purpose
>>>> login and password stuff being in the application and not in the
>>>> framework.
>>>> I found they are there since the incubator time.
>>>>
>>>> What I think should be done is to merge the securityext to the
>>>> security component in the framework. I would like to try to do it, but
>>>> please, if you see something blocking this or something that should be
>>>> done first, or even a reason for not to do this, please advice.
>>>>
>>>> Thank you,
>>>> -Bruno
>>>>
>>>>
>>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>>
>>>>> Scott,
>>>>> from a securityext code browsing I see that there is a dependence from
>>>>> Party, Product and Ecommerce.
>>>>>
>>>>> Party:
>>>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>>>> PartyContactMech entities
>>>>>  -> Could be moved to Party?
>>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>>> the updatePassword service. This is to be sure that an admin can
>>>>> always update a password, even not knowing the current password.
>>>>>  -> An admin permission should be checked here.
>>>>>
>>>>> Product:
>>>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>>>> used for a ProductStore. The password email should be a core feature
>>>>> not used for ProductStores only.
>>>>>  -> Could we split this method in a framework one and an higher
>>>>> level part (dedicated for a ProductStore) implemented in the Product
>>>>> component?
>>>>>
>>>>> Ecommerce:
>>>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>>>> the email password should not only be an ecommerce feature this should
>>>>> be moved to Common.
>>>>>
>>>>> Should we try to resolve these dependences and then merge to security
>>>>> in the framework?
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> I guess the first thing we need to understand is why it exists in the
>>>>>> first
>>>>>> place?  I'm assuming it has some dependencies on application
>>>>>> components
>>>>>> that
>>>>>> prevent it from being in the framework (even if perhaps some of the
>>>>>> logic
>>>>>> could be moved).
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> the securityext component is actually located in the application
>>>>>>> folder.
>>>>>>> It implements the sending of the password remainder, password updated
>>>>>>> services, permission groups etc. that we want available in the
>>>>>>> framework-only release also.
>>>>>>>
>>>>>>> Do we agree to change it to move it over there?
>>>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>>>> store dependencies also.
>>>>>>>
>>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>

Re: Moving securityext to the framework

[Scott Gray <sc...@hotwaxmedia.com>]

My first question is why do we need this functionality in the  
framework?  At what point do we draw the line between framework and  
application?  Emailing passwords sounds very much like an application  
feature to me.

Regards
Scott

On 30/12/2009, at 11:50 AM, Bruno Busco wrote:

> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility to
> have the password emailed if forgotten.
> This is actually done in
>    public static String emailPassword(HttpServletRequest request,
> HttpServletResponse response) {
> that is located in LoginEvents.java in securityext.
>
> To get the email address, emailPassword(...) checks if the userLoginId
> exists, then find the related party, then find a related ContactMech
> with PRIMARY_MAIL purpose.
> To get the email body and other details, emailPassword(...) starts
> from a ProductStore and gets the related ProductStoreEmailSetting.
>
> So, being dependent from both party and product, emailPassword(...)
> service needs to be in applications/securityext and cannot be
> available in a framework-only distribution.
>
> Now,
> the emailPassword(...) sevice in the securityext is OK for the
> ecommerce application (that depends on party and product) but IMO is
> not the right implementation for the backoffice (and thus for the
> framework-only).
>
> I propose to do the following:
> 1) Put an email address in the userLogin entity. This would be used to
> retrieve the password.
> 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
> common component (renaming it simply "EmailSetting") and transform the
> actual "ProductStoreEmailSetting" into a link between ProductStore and
> EmailSetting.
> 3) Define a new emailPassword(...) service in the common component
> that does things differently: using the email address in the userLogin
> entity and retrieving the email settings accessing to the EmailSetting
> entity.
>
> What do you think about?
>
> -Bruno
>
>
>
> 2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
>> Hi Bruno,
>>
>> The whole point of the securityext component is to allow portions of
>> security related functionality to depend on the application  
>> components, I
>> believe this was done as part of the effort to isolate the  
>> framework from
>> any application dependencies.  I think it is perfectly fine to move  
>> portions
>> of securityext back to the framework when there is no dependency on  
>> the
>> application code but I don't necessarily think we should have a  
>> goal of
>> removing the securityext component altogether.
>>
>> It wouldn't be possible to remove securityext without either removing
>> functionality or otherwise transferring logic that is traditionally  
>> in the
>> application domain back to the framework.  The more that we look at  
>> doing
>> the latter the more we need to consider exactly what the needs are  
>> that we
>> want a framework only installation to fulfill.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>
>>> Hi David, devs,
>>> I searched the SVN logs to look for a reason for those general  
>>> purpose
>>> login and password stuff being in the application and not in the
>>> framework.
>>> I found they are there since the incubator time.
>>>
>>> What I think should be done is to merge the securityext to the
>>> security component in the framework. I would like to try to do it,  
>>> but
>>> please, if you see something blocking this or something that  
>>> should be
>>> done first, or even a reason for not to do this, please advice.
>>>
>>> Thank you,
>>> -Bruno
>>>
>>>
>>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>>
>>>> Scott,
>>>> from a securityext code browsing I see that there is a dependence  
>>>> from
>>>> Party, Product and Ecommerce.
>>>>
>>>> Party:
>>>> 1) The UserDemoData.xml file creates several Party, Person,  
>>>> PartyRole,
>>>> PartyContactMech entities
>>>>  -> Could be moved to Party?
>>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>>> the updatePassword service. This is to be sure that an admin can
>>>> always update a password, even not knowing the current password.
>>>>  -> An admin permission should be checked here.
>>>>
>>>> Product:
>>>> 3) In the LoginEvents.java the emailPassword method is written to  
>>>> be
>>>> used for a ProductStore. The password email should be a core  
>>>> feature
>>>> not used for ProductStores only.
>>>>  -> Could we split this method in a framework one and an higher
>>>> level part (dedicated for a ProductStore) implemented in the  
>>>> Product
>>>> component?
>>>>
>>>> Ecommerce:
>>>> 4) In passwordemail.ftl there are few labels from ECommerce ->  
>>>> Since
>>>> the email password should not only be an ecommerce feature this  
>>>> should
>>>> be moved to Common.
>>>>
>>>> Should we try to resolve these dependences and then merge to  
>>>> security
>>>> in the framework?
>>>>
>>>> -Bruno
>>>>
>>>>
>>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>>
>>>>> I guess the first thing we need to understand is why it exists  
>>>>> in the
>>>>> first
>>>>> place?  I'm assuming it has some dependencies on application  
>>>>> components
>>>>> that
>>>>> prevent it from being in the framework (even if perhaps some of  
>>>>> the
>>>>> logic
>>>>> could be moved).
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>>
>>>>>> Hi,
>>>>>> the securityext component is actually located in the application
>>>>>> folder.
>>>>>> It implements the sending of the password remainder, password  
>>>>>> updated
>>>>>> services, permission groups etc. that we want available in the
>>>>>> framework-only release also.
>>>>>>
>>>>>> Do we agree to change it to move it over there?
>>>>>> At least the labels used from ecommerce needs to be changed and  
>>>>>> some
>>>>>> store dependencies also.
>>>>>>
>>>>>> -Bruno
>>>>>
>>>>>
>>>>
>>
>>

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
    public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.

To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.

So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.

Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).

I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the <entity entity-name="ProductStoreEmailSetting"> to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.

What do you think about?

-Bruno



2009/12/29 Scott Gray <sc...@hotwaxmedia.com>:
> Hi Bruno,
>
> The whole point of the securityext component is to allow portions of
> security related functionality to depend on the application components, I
> believe this was done as part of the effort to isolate the framework from
> any application dependencies.  I think it is perfectly fine to move portions
> of securityext back to the framework when there is no dependency on the
> application code but I don't necessarily think we should have a goal of
> removing the securityext component altogether.
>
> It wouldn't be possible to remove securityext without either removing
> functionality or otherwise transferring logic that is traditionally in the
> application domain back to the framework.  The more that we look at doing
> the latter the more we need to consider exactly what the needs are that we
> want a framework only installation to fulfill.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>
>> Hi David, devs,
>> I searched the SVN logs to look for a reason for those general purpose
>> login and password stuff being in the application and not in the
>> framework.
>> I found they are there since the incubator time.
>>
>> What I think should be done is to merge the securityext to the
>> security component in the framework. I would like to try to do it, but
>> please, if you see something blocking this or something that should be
>> done first, or even a reason for not to do this, please advice.
>>
>> Thank you,
>> -Bruno
>>
>>
>> 2009/12/26 Bruno Busco <br...@gmail.com>:
>>>
>>> Scott,
>>> from a securityext code browsing I see that there is a dependence from
>>> Party, Product and Ecommerce.
>>>
>>> Party:
>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>> PartyContactMech entities
>>>  -> Could be moved to Party?
>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>> the updatePassword service. This is to be sure that an admin can
>>> always update a password, even not knowing the current password.
>>>  -> An admin permission should be checked here.
>>>
>>> Product:
>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>> used for a ProductStore. The password email should be a core feature
>>> not used for ProductStores only.
>>>  -> Could we split this method in a framework one and an higher
>>> level part (dedicated for a ProductStore) implemented in the Product
>>> component?
>>>
>>> Ecommerce:
>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>> the email password should not only be an ecommerce feature this should
>>> be moved to Common.
>>>
>>> Should we try to resolve these dependences and then merge to security
>>> in the framework?
>>>
>>> -Bruno
>>>
>>>
>>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>>>
>>>> I guess the first thing we need to understand is why it exists in the
>>>> first
>>>> place?  I'm assuming it has some dependencies on application components
>>>> that
>>>> prevent it from being in the framework (even if perhaps some of the
>>>> logic
>>>> could be moved).
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>>
>>>>> Hi,
>>>>> the securityext component is actually located in the application
>>>>> folder.
>>>>> It implements the sending of the password remainder, password updated
>>>>> services, permission groups etc. that we want available in the
>>>>> framework-only release also.
>>>>>
>>>>> Do we agree to change it to move it over there?
>>>>> At least the labels used from ecommerce needs to be changed and some
>>>>> store dependencies also.
>>>>>
>>>>> -Bruno
>>>>
>>>>
>>>
>
>

Re: Moving securityext to the framework

[Scott Gray <sc...@hotwaxmedia.com>]

Hi Bruno,

The whole point of the securityext component is to allow portions of  
security related functionality to depend on the application  
components, I believe this was done as part of the effort to isolate  
the framework from any application dependencies.  I think it is  
perfectly fine to move portions of securityext back to the framework  
when there is no dependency on the application code but I don't  
necessarily think we should have a goal of removing the securityext  
component altogether.

It wouldn't be possible to remove securityext without either removing  
functionality or otherwise transferring logic that is traditionally in  
the application domain back to the framework.  The more that we look  
at doing the latter the more we need to consider exactly what the  
needs are that we want a framework only installation to fulfill.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 30/12/2009, at 6:11 AM, Bruno Busco wrote:

> Hi David, devs,
> I searched the SVN logs to look for a reason for those general purpose
> login and password stuff being in the application and not in the
> framework.
> I found they are there since the incubator time.
>
> What I think should be done is to merge the securityext to the
> security component in the framework. I would like to try to do it, but
> please, if you see something blocking this or something that should be
> done first, or even a reason for not to do this, please advice.
>
> Thank you,
> -Bruno
>
>
> 2009/12/26 Bruno Busco <br...@gmail.com>:
>> Scott,
>> from a securityext code browsing I see that there is a dependence  
>> from
>> Party, Product and Ecommerce.
>>
>> Party:
>> 1) The UserDemoData.xml file creates several Party, Person,  
>> PartyRole,
>> PartyContactMech entities
>>   -> Could be moved to Party?
>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>> the updatePassword service. This is to be sure that an admin can
>> always update a password, even not knowing the current password.
>>   -> An admin permission should be checked here.
>>
>> Product:
>> 3) In the LoginEvents.java the emailPassword method is written to be
>> used for a ProductStore. The password email should be a core feature
>> not used for ProductStores only.
>>   -> Could we split this method in a framework one and an higher
>> level part (dedicated for a ProductStore) implemented in the Product
>> component?
>>
>> Ecommerce:
>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>> the email password should not only be an ecommerce feature this  
>> should
>> be moved to Common.
>>
>> Should we try to resolve these dependences and then merge to security
>> in the framework?
>>
>> -Bruno
>>
>>
>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>> I guess the first thing we need to understand is why it exists in  
>>> the first
>>> place?  I'm assuming it has some dependencies on application  
>>> components that
>>> prevent it from being in the framework (even if perhaps some of  
>>> the logic
>>> could be moved).
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>
>>>> Hi,
>>>> the securityext component is actually located in the application  
>>>> folder.
>>>> It implements the sending of the password remainder, password  
>>>> updated
>>>> services, permission groups etc. that we want available in the
>>>> framework-only release also.
>>>>
>>>> Do we agree to change it to move it over there?
>>>> At least the labels used from ecommerce needs to be changed and  
>>>> some
>>>> store dependencies also.
>>>>
>>>> -Bruno
>>>
>>>
>>

Re: Moving securityext to the framework

[Jacques Le Roux <ja...@les7arts.com>]

UserLogin has a partyId field extended in Party application. This is certainly something that is widely used (so convenient) and 
should be taken with care.

Jacques

From: "Bruno Busco" <br...@gmail.com>
> Hi David, devs,
> I searched the SVN logs to look for a reason for those general purpose
> login and password stuff being in the application and not in the
> framework.
> I found they are there since the incubator time.
>
> What I think should be done is to merge the securityext to the
> security component in the framework. I would like to try to do it, but
> please, if you see something blocking this or something that should be
> done first, or even a reason for not to do this, please advice.
>
> Thank you,
> -Bruno
>
>
> 2009/12/26 Bruno Busco <br...@gmail.com>:
>> Scott,
>> from a securityext code browsing I see that there is a dependence from
>> Party, Product and Ecommerce.
>>
>> Party:
>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>> PartyContactMech entities
>> -> Could be moved to Party?
>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>> the updatePassword service. This is to be sure that an admin can
>> always update a password, even not knowing the current password.
>> -> An admin permission should be checked here.
>>
>> Product:
>> 3) In the LoginEvents.java the emailPassword method is written to be
>> used for a ProductStore. The password email should be a core feature
>> not used for ProductStores only.
>> -> Could we split this method in a framework one and an higher
>> level part (dedicated for a ProductStore) implemented in the Product
>> component?
>>
>> Ecommerce:
>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>> the email password should not only be an ecommerce feature this should
>> be moved to Common.
>>
>> Should we try to resolve these dependences and then merge to security
>> in the framework?
>>
>> -Bruno
>>
>>
>> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>>> I guess the first thing we need to understand is why it exists in the first
>>> place? I'm assuming it has some dependencies on application components that
>>> prevent it from being in the framework (even if perhaps some of the logic
>>> could be moved).
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>>
>>>> Hi,
>>>> the securityext component is actually located in the application folder.
>>>> It implements the sending of the password remainder, password updated
>>>> services, permission groups etc. that we want available in the
>>>> framework-only release also.
>>>>
>>>> Do we agree to change it to move it over there?
>>>> At least the labels used from ecommerce needs to be changed and some
>>>> store dependencies also.
>>>>
>>>> -Bruno
>>>
>>>
>>
>

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.

What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it, but
please, if you see something blocking this or something that should be
done first, or even a reason for not to do this, please advice.

Thank you,
-Bruno


2009/12/26 Bruno Busco <br...@gmail.com>:
> Scott,
> from a securityext code browsing I see that there is a dependence from
> Party, Product and Ecommerce.
>
> Party:
> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
> PartyContactMech entities
>   -> Could be moved to Party?
> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
> the updatePassword service. This is to be sure that an admin can
> always update a password, even not knowing the current password.
>   -> An admin permission should be checked here.
>
> Product:
> 3) In the LoginEvents.java the emailPassword method is written to be
> used for a ProductStore. The password email should be a core feature
> not used for ProductStores only.
>   -> Could we split this method in a framework one and an higher
> level part (dedicated for a ProductStore) implemented in the Product
> component?
>
> Ecommerce:
> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
> the email password should not only be an ecommerce feature this should
> be moved to Common.
>
> Should we try to resolve these dependences and then merge to security
> in the framework?
>
> -Bruno
>
>
> 2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
>> I guess the first thing we need to understand is why it exists in the first
>> place?  I'm assuming it has some dependencies on application components that
>> prevent it from being in the framework (even if perhaps some of the logic
>> could be moved).
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>>
>>> Hi,
>>> the securityext component is actually located in the application folder.
>>> It implements the sending of the password remainder, password updated
>>> services, permission groups etc. that we want available in the
>>> framework-only release also.
>>>
>>> Do we agree to change it to move it over there?
>>> At least the labels used from ecommerce needs to be changed and some
>>> store dependencies also.
>>>
>>> -Bruno
>>
>>
>

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Scott,
from a securityext code browsing I see that there is a dependence from
Party, Product and Ecommerce.

Party:
1) The UserDemoData.xml file creates several Party, Person, PartyRole,
PartyContactMech entities
   -> Could be moved to Party?
2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
the updatePassword service. This is to be sure that an admin can
always update a password, even not knowing the current password.
   -> An admin permission should be checked here.

Product:
3) In the LoginEvents.java the emailPassword method is written to be
used for a ProductStore. The password email should be a core feature
not used for ProductStores only.
   -> Could we split this method in a framework one and an higher
level part (dedicated for a ProductStore) implemented in the Product
component?

Ecommerce:
4) In passwordemail.ftl there are few labels from ECommerce -> Since
the email password should not only be an ecommerce feature this should
be moved to Common.

Should we try to resolve these dependences and then merge to security
in the framework?

-Bruno


2009/12/11 Scott Gray <sc...@hotwaxmedia.com>:
> I guess the first thing we need to understand is why it exists in the first
> place?  I'm assuming it has some dependencies on application components that
> prevent it from being in the framework (even if perhaps some of the logic
> could be moved).
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
>
>> Hi,
>> the securityext component is actually located in the application folder.
>> It implements the sending of the password remainder, password updated
>> services, permission groups etc. that we want available in the
>> framework-only release also.
>>
>> Do we agree to change it to move it over there?
>> At least the labels used from ecommerce needs to be changed and some
>> store dependencies also.
>>
>> -Bruno
>
>

Re: Moving securityext to the framework

[Scott Gray <sc...@hotwaxmedia.com>]

I guess the first thing we need to understand is why it exists in the  
first place?  I'm assuming it has some dependencies on application  
components that prevent it from being in the framework (even if  
perhaps some of the logic could be moved).

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 11/12/2009, at 11:41 PM, Bruno Busco wrote:

> Hi,
> the securityext component is actually located in the application  
> folder.
> It implements the sending of the password remainder, password updated
> services, permission groups etc. that we want available in the
> framework-only release also.
>
> Do we agree to change it to move it over there?
> At least the labels used from ecommerce needs to be changed and some
> store dependencies also.
>
> -Bruno