+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
[
https://issues.apache.org/jira/browse/OFBIZ-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795241#action_12795241
]
Pranay Pandey commented on OFBIZ-3379:
--
Thanks Scott, I will test the patch uploaded b
[
https://issues.apache.org/jira/browse/OFBIZ-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795240#action_12795240
]
Sumit Pandit commented on OFBIZ-2913:
-
Hi Bruno,
I am not sure that I got your point,
[
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 G
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
Componen
[
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 al
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
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.
>>
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 :
> Adrian,
> I think our divergence comes from how we imagine the framework-only being
> us
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
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
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
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,
>
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 :
> All of the things you are describing could be done by an application
> developer that is usin
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 :
> All of the things you a
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 se
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 applic
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 :
> Adrian,
> the getPrimaryEmailAddress
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-onl
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 :
> Or have a service - getPrimaryEmailAddress - that is defined in the
> framework and returns nothing. T
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 nee
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
use
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
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)
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
+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.
Th
[
https://issues.apache.org/jira/browse/OFBIZ-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795126#action_12795126
]
Jacques Le Roux commented on OFBIZ-3374:
HI Bruno, Sascha,
1) We already have a no
[
https://issues.apache.org/jira/browse/OFBIZ-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795115#action_12795115
]
Bruno Busco commented on OFBIZ-2913:
Hi,
while looking for a framework integration of t
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
accountingt
Adrian Crum wrote:
> David E Jones wrote:
>> On Dec 28, 2009, at 4:32 PM, Jacques Le Roux wrote:
>>
>>> From: "Ean Schuessler"
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 PartyGrou
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
>
[
https://issues.apache.org/jira/browse/OFBIZ-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795095#action_12795095
]
Jacques Le Roux commented on OFBIZ-3381:
Thanks Erwan,
Cheers
> Update of the geo
[
https://issues.apache.org/jira/browse/OFBIZ-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795092#action_12795092
]
Erwan de FERRIERES commented on OFBIZ-3381:
---
Hi Jacques,
this is was my intent, b
From: "Adrian Crum"
David E Jones wrote:
On Dec 28, 2009, at 4:32 PM, Jacques Le Roux wrote:
From: "Ean Schuessler"
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 f
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"
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stu
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 t
David E Jones wrote:
On Dec 28, 2009, at 4:32 PM, Jacques Le Roux wrote:
From: "Ean Schuessler"
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
Yes sounds logical
+1
Jacques
From: "Rishi Solanki"
+1.
Rishi Solanki
Enterprise Software Developer
HotWax Media Pvt. Ltd.
On Tue, Dec 29, 2009 at 6:24 PM, Vikas Mayur wrote:
Hi,
The test definition files name is not consistent throughout the project.
Some of the files name is all lower
+1.
Rishi Solanki
Enterprise Software Developer
HotWax Media Pvt. Ltd.
On Tue, Dec 29, 2009 at 6:24 PM, 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
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
invoicete
[
https://issues.apache.org/jira/browse/OFBIZ-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795033#action_12795033
]
Bruno Busco commented on OFBIZ-3374:
Hi Sascha,
I have looked at your latest patch.
Fe
[
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
42 matches
Mail list logo
