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