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 <adri...@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 <bruno.bu...@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 <bruno.bu...@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 <adri...@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 <scott.g...@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 <bruno.bu...@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 <scott.g...@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
>>
>
