[jira] Closed: (OFBIZ-3274) Using decorator sections to control the left-bar
[ https://issues.apache.org/jira/browse/OFBIZ-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3274. -- Resolution: Fixed A modified patch committed into trunk At revision: 894330 Using decorator sections to control the left-bar Key: OFBIZ-3274 URL: https://issues.apache.org/jira/browse/OFBIZ-3274 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Bruno Busco Assignee: Bruno Busco Attachments: OFBIZ-3274 DecoratorSectionLayout.patch, OFBIZ-3274 DecoratorSectionLayout.patch, OFBIZ-3274 DecoratorSectionLayout.patch Hi, at the moment, in order to have a screen rendered with or without a left bar, the variables leftbarScreenName, leftbarScreenLocation and MainColumnStyle need to be set to select a screen for the left bar and a main column style. This must be done in the screen itself or an application decorator. With the attached patch, submitted for your review, a new GlobalDecorator section named left-bar has been added. If a screen must be displayed with a left bar this new decorator section needs to be filled with the selected content. The main column style is defined in the Global decorator. In order to do this a new screen condition has been added: if-empty-decorator-section. This condition allows to check if a decorator section has been added content or not. (actually it only checks if the decorator section has been defined). In the patch I updated all catalog application screens to use this new method. If there are no problems with you with this, I will commit in the next days. Thank you for sharing your thoughts about. -Bruno -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3374) UI upgrade, new lookups
[ https://issues.apache.org/jira/browse/OFBIZ-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795033#action_12795033 ] Bruno Busco commented on OFBIZ-3374: Hi Sascha, I have looked at your latest patch. Few comments: 1) Are we sure we can commit the resize.js file as it is? There is a license note that I do not know if is compatible with the Apache. I would like others to check at least thi file in the patch. 2) To check that a section is empty there is now the tag if-empty-section section-name=body/ you should use instead of if-empty field=sections.body/ 3) There are some conflict with the latest trunk 4) Generally to get the review simpler is better to remove all the formatting changes (there are lots of trailing spaces removal) 5) Where and which gif file need to be added to let the patch work? Thank you Sascha for the continued effort with this but I try to do my best to avoid wrong things committed. I hope you understand. UI upgrade, new lookups --- Key: OFBIZ-3374 URL: https://issues.apache.org/jira/browse/OFBIZ-3374 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Sascha Rodekamp Priority: Minor Fix For: SVN trunk Attachments: header_bg.gif, header_close_button.png, lookup.jpg, lookup2.jpg, lookups.patch, lookups.patch, lookups.patch, lookups.patch, lookups.patch, lookups.patch Hi, regarding to this articel: [here|http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document#NewFeaturesRoadmap-LivingDocument-Quickeranintuitiveaccesstobasicfunctionnalities%28creation,etc.%29] I decided to improve the lookup fields. They shouldn't open in a page layer instead of a seperate windows. My Patch contains a prototype (not a final patch), so what do you think about the new lookup windows? Should i follow this idea, any suggestions? So long Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Naming pattern of test definition files
Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas smime.p7s Description: S/MIME cryptographic signature
Re: Naming pattern of test definition files
+1. Rishi Solanki Enterprise Software Developer HotWax Media Pvt. Ltd. On Tue, Dec 29, 2009 at 6:24 PM, Vikas Mayur vikas.ma...@hotwaxmedia.comwrote: Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas
Re: Naming pattern of test definition files
Yes sounds logical +1 Jacques From: Rishi Solanki rishisolan...@gmail.com +1. Rishi Solanki Enterprise Software Developer HotWax Media Pvt. Ltd. On Tue, Dec 29, 2009 at 6:24 PM, Vikas Mayur vikas.ma...@hotwaxmedia.comwrote: Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas
Re: svn commit: r893961 - in /ofbiz/trunk/applications/party: servicedef/ src/org/ofbiz/party/party/
David E Jones wrote: On Dec 28, 2009, at 4:32 PM, Jacques Le Roux wrote: From: Ean Schuessler e...@brainfood.com Jacques Le Roux wrote: Thanks, I saw that but was not sure how to use it. I remember now why I created Java services. I needed to create a PartyGroup. So initially I looked for a service and found createPartyGroup wich is implemented by a method in PartyServices.java. Then I continued in Java :/. Now I wonder what we should do regarding your sentence I've thought a few times that maybe it's not the best idea to do so, and instead whenever a party is implied to be in a role if they are not already then they should be added automatically. in http://markmail.org/message/j5yprwdv3fgz3rb6 I always took this to be a security thing, that a role must be authorized before it can be used in relationships and other structures. If the aplication needs to create a PartyRole, I can't see any reasons to not let it do it automatically The original idea was to use this as an extra protection, ie so users don't describe a party's relationship with something else using a certain role if the party isn't really in that role. The result, however, is that it is cumbersome, a real pain, and a common complaint... which is why I'm for changing the default behavior. Maybe have it configurable in a properties file, like requirePartyRole=true or enforcePartyRole=true. -Adrian
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
UserLogin has a partyId field extended in Party application. This is certainly something that is widely used (so convenient) and should be taken with care. Jacques From: Bruno Busco bruno.bu...@gmail.com 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
Re: svn commit: r893961 - in /ofbiz/trunk/applications/party: servicedef/ src/org/ofbiz/party/party/
From: Adrian Crum adri...@hlmksw.com David E Jones wrote: On Dec 28, 2009, at 4:32 PM, Jacques Le Roux wrote: From: Ean Schuessler e...@brainfood.com Jacques Le Roux wrote: Thanks, I saw that but was not sure how to use it. I remember now why I created Java services. I needed to create a PartyGroup. So initially I looked for a service and found createPartyGroup wich is implemented by a method in PartyServices.java. Then I continued in Java :/. Now I wonder what we should do regarding your sentence I've thought a few times that maybe it's not the best idea to do so, and instead whenever a party is implied to be in a role if they are not already then they should be added automatically. in http://markmail.org/message/j5yprwdv3fgz3rb6 I always took this to be a security thing, that a role must be authorized before it can be used in relationships and other structures. If the aplication needs to create a PartyRole, I can't see any reasons to not let it do it automatically The original idea was to use this as an extra protection, ie so users don't describe a party's relationship with something else using a certain role if the party isn't really in that role. The result, however, is that it is cumbersome, a real pain, and a common complaint... which is why I'm for changing the default behavior. Maybe have it configurable in a properties file, like requirePartyRole=true or enforcePartyRole=true. -Adrian That can certainly be taken into account, sure. Jacques
[jira] Commented: (OFBIZ-3381) Update of the geolocation screen in party
[ https://issues.apache.org/jira/browse/OFBIZ-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795092#action_12795092 ] Erwan de FERRIERES commented on OFBIZ-3381: --- Hi Jacques, this is was my intent, but I hadn't yet search for other screens to update. Thanks for pointing them. I'm a bit busy this week, but I will take a look at it next week ! Cheers, Update of the geolocation screen in party - Key: OFBIZ-3381 URL: https://issues.apache.org/jira/browse/OFBIZ-3381 Project: OFBiz Issue Type: Improvement Components: party Affects Versions: SVN trunk Reporter: Erwan de FERRIERES Fix For: SVN trunk Attachments: OFBIZ-3381.diff This will allow to use the new geoChart screen introduced by Bruno instead of the geoLocation screen, and then have less javascript calls. I put this as a JIRA issue to have your comments and be sure that this meet OFBiz requirements. if it's OK, I will then commit it to the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3381) Update of the geolocation screen in party
[ https://issues.apache.org/jira/browse/OFBIZ-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795095#action_12795095 ] Jacques Le Roux commented on OFBIZ-3381: Thanks Erwan, Cheers Update of the geolocation screen in party - Key: OFBIZ-3381 URL: https://issues.apache.org/jira/browse/OFBIZ-3381 Project: OFBiz Issue Type: Improvement Components: party Affects Versions: SVN trunk Reporter: Erwan de FERRIERES Fix For: SVN trunk Attachments: OFBIZ-3381.diff This will allow to use the new geoChart screen introduced by Bruno instead of the geoLocation screen, and then have less javascript calls. I put this as a JIRA issue to have your comments and be sure that this meet OFBiz requirements. if it's OK, I will then commit it to the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r893961 - in /ofbiz/trunk/applications/party: servicedef/ src/org/ofbiz/party/party/
David E Jones wrote: The original idea was to use this as an extra protection, ie so users don't describe a party's relationship with something else using a certain role if the party isn't really in that role. The result, however, is that it is cumbersome, a real pain, and a common complaint... which is why I'm for changing the default behavior. Could the ability to assign roles require membership in a different security group? If the user has the ability to assign roles it would do it automatically otherwise it would fail. You might even like to have the ability to partition which roles can be assigned by which users but that might get a bit complicated.
Re: svn commit: r893961 - in /ofbiz/trunk/applications/party: servicedef/ src/org/ofbiz/party/party/
Adrian Crum wrote: David E Jones wrote: On Dec 28, 2009, at 4:32 PM, Jacques Le Roux wrote: From: Ean Schuessler e...@brainfood.com Jacques Le Roux wrote: Thanks, I saw that but was not sure how to use it. I remember now why I created Java services. I needed to create a PartyGroup. So initially I looked for a service and found createPartyGroup wich is implemented by a method in PartyServices.java. Then I continued in Java :/. Now I wonder what we should do regarding your sentence I've thought a few times that maybe it's not the best idea to do so, and instead whenever a party is implied to be in a role if they are not already then they should be added automatically. in http://markmail.org/message/j5yprwdv3fgz3rb6 I always took this to be a security thing, that a role must be authorized before it can be used in relationships and other structures. If the aplication needs to create a PartyRole, I can't see any reasons to not let it do it automatically The original idea was to use this as an extra protection, ie so users don't describe a party's relationship with something else using a certain role if the party isn't really in that role. The result, however, is that it is cumbersome, a real pain, and a common complaint... which is why I'm for changing the default behavior. Maybe have it configurable in a properties file, like requirePartyRole=true or enforcePartyRole=true. Not the best, as existing code in ofbiz which uses this service may break if that property setting is changed. However, maybe adding a boolean flag to the service definition, defaulted to false, would help. Adding the single flag to all the callers would still be a win, rather than keeping the role creation stuff everywhere.
[jira] Commented: (OFBIZ-2913) Write a new service for quick create customer profile.
[ https://issues.apache.org/jira/browse/OFBIZ-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795115#action_12795115 ] Bruno Busco commented on OFBIZ-2913: Hi, while looking for a framework integration of the basic userLogin/Person/email stuff I fond this jira. I think the mentioned service (createContact, createPerson etc.) should be moved in the framework. Having a userLogin with Person Name and email in the framework would allow for instance to have a forgotten email forwarded even with no applications. Write a new service for quick create customer profile. -- Key: OFBIZ-2913 URL: https://issues.apache.org/jira/browse/OFBIZ-2913 Project: OFBiz Issue Type: New Feature Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Sumit Pandit Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-2913.patch, OFBIZ-2913.patch, OFBIZ-2913.patch Write a new service for creating a customer profile. This could be called as QuickCreateCustomerProfile. Create a Customer Profile based on following IN parameter - 1) First Name 2) Last Name 3) Email Address Based on above information create - Person, Party, PartyRole (CUSTOMER), Contact (Email). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3374) UI upgrade, new lookups
[ https://issues.apache.org/jira/browse/OFBIZ-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795126#action_12795126 ] Jacques Le Roux commented on OFBIZ-3374: HI Bruno, Sascha, 1) We already have a notice about Thomas Fuchs's works in the NOTICE file so it's OK. 4) True, but on the other hand, we should not have any trailing spaces :/ Adam and I have struggled against them many times, but they always creep in again :) Actually it's hard to avoid them, notably on new lines, etc. And most of them in this patch are from new lines... 5) From the patch wr.png, header_close_button.png and header_bg.gif are needed, so it's looks like wr.png is missing. Thanks guys! UI upgrade, new lookups --- Key: OFBIZ-3374 URL: https://issues.apache.org/jira/browse/OFBIZ-3374 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Sascha Rodekamp Priority: Minor Fix For: SVN trunk Attachments: header_bg.gif, header_close_button.png, lookup.jpg, lookup2.jpg, lookups.patch, lookups.patch, lookups.patch, lookups.patch, lookups.patch, lookups.patch Hi, regarding to this articel: [here|http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document#NewFeaturesRoadmap-LivingDocument-Quickeranintuitiveaccesstobasicfunctionnalities%28creation,etc.%29] I decided to improve the lookup fields. They shouldn't open in a page layer instead of a seperate windows. My Patch contains a prototype (not a final patch), so what do you think about the new lookup windows? Should i follow this idea, any suggestions? So long Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Naming pattern of test definition files
+1 Regards Scott On 30/12/2009, at 1:54 AM, Vikas Mayur wrote: Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas smime.p7s Description: S/MIME cryptographic signature
Re: Moving securityext to the framework
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 smime.p7s Description: S/MIME cryptographic signature
Re: Moving securityext to the framework
My first question is why do we need this functionality in the
framework? At what point do we draw the line between framework and
application? Emailing passwords sounds very much like an application
feature to me.
Regards
Scott
On 30/12/2009, at 11:50 AM, 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,
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
In the framework-only there will be the webtools, the example and the
MyPortal applications.
So it is something that should allow defining new users (userLogins)
to be defined with their permissions.
As soon as I have a new user defined I need the forgot password feature working.
This is why we need it.
-Bruno
2009/12/29 Scott Gray scott.g...@hotwaxmedia.com:
My first question is why do we need this functionality in the framework? At
what point do we draw the line between framework and application? Emailing
passwords sounds very much like an application feature to me.
Regards
Scott
On 30/12/2009, at 11:50 AM, 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?
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
Like Scott said, that feature is appropriate for applications, not for
the framework. So we can create framework services for the feature that
do nothing - which can then be overridden by applications, or we can
remove the feature from the framework and implement it entirely in the
Party application (or some other application).
-Adrian
Bruno Busco wrote:
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
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
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)
Re: Moving securityext to the framework
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.
Why not move ContactMech(and children, but not PartyContactMech*) to
framework, then have a join table between UserLogin and ContactMech?
Re: Moving securityext to the framework
I would recommend changing #6 to:
#6 users can change their password
and then drop 7 through 9.
But that's just my opinion.
-Adrian
Bruno Busco wrote:
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:
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
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
Re: Moving securityext to the framework
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
Re: Naming pattern of test definition files
Why not camel case them like most other files? -David On Dec 29, 2009, at 1:05 PM, Bilgin Ibryam wrote: Vikas Mayur wrote: Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas + 1 for a naming pattern. The above proposal is fine for me. Bilgin
Re: Naming pattern of test definition files
Actually, most XML files in OFBiz these days (with just a few exceptions) follow a patterns like: *Services.xml *Forms.xml *Screens.xml *Data.xml ... etc By that pattern the test files should be *Tests.xml, with the rest of the file camel-cased and an upper-case first letter. -David On Dec 29, 2009, at 6:44 PM, David E Jones wrote: Why not camel case them like most other files? -David On Dec 29, 2009, at 1:05 PM, Bilgin Ibryam wrote: Vikas Mayur wrote: Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas + 1 for a naming pattern. The above proposal is fine for me. Bilgin
[jira] Updated: (OFBIZ-3379) Email sending process using one connection for To/CC/BCC causing issues
[ https://issues.apache.org/jira/browse/OFBIZ-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3379: -- Attachment: OFBIZ-3379.patch Attaching a patch which generates a delivery failure notification which along with r894236 should resolve this issue. Pranay, I'm unable to test this patch because I couldn't reproduce the environment in which the SendFailedException occurs. Could you either test the patch for me or otherwise let me know (offline) how to setup my system in order to reproduce the problem? Thanks Scott Email sending process using one connection for To/CC/BCC causing issues --- Key: OFBIZ-3379 URL: https://issues.apache.org/jira/browse/OFBIZ-3379 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: Pranay Pandey Assignee: Scott Gray Fix For: Release Branch 9.04, SVN trunk Attachments: OFBIZ-3379.patch, OFBIZ-3379.patch Typically BCCs are handled via the sending mail client. That is, when the client sees a BCC in an email, it will open up two connections to the mail server, the first for the To/CC fields, the second for BCC fields, this way the addresses are masked from the headers and there is that layer of anonymity that BCC is used for. What appears to be happening is that OFBiz is sending all of the information in one connection to the mail server and having the mail server sort out the details. So when sendTo encountering an invalid email, and then terminating the remaining execution of the outgoing process and no email sent to BCC address which is usually going to be a valid address from email settings for the company. To fix the issue, we need to send this via two connection to mail client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3386) Docbook Online Help: Help screens for Global GL Settings
Docbook Online Help: Help screens for Global GL Settings Key: OFBIZ-3386 URL: https://issues.apache.org/jira/browse/OFBIZ-3386 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Sharan Foga Priority: Minor Hi This is a patch for the Docbook online help. It contains some help text and placemarker xml files for the Accounting Global GL Settings screens. Thanks Sharan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3386) Docbook Online Help: Help screens for Global GL Settings
[ https://issues.apache.org/jira/browse/OFBIZ-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharan Foga updated OFBIZ-3386: --- Attachment: OFBIZ-3386_DocbookGlobalGLSettings.patch Docbook Online Help: Help screens for Global GL Settings Key: OFBIZ-3386 URL: https://issues.apache.org/jira/browse/OFBIZ-3386 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Sharan Foga Priority: Minor Attachments: OFBIZ-3386_DocbookGlobalGLSettings.patch Hi This is a patch for the Docbook online help. It contains some help text and placemarker xml files for the Accounting Global GL Settings screens. Thanks Sharan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2913) Write a new service for quick create customer profile.
[ https://issues.apache.org/jira/browse/OFBIZ-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795240#action_12795240 ] Sumit Pandit commented on OFBIZ-2913: - Hi Bruno, I am not sure that I got your point, if you don't mind can you please describe it a little bit more. :) Write a new service for quick create customer profile. -- Key: OFBIZ-2913 URL: https://issues.apache.org/jira/browse/OFBIZ-2913 Project: OFBiz Issue Type: New Feature Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Sumit Pandit Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-2913.patch, OFBIZ-2913.patch, OFBIZ-2913.patch Write a new service for creating a customer profile. This could be called as QuickCreateCustomerProfile. Create a Customer Profile based on following IN parameter - 1) First Name 2) Last Name 3) Email Address Based on above information create - Person, Party, PartyRole (CUSTOMER), Contact (Email). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3379) Email sending process using one connection for To/CC/BCC causing issues
[ https://issues.apache.org/jira/browse/OFBIZ-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795241#action_12795241 ] Pranay Pandey commented on OFBIZ-3379: -- Thanks Scott, I will test the patch uploaded by you and will post the results here. Email sending process using one connection for To/CC/BCC causing issues --- Key: OFBIZ-3379 URL: https://issues.apache.org/jira/browse/OFBIZ-3379 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: Pranay Pandey Assignee: Scott Gray Fix For: Release Branch 9.04, SVN trunk Attachments: OFBIZ-3379.patch, OFBIZ-3379.patch Typically BCCs are handled via the sending mail client. That is, when the client sees a BCC in an email, it will open up two connections to the mail server, the first for the To/CC fields, the second for BCC fields, this way the addresses are masked from the headers and there is that layer of anonymity that BCC is used for. What appears to be happening is that OFBiz is sending all of the information in one connection to the mail server and having the mail server sort out the details. So when sendTo encountering an invalid email, and then terminating the remaining execution of the outgoing process and no email sent to BCC address which is usually going to be a valid address from email settings for the company. To fix the issue, we need to send this via two connection to mail client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Naming pattern of test definition files
+1 on David's comment, *Tests.xml looking better. -- Thanks and Regards Sumit Pandit On Dec 29, 2009, at 5:47 PM, David E Jones wrote: Actually, most XML files in OFBiz these days (with just a few exceptions) follow a patterns like: *Services.xml *Forms.xml *Screens.xml *Data.xml ... etc By that pattern the test files should be *Tests.xml, with the rest of the file camel-cased and an upper-case first letter. -David On Dec 29, 2009, at 6:44 PM, David E Jones wrote: Why not camel case them like most other files? -David On Dec 29, 2009, at 1:05 PM, Bilgin Ibryam wrote: Vikas Mayur wrote: Hi, The test definition files name is not consistent throughout the project. Some of the files name is all lowercase and others have camel case pattern. I think we can follow the pattern used in service definition files. The files under accounting/testdef are accountingtests.xml invoicetests.xml paymenttests.xml fixedassettests.xml and would be (after this change) tests.xml (generic test) tests_invoice.xml (tests specific to invoices) tests_payment.xml (tests specific to payments) tests_fixedasset.xml (tests specific to fixed assets) etc.. Any thoughts? Vikas + 1 for a naming pattern. The above proposal is fine for me. Bilgin
