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 <[email protected]>: > 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 <[email protected]>: >>> >>> 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 <[email protected]>: >>>>> >>>>> 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 <[email protected]>: >>>>>> >>>>>> 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 <[email protected]>: >>>>>>> >>>>>>> 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 <[email protected]>: >>>>>>>>> >>>>>>>>> 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 <[email protected]>: >>>>>>>>>>> >>>>>>>>>>> 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 <[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>> 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 >> >
