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 >>> >> >