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