[jira] [Commented] (OFBIZ-5865) Have the ability to generate a quote when request is of type 'Request for proposal'
[ https://issues.apache.org/jira/browse/OFBIZ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201777#comment-14201777 ] Pierre Smits commented on OFBIZ-5865: - Thanks for pointing that out. I will submit a new patch as a replacement. Have the ability to generate a quote when request is of type 'Request for proposal' --- Key: OFBIZ-5865 URL: https://issues.apache.org/jira/browse/OFBIZ-5865 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Pierre Smits Labels: RfP, quote, request Attachments: OFBIZ-5865-ORDER-Request-RfP.patch Currently the use can only generate a quote from the request screens when the request is of the type 'Request for Quote'. However, a request for proposal is in effect also a request for quote and therefor the user should also have the ability to generate a quote from the request when it is of type 'Request for proposal'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-5865) Have the ability to generate a quote when request is of type 'Request for proposal'
[ https://issues.apache.org/jira/browse/OFBIZ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-5865: Attachment: OFBIZ-5865-ORDER-Request-RfP-v2.patch This patch supersedes the first one. Have the ability to generate a quote when request is of type 'Request for proposal' --- Key: OFBIZ-5865 URL: https://issues.apache.org/jira/browse/OFBIZ-5865 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Pierre Smits Labels: RfP, quote, request Attachments: OFBIZ-5865-ORDER-Request-RfP-v2.patch, OFBIZ-5865-ORDER-Request-RfP.patch Currently the use can only generate a quote from the request screens when the request is of the type 'Request for Quote'. However, a request for proposal is in effect also a request for quote and therefor the user should also have the ability to generate a quote from the request when it is of type 'Request for proposal'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201796#comment-14201796
]
Deepak Dixit commented on OFBIZ-5848:
-
Hi Jacopo,
R13.07 successfully build on java 7.
{code}
jar:
[jar] Building jar:
/Users/deepakdixit/sandbox/ofbiz.13.07/specialpurpose/ecommerce/build/lib/ofbiz-ecommerce.jar
build:
[externalsubant] No sub-builds to iterate on
clean-svninfo:
[echo] Resetting svninfo...
[echo] Done!
[echo] [build] == Done Building (Compile) ==
BUILD SUCCESSFUL
Total time: 45 seconds
deepaks-mbp:ofbiz.13.07 deepakdixit$ java -version
java version 1.7.0_65
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
deepaks-mbp:ofbiz.13.07 deepakdixit$
{code}
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201815#comment-14201815
]
Adrian Crum commented on OFBIZ-5848:
Getting R13 to compile with Java 7 has never been a problem. The problem is the
tests will fail using java 7.
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5773) @htmlTemplate.renderDateTimeField icon buttons disappear on some pages after refresh
[ https://issues.apache.org/jira/browse/OFBIZ-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201846#comment-14201846 ] Gareth Carter commented on OFBIZ-5773: -- Hi guys I have just had a look at this issue and I don't believe the patch provided does not fix the issue. Google chrome works fine but in Firefox it seems to set initDate to browsers locale even though the attribute value is ISO: input name=shipAfterDate_i18n title=Format: -MM-dd HH:mm:ss.SSS value=2014-11-07 00:00:00.000 size=25 maxlength=30 id=shipAfterDate_1_i18n type=text In Firefox, initDate is 07/11/2014 00:00:00 so either Firefox or jQuery is converting to local format (I think firefox) I have created another issue relating to this one https://issues.apache.org/jira/browse/OFBIZ-5850, shall I provide the patch in that issue or this? @htmlTemplate.renderDateTimeField icon buttons disappear on some pages after refresh -- Key: OFBIZ-5773 URL: https://issues.apache.org/jira/browse/OFBIZ-5773 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Christian Carlow Assignee: Ashish Vijaywargiya Priority: Minor Fix For: Release Branch 11.04, Upcoming Branch Attachments: OFBIZ-5773-branch-13.07.patch, OFBIZ-5773.patch When some pages that use @htmlTemplate.renderDateTimeField are refreshed the icons associated with those fields start to disappear. For example, the ShipBeforeDate fields of the ship groups at ordermgr/control/editOrderItems disappear one at a time for each refresh. Another example of this happening is at ordermgr/control/EditQuote for the QuoteIssueDate field but oddly the ValidFromDate and ValidThruDate don't exhibit the behavior even though they are the same type of field. Also, the statusId field of the ordermgr/control/EditQuote also gets unset after the first refresh which may be related. I'm not sure if this behavior is isolated to the @htmlTemplate.renderDateTimeField or also occuring for form-widget date-time type=timestamp/ fields as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5865) Have the ability to generate a quote when request is of type 'Request for proposal'
[ https://issues.apache.org/jira/browse/OFBIZ-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201897#comment-14201897 ] Pierre Smits commented on OFBIZ-5865: - FYI If you want to read up on the differences AND the commonalities between the rfp (request for proposal) and the rfq (request for quotation) via following links: * http://en.wikipedia.org/wiki/Request_for_proposal * http://en.wikipedia.org/wiki/Request_for_quotation Have the ability to generate a quote when request is of type 'Request for proposal' --- Key: OFBIZ-5865 URL: https://issues.apache.org/jira/browse/OFBIZ-5865 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Pierre Smits Labels: RfP, quote, request Attachments: OFBIZ-5865-ORDER-Request-RfP-v2.patch, OFBIZ-5865-ORDER-Request-RfP.patch Currently the use can only generate a quote from the request screens when the request is of the type 'Request for Quote'. However, a request for proposal is in effect also a request for quote and therefor the user should also have the ability to generate a quote from the request when it is of type 'Request for proposal'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-5869) correction to changeset r1626462 and r1626463
Leon created OFBIZ-5869: --- Summary: correction to changeset r1626462 and r1626463 Key: OFBIZ-5869 URL: https://issues.apache.org/jira/browse/OFBIZ-5869 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Leon Fix For: Trunk There's error in this commit. e.g. – ListGenericValue allPCMPs = EntityUtil.filterByDate(delegator.findByAnd(PartyContactMechPurpose, pcmpFindMap, null, false), true); ++ allPCWPs = EntityUtil.filterByDate(allPCWPs, null, contactFromDate, contactThruDate, true); According to EntityUtil.filterByDate(List, EntityCondition, String, String ,Boolean), it filter nothing if condition parameter (the second) is null. see OFBIZ-5261. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-5869) correction to changeset r1626462 and r1626463
[ https://issues.apache.org/jira/browse/OFBIZ-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon updated OFBIZ-5869: Attachment: OFBIZ-5869.patch use now timestamp to replace null value. correction to changeset r1626462 and r1626463 Key: OFBIZ-5869 URL: https://issues.apache.org/jira/browse/OFBIZ-5869 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Leon Fix For: Trunk Attachments: OFBIZ-5869.patch There's error in this commit. e.g. – ListGenericValue allPCMPs = EntityUtil.filterByDate(delegator.findByAnd(PartyContactMechPurpose, pcmpFindMap, null, false), true); ++ allPCWPs = EntityUtil.filterByDate(allPCWPs, null, contactFromDate, contactThruDate, true); According to EntityUtil.filterByDate(List, EntityCondition, String, String ,Boolean), it filter nothing if condition parameter (the second) is null. see OFBIZ-5261. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201909#comment-14201909
]
Jacopo Cappellato commented on OFBIZ-5848:
--
Before the release 13.07.01 was issued I back ported a series of fixes to unit
tests in order to make them pass also with 1.7: tests should not be an issue in
13.07.
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-5261) Party contact expiration and its hidden problems
[
https://issues.apache.org/jira/browse/OFBIZ-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201499#comment-14201499
]
Leon edited comment on OFBIZ-5261 at 11/7/14 10:45 AM:
---
There's error in this commit. e.g.
-- ListGenericValue allPCMPs =
EntityUtil.filterByDate(delegator.findByAnd(PartyContactMechPurpose,
pcmpFindMap, null, false), true);
++ allPCWPs = EntityUtil.filterByDate(allPCWPs, null, contactFromDate,
contactThruDate, true);
According to EntityUtil.filterByDate(List, EntityCondition, String, String
,Boolean), it filter nothing if condition parameter (the second) is null.
ps: I have created an issue about this. OFBIZ-5869
was (Author: utcb):
There's error in this commit. e.g.
-- ListGenericValue allPCMPs =
EntityUtil.filterByDate(delegator.findByAnd(PartyContactMechPurpose,
pcmpFindMap, null, false), true);
++ allPCWPs = EntityUtil.filterByDate(allPCWPs, null, contactFromDate,
contactThruDate, true);
According to EntityUtil.filterByDate(List, EntityCondition, String, String
,Boolean), it filter nothing if condition parameter (the second) is null.
Party contact expiration and its hidden problems
Key: OFBIZ-5261
URL: https://issues.apache.org/jira/browse/OFBIZ-5261
Project: OFBiz
Issue Type: Bug
Components: accounting, order, party
Affects Versions: Release 09.04, Release 09.04.01, Release 10.04, Release
Branch 11.04, Trunk
Reporter: Sergei Biletnikov
Assignee: Ashish Vijaywargiya
Fix For: Release Branch 11.04, Upcoming Branch
Attachments: OFBIZ-5261.patch
I found a problem which can appear when you add new contact like postal
address and expiry old one, the old contact is still used by some code.
The cause of the problem is easy and clear.
To make it more clear, let me remind you that OFBiz has a smart contacts data
model, where each contact represents the contact data like address, phone
number and etc and contact purposes, which is responsible for the how to
apply the contact.
Regarding parties, the main entities here:
PartyContactMech (contact)
and
PartyContactMechPurpose (purpose)
All looks good.
However, both PartyContactMech and PartyContactMechPurpose have from and thru
date creterias,i.e. can be expired!
If you add a purpose to the contanct and after that you remove it, the
purpose will be expired (not deleted), that is ok for auditing.
RE: PartyContactMech, if you expire the contact,it means this contact
mechanism must be out from the game and not be visisble on the profile page.
The state of its purposes do not matter anymore, it must be not used.
But there is a problem here, some code takes into account
PartyContactMechPurpose and use date filter but ignores PartyContactMech
expiration state. This follows to the error: the contact is expired, the
purposes not, but the contact is still used!!!
Example:
\applications\order\webapp\ordermgr\WEB-INF\actions\order\CompanyHeader.groovy
addresses = delegator.findByAnd(PartyContactMechPurpose, [partyId :
partyId, contactMechPurposeTypeId : GENERAL_LOCATION]);
selAddresses = EntityUtil.filterByDate(addresses, nowTimestamp, fromDate,
thruDate, true);
phones = delegator.findByAnd(PartyContactMechPurpose, [partyId : partyId,
contactMechPurposeTypeId : PRIMARY_PHONE]);
...
only PartyContactMechPurpose ??? and it ignores that PartyContactMech is
already expired! The result : I see the expired contact on the order page.
\applications\accounting\src\org\ofbiz\accounting\payment\PaymentMethodServices.java
try {
ListGenericValue allPCMPs =
EntityUtil.filterByDate(delegator.findByAnd(PartyContactMechPurpose,
UtilMisc.toMap(partyId, partyId, contactMechId,
contactMechId, contactMechPurposeTypeId, contactMechPurposeTypeId), null),
true);
tempVal = EntityUtil.getFirst(allPCMPs);
} catch (GenericEntityException e) {
Debug.logWarning(e.getMessage(), module);
tempVal = null;
}
.
and again, we are interested only in PartyContactMechPurpose. The potential
problem is here.
I did not check the all code of OFBiz, it is just my fast search attempts.
How to solve the problem???
In my opinion, the data model looks ok, and it is ok when PartyContactMech is
expired, but its purposes are not. It does not break a sense and good for
auditing.
The good solution is to correct code and rely on both parties to find the
necessary contact/purpose, for example the PartyContactWithPurpose can be
used with contactFromDate, contactThruDate, purposeFromDate, purposeThruDate
accordingly. However, I do not know how is big the effort to do that in the
existing code.
The
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201917#comment-14201917
]
Jacques Le Roux commented on OFBIZ-5848:
Thanks NIcolas,
This is annoying indeed, did you try R12.04 with Java 6 and TLSv1.0?
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Security page in OFBTECH
Hi All, I have partially rewritten the Security page in OFBTECH https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+security+permissions I think it's now more clear. I have also added some comments about the situation with role limited permissions in a warning. Please review and comment if needed, thanks. I have still to review this pages and decided about them https://cwiki.apache.org/confluence/display/OFBTECH/Security+Services+-+Developer https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045135 Jacques
Re: How to use ProjectMgr in 13.07
This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- www.nereide.fr Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr http://www.nereide.fr
Re: How to use ProjectMgr in 13.07
Hi Jacques, Birt is definitely important for us Taher Alkhateeb On Nov 7, 2014 2:40 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- http://www.nereide.fr Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- Mail Attachment.jpeg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
Hi Jacopo, Well thought and a good suggestion IMHO. Definitely a good middle ground solution that supports all components and keeps things alive Taher Alkhateeb Taher Alkhateeb On Nov 7, 2014 3:05 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- Mail Attachment.jpeg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
I'm all for it, good idea! Jacques Le 07/11/2014 13:11, Taher Alkhateeb a écrit : Hi Jacopo, Well thought and a good suggestion IMHO. Definitely a good middle ground solution that supports all components and keeps things alive Taher Alkhateeb Taher Alkhateeb On Nov 7, 2014 3:05 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- Mail Attachment.jpeg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: Security page in OFBTECH
Since I can not edit these pages, here are some suggested changes to improve readability. Here security is about permissions granted to access OFBiz artifacts, like services, screen and data. could be Security, as discussed in this article, is about permissions being granted to access OFBiz artifacts such as services, screens and data. Category 2 (party permission, eg ORDERMGR_ROLE_CREATE) is*Party dependent*and can be combined with Category 1, usually with special *role limited* permissions that when checked require not just the permission, but some*relationship*between the Party and whatever records are concerned by the screen, service, or whatever. This lets quite open possibilities. could be Category 2 (party permission, eg ORDERMGR_ROLE_CREATE) is*Party dependent*and can be combined with Category 1, usually with special *role limited* permissions that require not just the permission, but some*relationship*between the Party and whatever artifact are being controlled. This supports quite a wide range of access control. It should be possible (in theory, not tested) to use the Category 1 without the party component. But the Category 2 is very dependent on the Party data model and whatever data model relates to it for the required relationships. It should be possible (in theory, not tested) to use Category 1 security without the party component. However, Category 2 is very dependent on the Party data object and the data object related to it. Note that a role limited permissions to work*requires*an enforcing relationship to be used. There are currently a number of cases in OFBiz where role limited permissions are used without enforcing relationships. For instance often the alt-permission tag is used in simple methods as if the role limited permission would complement the primary user permission when it's actually only redundant since the check-permission tag is not supposed to infer by itself what to do with this alternative permission. This is explained and discussed inthis dev ML thread http://markmail.org/message/4eivnpyarcemtxxq. Inthis other user ML thread http://markmail.org/message/si4yhvc57ra24joqa solution is proposed to prevent this to spread all over the code. Two other propositions has been discussed some years ago, notably thisOFBiz Security Redesign https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign. Note though that there are cases where the alternative permission could be used, but not with role limited permissions, only user permissions. For instance someone may not have the right to create all types of order but only sales orders. Then with the primary permission defined ORDERMGR_CREATE this person can't create a sales order but with the alternative permission defined as ORDERMGR_SALES_CREATE it's possible. As you see access permissions can be a very complex topic! Is the section in bold a warning. It seems that using role limited permissions are used without enforcing relationships is not a recommended practice but it is described here as part of role limited permissions with links to other references which are proposed as best practices. Perhaps this could, at least, be broken into 2 paragraphs and the description of using role limited permission with enforcing relationships described first and then the alternative of without discussed with proper cautionary notes. Perhaps clarifying the audience (new developer?) might make this section more readable and give the person a clear idea of how to do it right while explaining that they might encounter some less secure alternatives while looking at existing applications. A secure role limited permission scheme*requires*that an enforcing relationship be used. *There are currently a number of cases in OFBiz where role limited permissions are used without enforcing relationships. For instance often the alt-permission tag is used in simple methods as if the role limited permission would complement the primary user permission when it's actually redundant since the check-permission tag is not supposed to infer by itself what to do with this alternative permission. This is explained and discussed inthis dev ML thread http://markmail.org/message/4eivnpyarcemtxxq**. Inthis other user ML thread http://markmail.org/message/si4yhvc57ra24joqa solution is proposed to prevent this from spreading all over the code. Two other propositions have been discussed some years ago, notably thisOFBiz Security Redesign https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign**.* Also note that there are cases where the alternative permission could be used, but not with role limited permissions, only user permissions. For instance someone may not have the right to create all types of order but only sales orders. Then with the primary permission defined ORDERMGR_CREATE this person can't create a sales order but with the
[jira] [Commented] (OFBIZ-5853) The createPartyRole service does not check a duplicate key.
[ https://issues.apache.org/jira/browse/OFBIZ-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14202180#comment-14202180 ] Leon commented on OFBIZ-5853: - search createPartyRole throughout project, more than 100 matched results there. If the behavior of this function changes, then it may affects most of them, the createPartyRelationshipContactAccount” mentioned here is just one of them. The createPartyRole service does not check a duplicate key. --- Key: OFBIZ-5853 URL: https://issues.apache.org/jira/browse/OFBIZ-5853 Project: OFBiz Issue Type: Bug Components: party Affects Versions: Trunk Reporter: Supatthra Nawicha Assignee: Nicolas Malin Priority: Minor Fix For: Trunk Attachments: OFBIZ-5853.patch, OFBIZ-5853.patch, ofbizbug_CreatePartyroleService.diff The createPartyRole service is changed from minilang to entity-auto which does not check a duplicate key. It effect to the createPartyRelationshipContactAccount service which call the createPartyRole service without check a duplicate key. And it might effect to other code that call the createPartyRole service as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: How to use ProjectMgr in 13.07
I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to
[jira] [Created] (OFBIZ-5870) Birt doesn't work
Leon created OFBIZ-5870:
---
Summary: Birt doesn't work
Key: OFBIZ-5870
URL: https://issues.apache.org/jira/browse/OFBIZ-5870
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/birt
Affects Versions: Trunk
Reporter: Leon
Fix For: Trunk
Birt report does't work anymore.
access following url: [http://demo-trunk-ofbiz.apache.org/birt/control/Report].
error cut out :
{quote}
FreeMarker template error: Could not find an instance of
freemarker.ext.servlet.ServletContextHashModel in the data model under either
the name __FreeMarkerServlet.Application__ or Application FTL stack trace
(~ means nesting-related): - Failed at: @birt.report id=birtReport
reportDe... [in template component://birt/webapp/birt/birt/chartReport.ftl at
line 22, column 1] Java stack trace (for programmers):
freemarker.template.TemplateModelException: [... Exception message was already
printed; see it above ...] at
freemarker.ext.jsp.FreeMarkerPageContext.init(FreeMarkerPageContext.java:92)
at
freemarker.ext.jsp._FreeMarkerPageContext21.init(_FreeMarkerPageContext21.java:53)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5870) Birt doesn't work
[
https://issues.apache.org/jira/browse/OFBIZ-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14202210#comment-14202210
]
Leon commented on OFBIZ-5870:
-
workaround:
* revert the commit r1621801
[https://fisheye6.atlassian.com/changelog/ofbiz?cs=1621801], since
ServletContextHashModel is being used by Birt, not the unused stuff.
* revert the commit r1621953 to ControlServlet.java
[https://fisheye6.atlassian.com/changelog/ofbiz?cs=1621953] to import necessary
packages
* add commons-discovery-0.4.jar back to framework/base/lib/commons, or add it
to specialpurpose/birt/lib folder, since it's depended by axis-1.4
[https://fisheye6.atlassian.com/changelog/ofbiz?cs=1623042]
Birt doesn't work
-
Key: OFBIZ-5870
URL: https://issues.apache.org/jira/browse/OFBIZ-5870
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/birt
Affects Versions: Trunk
Reporter: Leon
Fix For: Trunk
Birt report does't work anymore.
access following url:
[http://demo-trunk-ofbiz.apache.org/birt/control/Report].
error cut out :
{quote}
FreeMarker template error: Could not find an instance of
freemarker.ext.servlet.ServletContextHashModel in the data model under either
the name __FreeMarkerServlet.Application__ or Application FTL stack
trace (~ means nesting-related): - Failed at: @birt.report id=birtReport
reportDe... [in template component://birt/webapp/birt/birt/chartReport.ftl
at line 22, column 1] Java stack trace (for programmers):
freemarker.template.TemplateModelException: [... Exception message was
already printed; see it above ...] at
freemarker.ext.jsp.FreeMarkerPageContext.init(FreeMarkerPageContext.java:92)
at
freemarker.ext.jsp._FreeMarkerPageContext21.init(_FreeMarkerPageContext21.java:53)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: How to use ProjectMgr in 13.07
I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what
Re: How to use ProjectMgr in 13.07
Hi All, I agree that hot-deploy component don't have to be installed with the core project by default. But in the other hand it could be interesting to be aware of those projects. When I read this topics, it seems matching with an extension manager... French community is working on this extension manager project maybe it could be the way to split specific OFBiz extension and the core project ? Am I wrong ? Julien. Le 07/11/2014 17:32, Adrian Crum a écrit : I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization
Re: How to use ProjectMgr in 13.07
I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization
Re: How to use ProjectMgr in 13.07
I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled
Re: How to use ProjectMgr in 13.07
Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the
Re: How to use ProjectMgr in 13.07
Taher Alkhateeb raised some valid concerns. My take (also as a newcomer) is that there is a high barrier to entry for people working on the framework and this makes it hard to get new people into the OFBiz project. By creating sub-projects that have a much smaller scope and do not have any affect on the overall robustness of the system, we would allow new people to take on tasks that have a much narrower scope and are more in-line withtheir abilities and interests. It will also allow OFBiz to attract subject matter experts on certain areas such as the BIRT language, data analysis, project management or manufacturing who are not attracted to the framework development tasks. The current level of complexity forces the group to be a small band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I
Re: How to use ProjectMgr in 13.07
I still think you're putting the cart before the horse. I'm not sure I could name any specialpurpose component that has the two or three active contributors that I think would be necessary to sustain it. If you have only one or two and they go away then what happens to any new comers looking to contribute? Do we just make anyone who comes along a committer? Does the TLP PMC need to monitor a whole bunch of new mailing lists and then support anyone who comes along in the hope they might be able to become committers? If a component had no active committers how long would it be before it broke completely because no one kept it updated? If a security vulnerability is found then who will deal with it? Without active committers the PMC would need to remain familiar with the code in order to receive contributions and determine their suitability for inclusion. Nothing would be different from now except that the component would be less visible to us, more easily forgotten and we'd have more infrastructure to deal with. You can look only at the best case scenarios because you won't have any responsibility to these sub-projects. The PMC however will still have the burden to do anything that the sub-project committers decide that they themselves no longer want to do. At what point will it be okay by you for us to kill it off? What is it that currently gives you confidence that it won't happen very quickly? I think Jacopo's solution is the best to keep everyone happy (including the vocal minority) but IMO the best approach would be to remove the components from OFBiz altogether, set them up on github or similar, ensure those who want to take ownership have the required access and then advertise the existence of these special purpose components from the OFBiz website. The components are then free to stand or fall as they may. Should any actually survive and thrive, then a subproject would seem like a good idea. It's my opinion though that the vast majority of the components would go dormant and I don't think it makes a difference whether it's as a subproject or as an external project hosted elsewhere. Regards Scott On 8/11/2014, at 9:21 am, Ron Wheeler rwhee...@artifact-software.com wrote: Taher Alkhateeb raised some valid concerns. My take (also as a newcomer) is that there is a high barrier to entry for people working on the framework and this makes it hard to get new people into the OFBiz project. By creating sub-projects that have a much smaller scope and do not have any affect on the overall robustness of the system, we would allow new people to take on tasks that have a much narrower scope and are more in-line withtheir abilities and interests. It will also allow OFBiz to attract subject matter experts on certain areas such as the BIRT language, data analysis, project management or manufacturing who are not attracted to the framework development tasks. The current level of complexity forces the group to be a small band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without
Re: How to use ProjectMgr in 13.07
The barrier to working on the framework is a technical one. Anyone wanting to work on the framework must understand these things: 1. OFBiz design philosophy and its high-level design. 2. Design patterns (ie GOF). 3. Concurrency (database and Java). 4. Commit history. It would be wonderful if more people would get involved in the framework. It just takes a bit of research, and a little time asking questions from those who have been working on it for a while. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 8:21 PM, Ron Wheeler wrote: Taher Alkhateeb raised some valid concerns. My take (also as a newcomer) is that there is a high barrier to entry for people working on the framework and this makes it hard to get new people into the OFBiz project. By creating sub-projects that have a much smaller scope and do not have any affect on the overall robustness of the system, we would allow new people to take on tasks that have a much narrower scope and are more in-line withtheir abilities and interests. It will also allow OFBiz to attract subject matter experts on certain areas such as the BIRT language, data analysis, project management or manufacturing who are not attracted to the framework development tasks. The current level of complexity forces the group to be a small band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly
[jira] [Commented] (OFBIZ-5706) Parties can't be assigned to production run tasks
[ https://issues.apache.org/jira/browse/OFBIZ-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203240#comment-14203240 ] Arun Patidar commented on OFBIZ-5706: - Hi [~pfm.smits], Please provide more details about the issue. Steps to regenerate and any additonal details can help. Parties can't be assigned to production run tasks - Key: OFBIZ-5706 URL: https://issues.apache.org/jira/browse/OFBIZ-5706 Project: OFBiz Issue Type: Bug Components: manufacturing Affects Versions: Release Branch 11.04, Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Pierre Smits It is not possible to assign parties to execute one or more task in a production run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203275#comment-14203275
]
Jacopo Cappellato commented on OFBIZ-5848:
--
As regards the 13.07 branch I would start by converting the ant scripts to
require java 7; our download page already warn that it is a requirement and
shouldn't be a huge deal; when we will announce the 13.07.02 release we could
still warn again about the requirement about java 7.
We could consider 11.04 an unsupported branch.
As regards 12.04: we should figure out if there is something we can do to
enable TLS, or we could:
1) anticipate the end of life of the release branch
2) publish a final release with the upgrade to Java 7: it should be used only
by users that can't upgrade to 13.07 but are ready to upgrade their production
instances to java 7
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-5793) modify logic to only run expiry service once when subscription expires
[ https://issues.apache.org/jira/browse/OFBIZ-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Cauchi updated OFBIZ-5793: --- Attachment: OFBIZ-5793.v3.patch modify logic to only run expiry service once when subscription expires -- Key: OFBIZ-5793 URL: https://issues.apache.org/jira/browse/OFBIZ-5793 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Trunk Environment: not relevant Reporter: Ivan Cauchi Assignee: Jacopo Cappellato Priority: Minor Labels: subscription Fix For: Trunk Attachments: OFBIZ-5793.patch, OFBIZ-5793.v3.patch Original Estimate: 672h Remaining Estimate: 672h Background --- Recenlty, the trunk version of OFBiz was augmented with a new service called runServiceUponSubscriptionExpiry through JIRA5333. This service is scheduled to run, using the demo data, once a day. Its algorithm looks up all subscriptions which have expired, which is defined as the current time being greater than the sum of the subscription.thruDate + subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is false. For all such subscriptions, the service runs any service named in SubscriptionResource.serviceNameOnExpiry. This provides users of the OFBiz framework who provide subscriptions to their customers using the framework, to trigger an external deprovisioning action when a subscription expires, implemented as a service whose name is inserted into SubscriptionResource.serviceNameOnExpiry. Currently, the service mentioned in SubscriptionResource.serviceNameOnExpiry is run every time the master service runServiceUponSubscriptionExpiry goes through its algorithm (once a day in the demo data). Typically, for subscriptions which require a deprovisioning action when the subscription expired, one and only one deprovisioning action would be required. proposed solution --- To resolve this, it is being proposed to make the following adjustments: a) augment the OFBiz data model with the following new field: Subscription.expirationCompletedDate b) modify the algorithm of runServiceUponSubscriptionExpiry to also check whether the expiry service has already run, by checking that expirationCompletedDate is null. - if expirationCompletedDate is null (and the other conditions are satisfied), run the service in SubscriptionResource.serviceNameOnExpiry and update the date/time into expirationCompletedDate - if expirationCompletedDate is not null, skip the expired subscription and move to the next Testing - 1. create a new subscription through OFBiz with demo data 2. modify the subscription's thru date and gracePeriodOnExpiry so the result of their addition is in the past of the system date 3. verify that Subscription.expirationCompletedDate is empty 4. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually 5. verify that the log file contains a reference to the subscription having expired, and that Subscription. expirationCompletedDate contains the date/time the service was run 6. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually, for a second time 7. verify that the log file does not contain a reference to the subscription having expired, and that Subscription.expirationCompletedDate still contains the date/time the service was run -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5793) modify logic to only run expiry service once when subscription expires
[ https://issues.apache.org/jira/browse/OFBIZ-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203293#comment-14203293 ] Ivan Cauchi commented on OFBIZ-5793: Hi Jacopo updated patch has been uploaded. thanks Ivan modify logic to only run expiry service once when subscription expires -- Key: OFBIZ-5793 URL: https://issues.apache.org/jira/browse/OFBIZ-5793 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Trunk Environment: not relevant Reporter: Ivan Cauchi Assignee: Jacopo Cappellato Priority: Minor Labels: subscription Fix For: Trunk Attachments: OFBIZ-5793.patch, OFBIZ-5793.v3.patch Original Estimate: 672h Remaining Estimate: 672h Background --- Recenlty, the trunk version of OFBiz was augmented with a new service called runServiceUponSubscriptionExpiry through JIRA5333. This service is scheduled to run, using the demo data, once a day. Its algorithm looks up all subscriptions which have expired, which is defined as the current time being greater than the sum of the subscription.thruDate + subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is false. For all such subscriptions, the service runs any service named in SubscriptionResource.serviceNameOnExpiry. This provides users of the OFBiz framework who provide subscriptions to their customers using the framework, to trigger an external deprovisioning action when a subscription expires, implemented as a service whose name is inserted into SubscriptionResource.serviceNameOnExpiry. Currently, the service mentioned in SubscriptionResource.serviceNameOnExpiry is run every time the master service runServiceUponSubscriptionExpiry goes through its algorithm (once a day in the demo data). Typically, for subscriptions which require a deprovisioning action when the subscription expired, one and only one deprovisioning action would be required. proposed solution --- To resolve this, it is being proposed to make the following adjustments: a) augment the OFBiz data model with the following new field: Subscription.expirationCompletedDate b) modify the algorithm of runServiceUponSubscriptionExpiry to also check whether the expiry service has already run, by checking that expirationCompletedDate is null. - if expirationCompletedDate is null (and the other conditions are satisfied), run the service in SubscriptionResource.serviceNameOnExpiry and update the date/time into expirationCompletedDate - if expirationCompletedDate is not null, skip the expired subscription and move to the next Testing - 1. create a new subscription through OFBiz with demo data 2. modify the subscription's thru date and gracePeriodOnExpiry so the result of their addition is in the past of the system date 3. verify that Subscription.expirationCompletedDate is empty 4. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually 5. verify that the log file contains a reference to the subscription having expired, and that Subscription. expirationCompletedDate contains the date/time the service was run 6. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually, for a second time 7. verify that the log file does not contain a reference to the subscription having expired, and that Subscription.expirationCompletedDate still contains the date/time the service was run -- This message was sent by Atlassian JIRA (v6.3.4#6332)
