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