[jira] Commented: (OFBIZ-2798) ecommerce screen shows error after loading only seed data

[BJ Freeman (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856774#action_12856774
 ] 

BJ Freeman commented on OFBIZ-2798:
---

 showing what went wrong would take a book.
and that is where I suggest such information is handle.
like when you use the script to give admin log in,
it is not associated with a partyID so the myportal does not work.

that is why the suggestion to modify the demo data before installation is 
recommended.

> ecommerce screen shows error after loading only seed data
> -
>
> Key: OFBIZ-2798
> URL: https://issues.apache.org/jira/browse/OFBIZ-2798
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 9.04
>Reporter: chris snow
> Attachments: ecommerce_store_9.04.patch, Screenshot.png
>
>
> Step 1 - load only seed data
> Step 2 - open url - http://localhost:8080/ecommerce/control/main
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://ecommerce/widget/CartScreens.xml#minipromotext]: 
> java.lang.NullPointerException: Cannot invoke method size() on null object 
> (Cannot invoke method size() on null object)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Post migration issues for resources managed by ASF Infra: Confluence

[BJ Freeman]

are we talking about who can contribute to sections or merging the
information.
on merging the information, as long as they are separate section from
the readers point of view then ok. but putting them under one heading
would be very confusing and make finding information harder.



=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin



Jacopo Cappellato sent the following on 4/13/2010 11:41 PM:
> A few more information on the current Confluence setup.
> 
> We have 5 spaces:
> 
> 1) Wiki
> 2) End User Docs
> 3) Tech Docs
> 4) Requirements And Design
> 5) Project Admin
> 
> Do we really need all of them?
> In my opinion we could merge #2 with #3; we could also merge them with #4 and 
> have the following setup:
> 1) Wiki: open to everyone
> 2+3+4) End User, Tech Docs and Requirements: moderated and restricted to 
> contributors (e.g. committers or people that ask for permissions to 
> contribute on documentation)
> 5) Project Admin: only PMC members (this is an extension of the static html 
> pages of the website)
> 
> Jacopo
> 
> On Apr 14, 2010, at 7:48 AM, Jacopo Cappellato wrote:
> 
>> Could you please help to get a summary of the issues that we see after the 
>> migration to our Confluence spaces to ASF Infra?
>>
>> The main ones I see are:
>>
>> 1) we need a custom header (with navigation links) similar to the one we 
>> have on our site home page
>> 2) the search box in Confluence should search only inside of the OFBiz spaces
>>
>> If you also have suggestions on how to fix them, they are welcome!
>>
>> As soon as we have a list we will contact (if needed) the Infra team and 
>> work with them to resolve the issues.
>>
>> Kind regards,
>>
>> Jacopo
> 
> 

Re: Post migration issues for resources managed by ASF Infra: Confluence

[Jacopo Cappellato]

A few more information on the current Confluence setup.

We have 5 spaces:

1) Wiki
2) End User Docs
3) Tech Docs
4) Requirements And Design
5) Project Admin

Do we really need all of them?
In my opinion we could merge #2 with #3; we could also merge them with #4 and 
have the following setup:
1) Wiki: open to everyone
2+3+4) End User, Tech Docs and Requirements: moderated and restricted to 
contributors (e.g. committers or people that ask for permissions to contribute 
on documentation)
5) Project Admin: only PMC members (this is an extension of the static html 
pages of the website)

Jacopo

On Apr 14, 2010, at 7:48 AM, Jacopo Cappellato wrote:

> Could you please help to get a summary of the issues that we see after the 
> migration to our Confluence spaces to ASF Infra?
> 
> The main ones I see are:
> 
> 1) we need a custom header (with navigation links) similar to the one we have 
> on our site home page
> 2) the search box in Confluence should search only inside of the OFBiz spaces
> 
> If you also have suggestions on how to fix them, they are welcome!
> 
> As soon as we have a list we will contact (if needed) the Infra team and work 
> with them to resolve the issues.
> 
> Kind regards,
> 
> Jacopo

[jira] Updated: (OFBIZ-2798) ecommerce screen shows error after loading only seed data

[chris snow (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chris snow updated OFBIZ-2798:
--

Attachment: ecommerce_store_9.04.patch

> ecommerce screen shows error after loading only seed data
> -
>
> Key: OFBIZ-2798
> URL: https://issues.apache.org/jira/browse/OFBIZ-2798
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 9.04
>Reporter: chris snow
> Attachments: ecommerce_store_9.04.patch, Screenshot.png
>
>
> Step 1 - load only seed data
> Step 2 - open url - http://localhost:8080/ecommerce/control/main
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://ecommerce/widget/CartScreens.xml#minipromotext]: 
> java.lang.NullPointerException: Cannot invoke method size() on null object 
> (Cannot invoke method size() on null object)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (OFBIZ-2798) ecommerce screen shows error after loading only seed data

[chris snow (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chris snow reopened OFBIZ-2798:
---


it would be useful to users to show them an error message stating how they have 
incorrectly setup ofbiz

> ecommerce screen shows error after loading only seed data
> -
>
> Key: OFBIZ-2798
> URL: https://issues.apache.org/jira/browse/OFBIZ-2798
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 9.04
>Reporter: chris snow
> Attachments: ecommerce_store_9.04.patch, Screenshot.png
>
>
> Step 1 - load only seed data
> Step 2 - open url - http://localhost:8080/ecommerce/control/main
> :ERROR MESSAGE:
> org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
> [component://ecommerce/widget/CartScreens.xml#minipromotext]: 
> java.lang.NullPointerException: Cannot invoke method size() on null object 
> (Cannot invoke method size() on null object)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Post migration issues for resources managed by ASF Infra: Confluence

[Ashish Vijaywargiya]

Thanks so much Jacopo for taking initiative of this thread.
It would be of great help if point # 2 is sorted out with the help of Infra.

I am thinking more on this and will get back to you ASAP.

--
Ashish

On Wed, Apr 14, 2010 at 11:18 AM, Jacopo Cappellato
 wrote:
> Could you please help to get a summary of the issues that we see after the 
> migration to our Confluence spaces to ASF Infra?
>
> The main ones I see are:
>
> 1) we need a custom header (with navigation links) similar to the one we have 
> on our site home page
> 2) the search box in Confluence should search only inside of the OFBiz spaces
>
> If you also have suggestions on how to fix them, they are welcome!
>
> As soon as we have a list we will contact (if needed) the Infra team and work 
> with them to resolve the issues.
>
> Kind regards,
>
> Jacopo

Post migration issues for resources managed by ASF Infra: Confluence

[Jacopo Cappellato]

Could you please help to get a summary of the issues that we see after the 
migration to our Confluence spaces to ASF Infra?

The main ones I see are:

1) we need a custom header (with navigation links) similar to the one we have 
on our site home page
2) the search box in Confluence should search only inside of the OFBiz spaces

If you also have suggestions on how to fix them, they are welcome!

As soon as we have a list we will contact (if needed) the Infra team and work 
with them to resolve the issues.

Kind regards,

Jacopo

Technical setup dock

[BJ Freeman]

I notice is says an 1.6 or later.
Since ofbiz ant script uses its own version of ant and the
trunk is currently using 1.7.2
should we distinguish between the 9.04 (1.6) and trunk (1.7.2) in the
setup, or put in instructions how to upgrade ant for 9.04 in ofbiz?
i say this because those that use 9.04 will be asking how to upgrade to
1.7.2

=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin

[jira] Commented: (OFBIZ-3695) open symphony work flow in ofbiz

[Ashish Vijaywargiya (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856745#action_12856745
 ] 

Ashish Vijaywargiya commented on OFBIZ-3695:


For more details on Mailing list please refer link: 
https://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists

--
Ashish

> open symphony  work flow in ofbiz
> -
>
> Key: OFBIZ-3695
> URL: https://issues.apache.org/jira/browse/OFBIZ-3695
> Project: OFBiz
>  Issue Type: New Feature
>  Components: humanres
>Affects Versions: Release Branch 4.0
>Reporter: Anurag
>
> I want to implement work flow open symphony for humanres.
> if u have any idea to configure this with ofbiz then please suggest me how to 
> configure it.
> Thanks in advance
> Regards
> Anurag Walia

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OFBIZ-3696) order Requirment

[Anurag (JIRA)]

order Requirment


 Key: OFBIZ-3696
 URL: https://issues.apache.org/jira/browse/OFBIZ-3696
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Release Branch 4.0
 Environment: win xp , jdk 1.5.13
Reporter: Anurag


Hi all,
I have a problem with order->requirement. 
After creating a requirement of  type INTERNAL REQUIREMENT.
approve requirement giving an error like

The Following Errors Occurred:

Error calling event: org.ofbiz.webapp.event.EventHandlerException: Commit 
multi-service global transaction failed

while other type PRODUCT REQUIREMENT  working fine


Regard 
Anurag Walia

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (OFBIZ-3695) open symphony work flow in ofbiz

[Scott Gray (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Gray closed OFBIZ-3695.
-

Resolution: Invalid

Please use the user mailing list for such questions

> open symphony  work flow in ofbiz
> -
>
> Key: OFBIZ-3695
> URL: https://issues.apache.org/jira/browse/OFBIZ-3695
> Project: OFBiz
>  Issue Type: New Feature
>  Components: humanres
>Affects Versions: Release Branch 4.0
>Reporter: Anurag
>
> I want to implement work flow open symphony for humanres.
> if u have any idea to configure this with ofbiz then please suggest me how to 
> configure it.
> Thanks in advance
> Regards
> Anurag Walia

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OFBIZ-3695) open symphony work flow in ofbiz

[Anurag (JIRA)]

open symphony  work flow in ofbiz
-

 Key: OFBIZ-3695
 URL: https://issues.apache.org/jira/browse/OFBIZ-3695
 Project: OFBiz
  Issue Type: New Feature
  Components: humanres
Affects Versions: Release Branch 4.0
Reporter: Anurag


I want to implement work flow open symphony for humanres.
if u have any idea to configure this with ofbiz then please suggest me how to 
configure it.

Thanks in advance

Regards
Anurag Walia

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Library upgrades before next release branch

[Adam Heath]

Erwan de FERRIERES wrote:
> Le 09/04/2010 18:05, Adam Heath a écrit :
>> Can we all try to start upgrading any of our embedded libraries to the
>> latest official releases(or some svn snapshot), before the next
>> release branch is created?
>>
>> If a library we use requires a version that hasn't been officially
>> released, at the very least, it must exist upstream as some revision
>> control version.  Any local changes applied to a library should not be
>> allowed.
>>
> 
> From my POV, I just have to push a new Tomcat version
> (https://issues.apache.org/jira/browse/OFBIZ-3424). It has not been
> tested Maybe I can try to make it go to the latest (6.0.26).
> 
> When do you want me to start ?

Anytime you want.  This was more a call for all of us to look at all
the libraries to see which ones any of us could look after.

[jira] Commented: (OFBIZ-3633) Minimum order quantity

[BJ Freeman (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856675#action_12856675
 ] 

BJ Freeman commented on OFBIZ-3633:
---

Bob
the pages you refer to are for company to Manufacture a product then have 
supplier (distributors) sell that product.
this is different than order from a supplier to get raw materials. order and 
order from a customer
covered on page 107 and 109.

I like Jacopo's suggestion  to use the Agreements
from the datamodel book
"An agreement is a set of terms and conditions that govern relationships 
between two parties."
also
You can have product agreements where each product can have this relationship 
both for customers and suppliers.with the company

> Minimum order quantity
> --
>
> Key: OFBIZ-3633
> URL: https://issues.apache.org/jira/browse/OFBIZ-3633
> Project: OFBiz
>  Issue Type: New Feature
>  Components: order, specialpurpose/ecommerce
>Reporter: Rishi Solanki
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3633.patch, OFBIZ-3633.patch
>
>
> It will work as follows;
> We will set the special type price as 'MINIMUM_ORDER_PRICE' for a Product in 
> ProductPrice entity. On the basis of it we will get the minimum order 
> quantity of the product on the basis of this price and sale price.
> Will get the minimum order quantity for product by division. For example we 
> have selling price of product P1 is $10.00 and its MINIMUM_ORDER_PRICE is 
> $100.00 then minimum order quantity for the product will be --> 100/10 ==> 10.
> To achieve the above ;
> write a getMinimumOrderQuantity() method in ShoppingCart.java which takes the 
> itemBasePrice and productId as in parameter, and call it where we add, update 
> the cart items and change the quantity to minmumOrderQuantity if it is less 
> then minimum.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Purchase Order Items - Supplier Product ID & Supplier Product Name

[BJ Freeman]

also
Data model book Vol I
Page 107 calls out sales order line item and purchase order line item as
reveferencing the Product.

you will note on page 82 that the supplierProduct does not cover a
product but additional information related to the supplier. However
ofbiz has information in the supplierproduct that is from the product
entity.

so now we run into the problem

so the question is do we get the datamodel correct or do we kluge

=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin



BJ Freeman sent the following on 4/13/2010 1:01 PM:
> Data model book Vol I page 126 calls out an PO Item and a Salesorder item.
> 
> =
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation 
> 
> Specialtymarket.com 
> 
> Systems Integrator-- Glad to Assist
> 
> Chat  Y! messenger: bjfr33man
> Linkedin
> 
> 
> 
> Joe Eckard sent the following on 4/13/2010 12:14 PM:
>> When an order item is created for a Purchase Order, its' description is
>> set to "${supplierProductId} - ${supplierProductName}".
>>
>> When talking to external systems and when creating custom PDFs, I need
>> to access these values separately. Right now I use two order item
>> attributes (supplierProductId and supplierProductName), but I am trying
>> to reduce the number of our customizations.
>>
>> Would there be any objections to creating a new field
>> "supplierProductId" on the OrderItem entity and using that when creating
>> POs, leaving the order item description as the supplier's product name?
> 
> 
> 

Re: "Magically" converted types from simpleTypeConvert

[Bob Morley]

Scott Gray-2 wrote:
> 
> Firstly and without verifying, the automatic conversion sounds wrong and
> yes I'm quite sure it intentional never used to be that way.
> 
> Secondly, I'm not sure why quantityToProduce is a floating point instead
> of a fixed point data type.  I'm surprised and can't imagine why I skipped
> these when I was doing the double -> BigDecimal conversion of everything.
> 

A HA!  Ok I did more digging and it appears that the call to
ModelService.makeValid would always do these type of conversions
"magically".  I suspect the main intent here was to take a context that may
or may not exactly match a service definition (parms & parm types) and
select the desirable parameters into a new context that can be used for
invocation.  There is no difference between the old and new in terms of this
method being called.

However, there appears to be some problem code, here it is from
ServiceDispatcher ...

if (UtilValidate.isNotEmpty(origService.permissionServiceName)) {
...
if (hasPermission.booleanValue()) {
context.putAll(permResp);
context = origService.makeValid(context,
ModelService.IN_PARAM);

Effectively what happens is if a ModelService has a permissionServiceName,
it will invoke that permission and if it is successful it adds the
permission response to the context and converts it to match the service that
will be invoked.  I suspect this gives us the ability to have the service
permission provide arguments to the underlying service.

Someone on our team overrode the "createWorkEffort" and removed the
permissionServiceName.  So this code would not execute, we had the context
with the Double in it, and service dispatcher produced the standard
violation.

My suggestion is we change this code to make use of
ServiceUtil.setServiceFields, something like this ...

Map permRespContext = ServiceUtil.setServiceFields(dctx,
serviceName, permResp);
context.putAll(permRespContext);

Effectively, we would take the permission response and grab the things from
it that match our service signature and then add those to the context (and
ultimately return it).  This would ensure that only replaces are added
without impacting anything else.  The second part to this would be either
changing WorkEffort to use BigDecimal OR change the service implementation
to pass in a Double when invoking those services.

Make sense?
-- 
View this message in context: 
http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1839077.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Closed: (OFBIZ-3490) Create theme build script

[BJ Freeman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BJ Freeman closed OFBIZ-3490.
-

Fix Version/s: SVN trunk
   Resolution: Fixed

I see a create-theme in the build
can not find the commit for it so can not reference when it was put in.
so closing this issue.


> Create theme build script
> -
>
> Key: OFBIZ-3490
> URL: https://issues.apache.org/jira/browse/OFBIZ-3490
> Project: OFBiz
>  Issue Type: New Feature
>Affects Versions: Release Branch 9.04, SVN trunk
> Environment: ant build
>Reporter: BJ Freeman
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: themebutildpatch.txt, themesbuild.txt
>
>
> I liked the build script for a new component, so I decided to make one for 
> themes.
> unfortunately I am not able to do a patch so included the script.
> I made it so you can pick a  theme as the template and copy the files over to 
> the new theme.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (OFBIZ-3424) Upgrade Tomcat version to 6.0.24

[BJ Freeman (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856643#action_12856643
 ] 

BJ Freeman commented on OFBIZ-3424:
---

I was going to test this on centos 5.4
I notice that there are additional files
do we use all of these or should I just replace the ones in the catalina\lib


> Upgrade Tomcat version to 6.0.24
> 
>
> Key: OFBIZ-3424
> URL: https://issues.apache.org/jira/browse/OFBIZ-3424
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: SVN trunk
>Reporter: Erwan de FERRIERES
>Priority: Blocker
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3424.diff, tomcat-6.0.24-annotations-api.jar, 
> tomcat-6.0.24-catalina-ha.jar, tomcat-6.0.24-catalina-tribes.jar, 
> tomcat-6.0.24-catalina.jar, tomcat-6.0.24-el-api.jar, 
> tomcat-6.0.24-jasper-el.jar, tomcat-6.0.24-jasper-jdt.jar, 
> tomcat-6.0.24-jasper.jar, tomcat-6.0.24-jsp-api.jar, 
> tomcat-6.0.24-servlet-api.jar, tomcat-6.0.24-tomcat-coyote.jar, 
> tomcat-6.0.24-tomcat-dbcp.jar, tomcat-6.0.24-tomcat-juli.jar
>
>
> 3 security issues have been released today for Tomcat, asking to migrate to 
> the latest version :
> CVE-2009-2902: Apache Tomcat unexpected file deletion in work directory
> CVE-2009-2901: Apache Tomcat insecure partial deploy after failed undeploy
> CVE-2009-3548: Apache Tomcat unexpected file deletion and/or alteration

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3586) application - manufacturing

[Bob Morley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bob Morley updated OFBIZ-3586:
--

Attachment: (was: OFBIZ-3586_ResolveWarningsManufacturing.patch)

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3586) application - manufacturing

[Bob Morley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bob Morley updated OFBIZ-3586:
--

Attachment: OFBIZ-3586_ResolveWarningsManufacturing.patch

Corrected patch.

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r933766 - /ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutEvents.java

[Scott Gray]

Hi Joe,

It looks like you've just changed a default that could already be overridden by 
setting an attribute on the cart.  Could you explain a little more?

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 14/04/2010, at 7:43 AM, eckar...@apache.org wrote:

> Author: eckardjf
> Date: Tue Apr 13 19:43:46 2010
> New Revision: 933766
> 
> URL: http://svn.apache.org/viewvc?rev=933766&view=rev
> Log:
> allow bypassing the additional party step of purchase order entry when 
> finalizeReqAdditionalParty=false
> 
> Modified:
>
> ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutEvents.java
> 
> Modified: 
> ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutEvents.java
> URL: 
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutEvents.java?rev=933766&r1=933765&r2=933766&view=diff
> ==
> --- 
> ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutEvents.java
>  (original)
> +++ 
> ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutEvents.java
>  Tue Apr 13 19:43:46 2010
> @@ -979,7 +979,6 @@ public class CheckOutEvents {
> if (cart.getOrderType().equals("PURCHASE_ORDER")) {
> // Force checks for the following
> requireCustomer = true; requireShipping = true; requireOptions = 
> true;
> -requireAdditionalParty = true;
> processOrder = new String[] {"customer", "term", "shipping", 
> "shipGroups", "options", "payment",
>  "addparty", "paysplit"};
> }
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

[jira] Commented: (OFBIZ-3586) application - manufacturing

[Bob Morley (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856595#action_12856595
 ] 

Bob Morley commented on OFBIZ-3586:
---

Please hold off on this one -- I attached the patch as I was building / testing 
via ant and there were a few compilation issues related to generic checking 
(differences between Eclipse building and ant building).  Will resolve and 
provide a replacement attachment.

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: "Magically" converted types from simpleTypeConvert

[Scott Gray]

Firstly and without verifying, the automatic conversion sounds wrong and yes 
I'm quite sure it intentional never used to be that way.

Secondly, I'm not sure why quantityToProduce is a floating point instead of a 
fixed point data type.  I'm surprised and can't imagine why I skipped these 
when I was doing the double -> BigDecimal conversion of everything.

Regards
Scott

On 14/04/2010, at 6:50 AM, Bob Morley wrote:

> We have just started to make use of ProductionRun in our project and we were
> having a problem in the create because the ProductionRunServices (around
> line 274) makes a call to "createWorkEffort" using a "quantityToProduce"
> that is a BigDecimal.  The field on the WorkEffort entity is actually a
> Double, so in our solution it was causing a "bad type error" and failing.
> 
> I jumped to trunk to try to figure out why it was working in stock Ofbiz. 
> After some digging, it turns out that the conversion enhancements now
> (appear to) silently do this conversion, resulting in a context that
> contains that field as a Double.
> 
> This happens because the ServiceDispatcher's runSync method calls
> "checkAuth" which (if the user can call the service) calls
> ModelService.makeValid which ultimately calls ObjectType.simpleTypeConvert
> that handles the BigDecimal -> Double conversion.
> 
> Is this the intended behavior?  To be honest, it seems to me that the
> complaint that the parameter was not the proper data type was more
> desirable.  I understand that when we are handling a postback, values need
> to be converted from String to their desired types; but if I am making a
> call in our back-end to another service I would think I should be forced to
> adhere to that service definition's signature.
> -- 
> View this message in context: 
> http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1838891.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.



smime.p7s
Description: S/MIME cryptographic signature

Re: Purchase Order Items - Supplier Product ID & Supplier Product Name

[BJ Freeman]

Data model book Vol I page 126 calls out an PO Item and a Salesorder item.

=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin



Joe Eckard sent the following on 4/13/2010 12:14 PM:
> When an order item is created for a Purchase Order, its' description is
> set to "${supplierProductId} - ${supplierProductName}".
> 
> When talking to external systems and when creating custom PDFs, I need
> to access these values separately. Right now I use two order item
> attributes (supplierProductId and supplierProductName), but I am trying
> to reduce the number of our customizations.
> 
> Would there be any objections to creating a new field
> "supplierProductId" on the OrderItem entity and using that when creating
> POs, leaving the order item description as the supplier's product name?

[jira] Commented: (OFBIZ-3647) Create dataResource from content

[nicolas malin (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856563#action_12856563
 ] 

nicolas malin commented on OFBIZ-3647:
--

To Hans : 
The persistContentAndAssoc service create a content and a dataressource. It's 
not my purpose. I search to create a content by generic screen and assoc a 
dataresource directly by the generic dataResource screen

To Scott :
Thanks Scott or the review, my response ;) :
 1.1 I have a memory brainless :( I hate java event call and i propably tried 
to pass this call to a service call ;) . I can remove this code in the patch.
 1.2 arf
 1.3 I understand, I had a different view before your comment but I find the 
java event complex and daunting
 1.4 :) your right, 'll teach me not to read the service
 2.1 ok for useTemplateDataResourceId, no pb. I change it in the next patch
 2.2 ok same 2.1
 2.3 Your right, It's stupid to store directly.

I create a new patch without createDataResourceAndGiveType service in few days 
(I hope).

Nicolas

> Create dataResource from content
> 
>
> Key: OFBIZ-3647
> URL: https://issues.apache.org/jira/browse/OFBIZ-3647
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: SVN trunk
>Reporter: nicolas malin
>Assignee: Scott Gray
>Priority: Minor
> Attachments: content.patch
>
>
> When you create a content, you need create a data resource and return to 
> content for create association.
> If a content don't have a dataResource, I change buton : GoToDataResource by 
> Create a DataResource. When this lastest is created, she automaticly 
> associate to the content and retour to EditContent screen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Purchase Order Items - Supplier Product ID & Supplier Product Name

[Joe Eckard]

When an order item is created for a Purchase Order, its' description  
is set to "${supplierProductId} - ${supplierProductName}".


When talking to external systems and when creating custom PDFs, I need  
to access these values separately. Right now I use two order item  
attributes (supplierProductId and supplierProductName), but I am  
trying to reduce the number of our customizations.


Would there be any objections to creating a new field  
"supplierProductId" on the OrderItem entity and using that when  
creating POs, leaving the order item description as the supplier's  
product name?

smime.p7s
Description: S/MIME cryptographic signature

Invalid description for field canclAutmExtTimeUomId in ProductSubscriptionResource

[Cimballi]

Hi,

The description for the field "canclAutmExtTimeUomId" in
"ProductSubscriptionResource" is invalid :

If this
flag is set to 'Y' the subscription will be extended at the end of the
subscription period with a new order.

The field must contain the id of a UoM, it's not a boolean field.

Cimballi

"Magically" converted types from simpleTypeConvert

[Bob Morley]

We have just started to make use of ProductionRun in our project and we were
having a problem in the create because the ProductionRunServices (around
line 274) makes a call to "createWorkEffort" using a "quantityToProduce"
that is a BigDecimal.  The field on the WorkEffort entity is actually a
Double, so in our solution it was causing a "bad type error" and failing.

I jumped to trunk to try to figure out why it was working in stock Ofbiz. 
After some digging, it turns out that the conversion enhancements now
(appear to) silently do this conversion, resulting in a context that
contains that field as a Double.

This happens because the ServiceDispatcher's runSync method calls
"checkAuth" which (if the user can call the service) calls
ModelService.makeValid which ultimately calls ObjectType.simpleTypeConvert
that handles the BigDecimal -> Double conversion.

Is this the intended behavior?  To be honest, it seems to me that the
complaint that the parameter was not the proper data type was more
desirable.  I understand that when we are handling a postback, values need
to be converted from String to their desired types; but if I am making a
call in our back-end to another service I would think I should be forced to
adhere to that service definition's signature.
-- 
View this message in context: 
http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1838891.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[jira] Assigned: (OFBIZ-3694) Pass Accounting label to Common Label

[Erwan de FERRIERES (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwan de FERRIERES reassigned OFBIZ-3694:
-

Assignee: Erwan de FERRIERES

> Pass Accounting label to Common Label
> -
>
> Key: OFBIZ-3694
> URL: https://issues.apache.org/jira/browse/OFBIZ-3694
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting, framework
>Affects Versions: SVN trunk
>Reporter: nicolas malin
>Assignee: Erwan de FERRIERES
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: accountingToCommonLabel.patch
>
>
> I pass two generic label from accounting component to common component:
> AccountingNoResultFound -> CommonNoResultFound
> AccountingNotAssign -> CommonNotAssign
> Nicolas

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3694) Pass Accounting label to Common Label

[nicolas malin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nicolas malin updated OFBIZ-3694:
-

Attachment: accountingToCommonLabel.patch

> Pass Accounting label to Common Label
> -
>
> Key: OFBIZ-3694
> URL: https://issues.apache.org/jira/browse/OFBIZ-3694
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting, framework
>Affects Versions: SVN trunk
>Reporter: nicolas malin
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: accountingToCommonLabel.patch
>
>
> I pass two generic label from accounting component to common component:
> AccountingNoResultFound -> CommonNoResultFound
> AccountingNotAssign -> CommonNotAssign
> Nicolas

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (OFBIZ-3694) Pass Accounting label to Common Label

[nicolas malin (JIRA)]

Pass Accounting label to Common Label
-

 Key: OFBIZ-3694
 URL: https://issues.apache.org/jira/browse/OFBIZ-3694
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting, framework
Affects Versions: SVN trunk
Reporter: nicolas malin
Priority: Minor
 Fix For: SVN trunk


I pass two generic label from accounting component to common component:
AccountingNoResultFound -> CommonNoResultFound
AccountingNotAssign -> CommonNotAssign

Nicolas

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Security Redesign and Release 10.x Branch

[Jacques Le Roux]

From: "Jacopo Cappellato" 

On Apr 13, 2010, at 5:54 PM, Adrian Crum wrote:


Jacopo Cappellato wrote:

On Apr 13, 2010, at 5:13 PM, Adrian Crum wrote:

Scott Gray wrote:

On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:

On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:


On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:


On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:


Hi Jacopo,

What exactly does it mean to create an "alpha" release, compared to what we 
have now where we create a release branch?

It fundamentally means that we can distribute it outside of the inner group of 
contributors because the we can guarantee
that it is full compliant with ASF license requirements.

Ah okay I see what you mean and that sounds fine to me.  I'm not entirely clear 
on the version numbering though, 10.04a,
10.04b, 10.04 (this is the stable one), 10.04.1 (post stable bug fix release?)


Numbering is an interesting point because it is difficult to state what is 
"stable" from what is not; in your example, of
course 10.04a is not stable; however what makes 10.04 stable? In fact it is 
less stable than 10.04.1.
I don't know, if we are concerned about clarifying what we consider stable we 
could follow the following strategy: adding the
prefix "alpha-" to all the releases we feel like should not be considered 
"stable".
For example:
alpha-10.04.a
alpha-10.04.b
Then when we feel we can consider the release stable:
10.04 (first stable release on 10.04)
10.04.1 (latest current stable release on 10.04)
or even:
stable-10.04
stable-10.04.1

Even if it could be simpler to just start from 10.04.1 since the first alpha 
release and then continue increasing the suffix:
alpha-10.04.1
alpha-10.04.2
stable-10.04.3
stable-10.04.4

but I understand that this is less appealing (i.e. the "stable" release will 
start with 10.04.3)

I don't think we're limited to the version name when it comes to describing 
each release, the download page and perhaps a
README file can help as well.
How about:
10.04-alpha-1
10.04-alpha-2
10.04
10.04.1
10.04.2
?

Or what other ASF projects do:

10.04-RC1
10.04-RC2
10.04
10.04.1
10.04.2

-Adrian

I would prefer to avoid the RC (Release Candidate) suffix because it could be 
confusing since it is actually a real release,
even if not intended to be used in production.


I guess everyone has their preference. Not using the RC suffix seems more 
confusing to me. ;-)



HTTPD and Tomcat use a lot "alpha" and "beta" releases

http://archive.apache.org/dist/httpd/
http://archive.apache.org/dist/tomcat/tomcat-6/

I think that RC is used more in branches and tags (for release candidates 
actually).

Jacopo


Then looks like beta alpha are better terms (I quickly plussed because I 
thought it was the Apache way)

Though I still wonder if we will not been even more considered as a technical framework, than as a ready to use ERP, with this 
numbering. In my mind, the less the best, but yes maybe we will benefit better feedback from some major contributors. At least it's 
worth to try.


Jacques

[jira] Updated: (OFBIZ-3586) application - manufacturing

[Bob Morley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bob Morley updated OFBIZ-3586:
--

Attachment: OFBIZ-3586_ResolveWarningsManufacturing.patch

Rather large set of changes here; typically very minor things -- but there was 
some changes with the BOMTree which was taking a generic ArrayList and now 
takes a List.  There were also a number of services that were not 
explicitly returning a success/error return code; so these were fixed as well.

> application - manufacturing
> ---
>
> Key: OFBIZ-3586
> URL: https://issues.apache.org/jira/browse/OFBIZ-3586
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3586_ResolveWarningsManufacturing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 5:54 PM, Adrian Crum wrote:

> Jacopo Cappellato wrote:
>> On Apr 13, 2010, at 5:13 PM, Adrian Crum wrote:
>>> Scott Gray wrote:
 On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:
> On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:
> 
>> On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
>> 
>>> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
>>> 
 Hi Jacopo,
 
 What exactly does it mean to create an "alpha" release, compared to 
 what we have now where we create a release branch?
>>> It fundamentally means that we can distribute it outside of the inner 
>>> group of contributors because the we can guarantee that it is full 
>>> compliant with ASF license requirements.
>> Ah okay I see what you mean and that sounds fine to me.  I'm not 
>> entirely clear on the version numbering though, 10.04a, 10.04b, 10.04 
>> (this is the stable one), 10.04.1 (post stable bug fix release?)
>> 
> Numbering is an interesting point because it is difficult to state what 
> is "stable" from what is not; in your example, of course 10.04a is not 
> stable; however what makes 10.04 stable? In fact it is less stable than 
> 10.04.1.
> I don't know, if we are concerned about clarifying what we consider 
> stable we could follow the following strategy: adding the prefix "alpha-" 
> to all the releases we feel like should not be considered "stable".
> For example:
> alpha-10.04.a
> alpha-10.04.b
> Then when we feel we can consider the release stable:
> 10.04 (first stable release on 10.04)
> 10.04.1 (latest current stable release on 10.04)
> or even:
> stable-10.04
> stable-10.04.1
> 
> Even if it could be simpler to just start from 10.04.1 since the first 
> alpha release and then continue increasing the suffix:
> alpha-10.04.1
> alpha-10.04.2
> stable-10.04.3
> stable-10.04.4
> 
> but I understand that this is less appealing (i.e. the "stable" release 
> will start with 10.04.3)
 I don't think we're limited to the version name when it comes to 
 describing each release, the download page and perhaps a README file can 
 help as well.
 How about:
 10.04-alpha-1
 10.04-alpha-2
 10.04
 10.04.1
 10.04.2
 ?
>>> Or what other ASF projects do:
>>> 
>>> 10.04-RC1
>>> 10.04-RC2
>>> 10.04
>>> 10.04.1
>>> 10.04.2
>>> 
>>> -Adrian
>> I would prefer to avoid the RC (Release Candidate) suffix because it could 
>> be confusing since it is actually a real release, even if not intended to be 
>> used in production.
> 
> I guess everyone has their preference. Not using the RC suffix seems more 
> confusing to me. ;-)
> 

HTTPD and Tomcat use a lot "alpha" and "beta" releases

http://archive.apache.org/dist/httpd/
http://archive.apache.org/dist/tomcat/tomcat-6/

I think that RC is used more in branches and tags (for release candidates 
actually).

Jacopo

Re: Security Redesign and Release 10.x Branch

[Adrian Crum]

Jacopo Cappellato wrote:

On Apr 13, 2010, at 5:13 PM, Adrian Crum wrote:


Scott Gray wrote:

On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:

On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:


On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:


On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:


Hi Jacopo,

What exactly does it mean to create an "alpha" release, compared to what we 
have now where we create a release branch?

It fundamentally means that we can distribute it outside of the inner group of 
contributors because the we can guarantee that it is full compliant with ASF 
license requirements.

Ah okay I see what you mean and that sounds fine to me.  I'm not entirely clear 
on the version numbering though, 10.04a, 10.04b, 10.04 (this is the stable 
one), 10.04.1 (post stable bug fix release?)


Numbering is an interesting point because it is difficult to state what is 
"stable" from what is not; in your example, of course 10.04a is not stable; 
however what makes 10.04 stable? In fact it is less stable than 10.04.1.
I don't know, if we are concerned about clarifying what we consider stable we could follow the 
following strategy: adding the prefix "alpha-" to all the releases we feel like should 
not be considered "stable".
For example:
alpha-10.04.a
alpha-10.04.b
Then when we feel we can consider the release stable:
10.04 (first stable release on 10.04)
10.04.1 (latest current stable release on 10.04)
or even:
stable-10.04
stable-10.04.1

Even if it could be simpler to just start from 10.04.1 since the first alpha 
release and then continue increasing the suffix:
alpha-10.04.1
alpha-10.04.2
stable-10.04.3
stable-10.04.4

but I understand that this is less appealing (i.e. the "stable" release will 
start with 10.04.3)

I don't think we're limited to the version name when it comes to describing 
each release, the download page and perhaps a README file can help as well.
How about:
10.04-alpha-1
10.04-alpha-2
10.04
10.04.1
10.04.2
?

Or what other ASF projects do:

10.04-RC1
10.04-RC2
10.04
10.04.1
10.04.2

-Adrian


I would prefer to avoid the RC (Release Candidate) suffix because it could be 
confusing since it is actually a real release, even if not intended to be used 
in production.


I guess everyone has their preference. Not using the RC suffix seems 
more confusing to me. ;-)

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 5:13 PM, Adrian Crum wrote:

> Scott Gray wrote:
>> On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:
>>> On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:
>>> 
 On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
 
> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
> 
>> Hi Jacopo,
>> 
>> What exactly does it mean to create an "alpha" release, compared to what 
>> we have now where we create a release branch?
> It fundamentally means that we can distribute it outside of the inner 
> group of contributors because the we can guarantee that it is full 
> compliant with ASF license requirements.
 Ah okay I see what you mean and that sounds fine to me.  I'm not entirely 
 clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the 
 stable one), 10.04.1 (post stable bug fix release?)
 
>>> Numbering is an interesting point because it is difficult to state what is 
>>> "stable" from what is not; in your example, of course 10.04a is not stable; 
>>> however what makes 10.04 stable? In fact it is less stable than 10.04.1.
>>> I don't know, if we are concerned about clarifying what we consider stable 
>>> we could follow the following strategy: adding the prefix "alpha-" to all 
>>> the releases we feel like should not be considered "stable".
>>> For example:
>>> alpha-10.04.a
>>> alpha-10.04.b
>>> Then when we feel we can consider the release stable:
>>> 10.04 (first stable release on 10.04)
>>> 10.04.1 (latest current stable release on 10.04)
>>> or even:
>>> stable-10.04
>>> stable-10.04.1
>>> 
>>> Even if it could be simpler to just start from 10.04.1 since the first 
>>> alpha release and then continue increasing the suffix:
>>> alpha-10.04.1
>>> alpha-10.04.2
>>> stable-10.04.3
>>> stable-10.04.4
>>> 
>>> but I understand that this is less appealing (i.e. the "stable" release 
>>> will start with 10.04.3)
>> I don't think we're limited to the version name when it comes to describing 
>> each release, the download page and perhaps a README file can help as well.
>> How about:
>> 10.04-alpha-1
>> 10.04-alpha-2
>> 10.04
>> 10.04.1
>> 10.04.2
>> ?
> 
> Or what other ASF projects do:
> 
> 10.04-RC1
> 10.04-RC2
> 10.04
> 10.04.1
> 10.04.2
> 
> -Adrian

I would prefer to avoid the RC (Release Candidate) suffix because it could be 
confusing since it is actually a real release, even if not intended to be used 
in production.

Jacopo

Re: Security Redesign and Release 10.x Branch

[Jacques Le Roux]

From: "Adrian Crum" 

Scott Gray wrote:

On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:


On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:


On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:


On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:


Hi Jacopo,

What exactly does it mean to create an "alpha" release, compared to what we 
have now where we create a release branch?
It fundamentally means that we can distribute it outside of the inner group of contributors because the we can guarantee that 
it is full compliant with ASF license requirements.
Ah okay I see what you mean and that sounds fine to me.  I'm not entirely clear on the version numbering though, 10.04a, 
10.04b, 10.04 (this is the stable one), 10.04.1 (post stable bug fix release?)


Numbering is an interesting point because it is difficult to state what is "stable" from what is not; in your example, of course 
10.04a is not stable; however what makes 10.04 stable? In fact it is less stable than 10.04.1.
I don't know, if we are concerned about clarifying what we consider stable we could follow the following strategy: adding the 
prefix "alpha-" to all the releases we feel like should not be considered "stable".

For example:
alpha-10.04.a
alpha-10.04.b
Then when we feel we can consider the release stable:
10.04 (first stable release on 10.04)
10.04.1 (latest current stable release on 10.04)
or even:
stable-10.04
stable-10.04.1

Even if it could be simpler to just start from 10.04.1 since the first alpha 
release and then continue increasing the suffix:
alpha-10.04.1
alpha-10.04.2
stable-10.04.3
stable-10.04.4

but I understand that this is less appealing (i.e. the "stable" release will 
start with 10.04.3)


I don't think we're limited to the version name when it comes to describing each release, the download page and perhaps a README 
file can help as well.

How about:
10.04-alpha-1
10.04-alpha-2
10.04
10.04.1
10.04.2
?


Or what other ASF projects do:

10.04-RC1
10.04-RC2
10.04
10.04.1
10.04.2

-Adrian


+1

Jacques 

Re: Security Redesign and Release 10.x Branch

[Adrian Crum]

Scott Gray wrote:

On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:


On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:


On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:


On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:


Hi Jacopo,

What exactly does it mean to create an "alpha" release, compared to what we 
have now where we create a release branch?

It fundamentally means that we can distribute it outside of the inner group of 
contributors because the we can guarantee that it is full compliant with ASF 
license requirements.

Ah okay I see what you mean and that sounds fine to me.  I'm not entirely clear 
on the version numbering though, 10.04a, 10.04b, 10.04 (this is the stable 
one), 10.04.1 (post stable bug fix release?)


Numbering is an interesting point because it is difficult to state what is 
"stable" from what is not; in your example, of course 10.04a is not stable; 
however what makes 10.04 stable? In fact it is less stable than 10.04.1.
I don't know, if we are concerned about clarifying what we consider stable we could follow the 
following strategy: adding the prefix "alpha-" to all the releases we feel like should 
not be considered "stable".
For example:
alpha-10.04.a
alpha-10.04.b
Then when we feel we can consider the release stable:
10.04 (first stable release on 10.04)
10.04.1 (latest current stable release on 10.04)
or even:
stable-10.04
stable-10.04.1

Even if it could be simpler to just start from 10.04.1 since the first alpha 
release and then continue increasing the suffix:
alpha-10.04.1
alpha-10.04.2
stable-10.04.3
stable-10.04.4

but I understand that this is less appealing (i.e. the "stable" release will 
start with 10.04.3)


I don't think we're limited to the version name when it comes to describing 
each release, the download page and perhaps a README file can help as well.
How about:
10.04-alpha-1
10.04-alpha-2
10.04
10.04.1
10.04.2
?


Or what other ASF projects do:

10.04-RC1
10.04-RC2
10.04
10.04.1
10.04.2

-Adrian

[jira] Commented: (OFBIZ-3446) Allow to open a layer lookup from a layer lookup

[Jacques Le Roux (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856416#action_12856416
 ] 

Jacques Le Roux commented on OFBIZ-3446:


Thanks Sascha,

I confirm there no longer any layer issues, I commited your patch in trunk at 
r933586.

However it seems that the FindSurvey bug reported and fixed by Ankit above is 
back again. Not totally sure because I find that sometimes even using Ctrl+F5 
does not empty completly the Firefox cache (at least the CSS part it seems). 
Anyway I will just try with Opera... Yes I confirm: same with Opera


> Allow to open a layer lookup from a layer lookup
> 
>
> Key: OFBIZ-3446
> URL: https://issues.apache.org/jira/browse/OFBIZ-3446
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: SVN trunk
>
> Attachments: lookup.patch, OFBIZ-3446_FixCloseButton.patch, 
> OFBIZ-3446_LayoutFix.patch, OFBIZ-3446_LayoutFix.patch, 
> OFBIZ-3446_Lookup_in_Lookup.patch, OFBIZ-3446_Lookup_in_Lookup.patch
>
>
> This issue is really a blocker else we need to duplicate a lot of things. I 
> began to work in this direction but after few hours on them I think I will 
> preferably find a real solution than mucking around.
> I was not quite sure this was possible, but as Calendars are also called from 
> layered popups, it seems possible. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (OFBIZ-3665) Main page cleanup: removed partial list of sites/products (available in the Wiki) and moved to the Wiki the "In The News" section

[Jacopo Cappellato (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacopo Cappellato closed OFBIZ-3665.


Resolution: Fixed

933573

> Main page cleanup: removed partial list of sites/products (available in the 
> Wiki) and moved to the Wiki the "In The News" section
> -
>
> Key: OFBIZ-3665
> URL: https://issues.apache.org/jira/browse/OFBIZ-3665
> Project: OFBiz
>  Issue Type: Improvement
>  Components: site
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
>Priority: Minor
> Attachments: mainpage.patch
>
>
> Please review the attached patch for the OFBiz main page:
> 1) removed the sites/products section; the list of sites and products was an 
> arbitrary subset of the list in Wiki (I have left the link to it)
> 2) moved the "In The News" section to the open Wiki space: 
> http://cwiki.apache.org/confluence/display/OFBIZ/In+The+News
> This proposal is a bit draconian but It seems to me inline with the recent 
> discussions in the lists. With this change the community will own the 
> responsibility to maintain the "In The News" page, as it is happening with 
> the "Service Provider" list, and we will have a clean room when we will want 
> to rethink the content of the main page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r933552 - /ofbiz/tags/REL-09.04/

[Jacques Le Roux]

Thanks for all your work on this Jacopo.

Jacques

From: 

Author: jacopoc
Date: Tue Apr 13 11:12:54 2010
New Revision: 933552

URL: http://svn.apache.org/viewvc?rev=933552&view=rev
Log:
Tag release 09.04.
The release has been created from the branch release09.04 (revision 930882) and 
has been officially voted in the dev list.
The results of the vote have been posted to the dev list on April 13 2010 in a mail with subject "[VOTE] [RESULT] [RELEASE] Apache 
OFBiz 09.04".

The vote has passed with the following result:
binding +1 votes: 9 (Adrian Crum, Anil Patel, Bruno Busco, Ashish Vijaywargiya, Jacques Le Roux, Adam Heath, Bilgin Ibryam, Jacopo 
Cappellato, Scott Gray)
non binding +1 votes: 8 (Bob Morley, Marco Risaliti, Erwan de Ferrieres, Bj Freeman, Tim Ruppert, Sam Hamilton, Alex D. Fleming, 
Ravindra Mandre)

binding -1 votes: 0
non binding -1 votes: 0


Added:
   ofbiz/tags/REL-09.04/   (props changed)
 - copied from r930882, ofbiz/branches/release09.04/

Propchange: ofbiz/tags/REL-09.04/
--
--- svn:ignore (added)
+++ svn:ignore Tue Apr 13 11:12:54 2010
@@ -0,0 +1,10 @@
+ofbiz.jar
+bin
+*.patch
+*.iml
+*.ipr
+*.iws
+*.time
+.settings
+.project
+comment.tmp

Propchange: ofbiz/tags/REL-09.04/
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Tue Apr 13 11:12:54 2010
@@ -0,0 +1 @@
+/ofbiz/trunk:765933,766011,766015,766293,766307,766316,766325,766462,766522,766800,767060,767072,767093,767098-767099,767102,767123,767125,767127,767279,767287,767671,767688,767694,767822,767845,768358,768490,768550,768675,768686,768705,768811,768815,768960,769030,769500,770272,770308,770997,771073,771477,772401,772464-772465,773076,773557,773628,773659,773697,774014,774632,774661,774995,775292,775667,776227,776594,776620,776922,777004,777020,68,92,777893,777947,778078,778094,778107,778273,778278,778280,778364,778374,778402,778576,778594,778628,779020,779477,779496,779639,779834,779856,779866,779873,780111,780138,780180,780199,780203,780906,780945,781201,781534,781549,781669,781680,781694,782663,783257,783266,783833,783913,783917,785123,785764,785967,786778,787126,787435-787436,787442,787520,788965,788983,788987,789329,789337,789506,789548,796769,799185,800461,800846,801023,802346,804364,805307,806127,806377,806914,808786-808787,808792,809141,810370,810438,810465,8

10

807,810809,810814,810832,810836,810878,810917,811020,811280,811297,811419,811528,811708,811714,811716,811793,811838,811860,811865,811870,812159,812182,812192,812456,812540,812724,813126,813131,813283,813672,813702,814168,814205,814251,814349,814531,814576,814681,814731,815158,815165,815350,815687,815977,816255,816863,818030,818049,818150,818494,818500,818716,818976,819275-819276,819282,819337,821263,821270,822659,823877-823878,823883,823888,823892,824511,825181-825182,826253,827730,828971,829085,829376,829412,829416,829527,830091,830112,830366,830528,830677,830874,830880,831238,831801,832361,832698,832776,832908,833324,833686,833703,834825,835161,835357,835585,836015,881194,881713,882072,882326,882918,883933,884023,884529,884546,884758,885122,885702,887916,888111,888559,888587,889666,890050,890107,890245,891378,891620,896649,899188,899833,900024,900026,900050,900217,900273,901628,907342-907343,910460,912587,915332,916252,916703,916925,917435,922042,923828,927870,928037,9281

6

6,928171,928180,928470,928477,929582

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 12:41 PM, Scott Gray wrote:

> On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:
> 
>> 
>> On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:
>> 
>>> On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
>>> 
 On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
 
> Hi Jacopo,
> 
> What exactly does it mean to create an "alpha" release, compared to what 
> we have now where we create a release branch?
 
 It fundamentally means that we can distribute it outside of the inner 
 group of contributors because the we can guarantee that it is full 
 compliant with ASF license requirements.
>>> 
>>> Ah okay I see what you mean and that sounds fine to me.  I'm not entirely 
>>> clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the 
>>> stable one), 10.04.1 (post stable bug fix release?)
>>> 
>> 
>> Numbering is an interesting point because it is difficult to state what is 
>> "stable" from what is not; in your example, of course 10.04a is not stable; 
>> however what makes 10.04 stable? In fact it is less stable than 10.04.1.
>> I don't know, if we are concerned about clarifying what we consider stable 
>> we could follow the following strategy: adding the prefix "alpha-" to all 
>> the releases we feel like should not be considered "stable".
>> For example:
>> alpha-10.04.a
>> alpha-10.04.b
>> Then when we feel we can consider the release stable:
>> 10.04 (first stable release on 10.04)
>> 10.04.1 (latest current stable release on 10.04)
>> or even:
>> stable-10.04
>> stable-10.04.1
>> 
>> Even if it could be simpler to just start from 10.04.1 since the first alpha 
>> release and then continue increasing the suffix:
>> alpha-10.04.1
>> alpha-10.04.2
>> stable-10.04.3
>> stable-10.04.4
>> 
>> but I understand that this is less appealing (i.e. the "stable" release will 
>> start with 10.04.3)
> 
> I don't think we're limited to the version name when it comes to describing 
> each release, the download page and perhaps a README file can help as well.
> How about:
> 10.04-alpha-1
> 10.04-alpha-2
> 10.04
> 10.04.1
> 10.04.2
> ?
> 

Yes, I like it

Jacopo

> Regards
> Scott

Re: Security Redesign and Release 10.x Branch

[Scott Gray]

On 13/04/2010, at 10:21 PM, Jacopo Cappellato wrote:

> 
> On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:
> 
>> On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
>> 
>>> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
>>> 
 Hi Jacopo,
 
 What exactly does it mean to create an "alpha" release, compared to what 
 we have now where we create a release branch?
>>> 
>>> It fundamentally means that we can distribute it outside of the inner group 
>>> of contributors because the we can guarantee that it is full compliant with 
>>> ASF license requirements.
>> 
>> Ah okay I see what you mean and that sounds fine to me.  I'm not entirely 
>> clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the 
>> stable one), 10.04.1 (post stable bug fix release?)
>> 
> 
> Numbering is an interesting point because it is difficult to state what is 
> "stable" from what is not; in your example, of course 10.04a is not stable; 
> however what makes 10.04 stable? In fact it is less stable than 10.04.1.
> I don't know, if we are concerned about clarifying what we consider stable we 
> could follow the following strategy: adding the prefix "alpha-" to all the 
> releases we feel like should not be considered "stable".
> For example:
> alpha-10.04.a
> alpha-10.04.b
> Then when we feel we can consider the release stable:
> 10.04 (first stable release on 10.04)
> 10.04.1 (latest current stable release on 10.04)
> or even:
> stable-10.04
> stable-10.04.1
> 
> Even if it could be simpler to just start from 10.04.1 since the first alpha 
> release and then continue increasing the suffix:
> alpha-10.04.1
> alpha-10.04.2
> stable-10.04.3
> stable-10.04.4
> 
> but I understand that this is less appealing (i.e. the "stable" release will 
> start with 10.04.3)

I don't think we're limited to the version name when it comes to describing 
each release, the download page and perhaps a README file can help as well.
How about:
10.04-alpha-1
10.04-alpha-2
10.04
10.04.1
10.04.2
?

Regards
Scott

smime.p7s
Description: S/MIME cryptographic signature

Re: Security Redesign and Release 10.x Branch

[BJ Freeman]

alpha on other teams I have been on has also included filling out a feature.
Alpha meant changes to module already implemented for functionality of
the design that was missing.
the numbering was the level of change to the code. the further the
.x.x.x the less of a change to the code.

=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin



Jacopo Cappellato sent the following on 4/13/2010 3:21 AM:
> On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:
> 
>> On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
>>
>>> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
>>>
 Hi Jacopo,

 What exactly does it mean to create an "alpha" release, compared to what 
 we have now where we create a release branch?
>>> It fundamentally means that we can distribute it outside of the inner group 
>>> of contributors because the we can guarantee that it is full compliant with 
>>> ASF license requirements.
>> Ah okay I see what you mean and that sounds fine to me.  I'm not entirely 
>> clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the 
>> stable one), 10.04.1 (post stable bug fix release?)
>>
> 
> Numbering is an interesting point because it is difficult to state what is 
> "stable" from what is not; in your example, of course 10.04a is not stable; 
> however what makes 10.04 stable? In fact it is less stable than 10.04.1.
> I don't know, if we are concerned about clarifying what we consider stable we 
> could follow the following strategy: adding the prefix "alpha-" to all the 
> releases we feel like should not be considered "stable".
> For example:
> alpha-10.04.a
> alpha-10.04.b
> Then when we feel we can consider the release stable:
> 10.04 (first stable release on 10.04)
> 10.04.1 (latest current stable release on 10.04)
> or even:
> stable-10.04
> stable-10.04.1
> 
> Even if it could be simpler to just start from 10.04.1 since the first alpha 
> release and then continue increasing the suffix:
> alpha-10.04.1
> alpha-10.04.2
> stable-10.04.3
> stable-10.04.4
> 
> but I understand that this is less appealing (i.e. the "stable" release will 
> start with 10.04.3)
> 
> Jacopo
> 
> 
>>> Kind regards,
>>>
>>> Jacopo
>>>
 Thanks
 Scott

 On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:

> Sorry if I am hijacking this thread, but the more I think of it the more 
> I believe we should officially create an "alpha" release 10.04, instead 
> of simply creating a release candidate for 10.04.
> In this way we will have two official current releases:
> 09.04 Stable Release
> 10.04 Alpha Release
>
> Intended audiences:
> 09.04: final users with no interest (or resources) in helping the 
> community to build and maintain stable releases
> 10.04: users (they could be service providers, end user companies with 
> internal resources or longer term goals etc...) that are willing to help 
> the community to build and maintain a stable release
>
> If there will be interest around the 10.04 alpha release, we will get bug 
> fixes that will be part of a future 10.04.1 "stable" (bug fix) release 
> (or a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more 
> stable than the predecessor).
>
> Jacopo
>
> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
>
>> Just to be clear though, I am NOT in favor of back-porting large chunks 
>> of functionality to the release branch under the guise of bug fixes.
>>
>> Regards
>> Scott
>>
>> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
>>
>>> Looks like, none who participated in this thread have objections for 
>>> merging of securitycontext20091231 branch with trunk. 
>>>
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>
>>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
>>>
 Well I don't see any problem with dropping it in right now then.  The 
 real question will be what do people want to be able to backport once 
 the release branch is created.

 Regards
 Scott

 On 7/04/2010, at 5:35 PM, Adrian Crum wrote:

> The security redesign implementation itself is mostly finished. There 
> are a few TODOs and they can be found in the BranchReadMe.txt file.
>
> I recently synchronized the branch with the trunk and there is a 
> remote chance something in the design might have broken in the 
> process. I need to run some tests and review the code to see 

[VOTE] [RESULT] [RELEASE] Apache OFBiz 09.04

[Jacopo Cappellato]

The vote has passed with the following result:

binding +1 votes: 9 (Adrian Crum, Anil Patel, Bruno Busco, Ashish Vijaywargiya, 
Jacques Le Roux, Adam Heath, Bilgin Ibryam, Jacopo Cappellato, Scott Gray)
non binding +1 votes: 8 (Bob Morley, Marco Risaliti, Erwan de Ferrieres, Bj 
Freeman, Tim Ruppert, Sam Hamilton, Alex D. Fleming, Ravindra Mandre)
binding -1 votes: 0
non binding -1 votes: 0

Thanks for your votes.

I am going to move the release package to the OFBiz dist directory for public 
distribution.

Jacopo

On Apr 8, 2010, at 12:27 PM, Jacopo Cappellato wrote:

> This is the vote thread to transform our release candidate 09.04 into an 
> official release. 
> 
> The files can be downloaded from here:
> 
> http://people.apache.org/~jacopoc/dist/
> 
> Vote:
> 
> [ +1] release as Apache OFBiz 09.04
> [ -1] do not release
> 
> For more details about this process please read this 
> http://www.apache.org/foundation/voting.html
> 
> Kind Regards,
> 
> Jacopo
> 

Re: OFBiz development and high level stories/requirements WAS: Re: squareFootage with decimals

[BJ Freeman]

here here.
This is my approach every time with a client. I find it helps them
understand their own business as well as how ofbiz can help.
I get their story of how they do business before implementing ofbiz.
We sometimes discuss how they do business now, before ofbiz could be
changed to help the bottom line.
I then link the functionality of ofbiz to their story, as a migration to
they can say we do this now and ofbiz will help this way in doing this.

When ofbiz does not do part of their story I show what can be done to
make ofbiz help in that part of the story.
and I keep the detailed steps to accomplish that in a separate project
manager software,linked to their story, for implementation should they
want that.

i can then hand the project task and story to a programmer to implement.

I have found it very successful.

A typical slice of a story is like
I open the door and go to my desk the first thing I usually do is check
emails for any major issues.
As I go get coffee I let the orders print out to review.
and so on.

Though this story is probably not quite what we want, it has the basic
to  pull a story like you suggest.




=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation 

Specialtymarket.com 

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin



Jacopo Cappellato sent the following on 4/13/2010 12:34 AM:
> I would like to keep this conversation alive because I think it is an 
> important one.
> What do you think about the idea of creating and maintaining stories (*) that 
> have to be referenced in commit logs (ideally each and every commit log 
> should be associated to a story; the same story can be associated to several 
> commit logs) as a way to focus the attention of the community around 
> requirements behind commits?
> I think it would be a valuable approach to enable the community interaction 
> around requirements (instead of implementation as it is happening now) with 
> the final goal of:
> 1) documenting the high level requirements (stories) available implemented by 
> screens and artifacts in OFBiz
> 2) facilitate the participation in the growth of OFBiz of less technical 
> contributors (e.g. analysts)
> 
> Jacopo
> 
> (*) An example of story could be the following one:
> "Sales Orders are approved automatically when paid by credit card and CC 
> authorization is successful.
> Sales Orders are placed in Pending status approval after checkout then 
> auto-approve once third-party payment processor (PayPal, GoogleCheckout, etc) 
> sends notification.
> Sales Orders are placed in Rejected status when authorization fails.
> Once order is approved inventory is automatically reserved, reducing 
> Available To Promise (ATP) quantity. If inventory is not available negative 
> inventory reservations are created and the order is placed on back-order."
> 
> Company sends confirmation email to the Placing Customer."
> On Apr 8, 2010, at 2:34 PM, Jacopo Cappellato wrote:
> 
>> This is an interesting comment. What we can d to improve this?
>> Here is a suggestion: from now on each and every commit to trunk will have 
>> to contain the reference to a (short) story that describes the context (i.e. 
>> generic business process) that the commit is enhancing.
>> This doesn't mean that there will be a story for each commit since several 
>> commits will share the same story; over time we will create a good set of 
>> stories and it will be easier, when a new story is added, to verify if it 
>> represents an alternative/redundant feature etc...
>> At the beginning there will be some overhead on the shoulders of committers, 
>> but if we are good at keeping the stories consistent this would also help 
>> the participation to non-tech guys.
>> The stories could stay in Confluence or (maybe better) in Jira (easier to 
>> associate commits to Jira tasks).
>>
>> Jacopo
>>
>>
>> On Apr 8, 2010, at 12:50 AM, David E Jones wrote:
>>
>>> This may or may not help this conversation, but to be clear I no longer 
>>> believe in the vision of a developer friendly community. Some good things 
>>> certainly come from the model of community over code and developers being 
>>> the most important part of a community, but my opinion these days is that e 
>>> problems trump the benefits.
>>>
>>> In an effort where there is a clear design with a written and accepted 
>>> specification this model seems to work fine. However when the project is 
>>> not simply implementing an established design what ensues is nothing short 
>>> of chaos and fighting over design with no clear targets or requirements to 
>>> help people make decisions.
>>>
>>> In short that is why I don't believe in this model for OFBiz. We have 
>>> problems with designs and not so much with impleme

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 12:00 PM, Scott Gray wrote:

> On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
> 
>> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
>> 
>>> Hi Jacopo,
>>> 
>>> What exactly does it mean to create an "alpha" release, compared to what we 
>>> have now where we create a release branch?
>> 
>> It fundamentally means that we can distribute it outside of the inner group 
>> of contributors because the we can guarantee that it is full compliant with 
>> ASF license requirements.
> 
> Ah okay I see what you mean and that sounds fine to me.  I'm not entirely 
> clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the 
> stable one), 10.04.1 (post stable bug fix release?)
> 

Numbering is an interesting point because it is difficult to state what is 
"stable" from what is not; in your example, of course 10.04a is not stable; 
however what makes 10.04 stable? In fact it is less stable than 10.04.1.
I don't know, if we are concerned about clarifying what we consider stable we 
could follow the following strategy: adding the prefix "alpha-" to all the 
releases we feel like should not be considered "stable".
For example:
alpha-10.04.a
alpha-10.04.b
Then when we feel we can consider the release stable:
10.04 (first stable release on 10.04)
10.04.1 (latest current stable release on 10.04)
or even:
stable-10.04
stable-10.04.1

Even if it could be simpler to just start from 10.04.1 since the first alpha 
release and then continue increasing the suffix:
alpha-10.04.1
alpha-10.04.2
stable-10.04.3
stable-10.04.4

but I understand that this is less appealing (i.e. the "stable" release will 
start with 10.04.3)

Jacopo


>> 
>> Kind regards,
>> 
>> Jacopo
>> 
>>> 
>>> Thanks
>>> Scott
>>> 
>>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:
>>> 
 Sorry if I am hijacking this thread, but the more I think of it the more I 
 believe we should officially create an "alpha" release 10.04, instead of 
 simply creating a release candidate for 10.04.
 In this way we will have two official current releases:
 09.04 Stable Release
 10.04 Alpha Release
 
 Intended audiences:
 09.04: final users with no interest (or resources) in helping the 
 community to build and maintain stable releases
 10.04: users (they could be service providers, end user companies with 
 internal resources or longer term goals etc...) that are willing to help 
 the community to build and maintain a stable release
 
 If there will be interest around the 10.04 alpha release, we will get bug 
 fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or 
 a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable 
 than the predecessor).
 
 Jacopo
 
 On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
 
> Just to be clear though, I am NOT in favor of back-porting large chunks 
> of functionality to the release branch under the guise of bug fixes.
> 
> Regards
> Scott
> 
> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
> 
>> Looks like, none who participated in this thread have objections for 
>> merging of securitycontext20091231 branch with trunk. 
>> 
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>> 
>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
>> 
>>> Well I don't see any problem with dropping it in right now then.  The 
>>> real question will be what do people want to be able to backport once 
>>> the release branch is created.
>>> 
>>> Regards
>>> Scott
>>> 
>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
>>> 
 The security redesign implementation itself is mostly finished. There 
 are a few TODOs and they can be found in the BranchReadMe.txt file.
 
 I recently synchronized the branch with the trunk and there is a 
 remote chance something in the design might have broken in the 
 process. I need to run some tests and review the code to see if that 
 happened.
 
 The Example component has been switched over to the new design.
 
 There is a user login called "artifact-user" that demonstrates the new 
 design. That user login is restricted to using the Example component.
 
 If the branch was merged back to the trunk and the new security design 
 was enabled, the Example component would use the new design and the 
 remaining components would still use the current security design. The 
 two can co-exist.
 
 I imagine the process after that would be similar to when we 
 introduced the permission checking services - contributors can 
 contribute code that converts parts of the project over to the new 
 security design. Conversion involves removing ha

Re: svn commit: r933159 - in /ofbiz/branches/release09.04: ./ applications/humanres/widget/forms/EmploymentAppForms.xml

[Jacques Le Roux]

Hi Jacopo,

No problems, 09.04.1 sounds good to me, thanks for the information

Jacques

From: "Jacopo Cappellato" 

Jacques,

I am going to create the tag for the release 09.04 before this bug fix: this means that the bug fix will not be included in the 
official release but of course it will be part of the next bug fix release for 09.04, if it will be released (as 09.04.1?).
I am sorry but the package with all the signatures have been created some days before it and the vote on it was still running for 
a few days when this fix has been committed yesterday.


Jacopo


On Apr 12, 2010, at 11:18 AM, jler...@apache.org wrote:


Author: jleroux
Date: Mon Apr 12 09:18:09 2010
New Revision: 933159

URL: http://svn.apache.org/viewvc?rev=933159&view=rev
Log:
"Applied fix from trunk for revision: 933157"

r933157 | jleroux | 2010-04-12 11:14:27 +0200 (lun. 12 avr. 2010) | 4 lignes

A patch from Bob Morley "Creating New Employment Application (non secure)" https://issues.apache.org/jira/browse/OFBIZ-2894 - 
OFBIZ-2894


Removes the query string parms from the form action. The applicationId was 
already in the form but the partyId had to be added.




Modified:
   ofbiz/branches/release09.04/   (props changed)
   
ofbiz/branches/release09.04/applications/humanres/widget/forms/EmploymentAppForms.xml

Propchange: ofbiz/branches/release09.04/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Apr 12 09:18:09 2010
@@ -1 +1 @@
-/ofbiz/trunk:765933,766011,766015,766293,766307,766316,766325,766462,766522,766800,767060,767072,767093,767098-767099,767102,767123,767125,767127,767279,767287,767671,767688,767694,767822,767845,768358,768490,768550,768675,768686,768705,768811,768815,768960,769030,769500,770272,770308,770997,771073,771477,772401,772464-772465,773076,773557,773628,773659,773697,774014,774632,774661,774995,775292,775667,776227,776594,776620,776922,777004,777020,68,92,777893,777947,778078,778094,778107,778273,778278,778280,778364,778374,778402,778576,778594,778628,779020,779477,779496,779639,779834,779856,779866,779873,780111,780138,780180,780199,780203,780906,780945,781201,781534,781549,781669,781680,781694,782663,783257,783266,783833,783913,783917,785123,785764,785967,786778,787126,787435-787436,787442,787520,788965,788983,788987,789329,789337,789506,789548,796769,799185,800461,800846,801023,802346,804364,805307,806127,806377,806914,808786-808787,808792,809141,810370,810438,810465,

810

807,810809,810814,810832,810836,810878,810917,811020,811280,811297,811419,811528,811708,811714,811716,811793,811838,811860,811865,811870,812159,812182,812192,812456,812540,812724,813126,813131,813283,813672,813702,814168,814205,814251,814349,814531,814576,814681,814731,815158,815165,815350,815687,815977,816255,816863,818030,818049,818150,818494,818500,818716,818976,819275-819276,819282,819337,821263,821270,822659,823877-823878,823883,823888,823892,824511,825181-825182,826253,827730,828971,829085,829376,829412,829416,829527,830091,830112,830366,830528,830677,830874,830880,831238,831801,832361,832698,832776,832908,833324,833686,833703,834825,835161,835357,835585,836015,881194,881713,882072,882326,882918,883933,884023,884529,884546,884758,885122,885702,887916,888111,888559,888587,889666,890050,890107,890245,891378,891620,896649,899188,899833,900024,900026,900050,900217,900273,901628,907342-907343,910460,912587,915332,916252,916703,916925,917435,922042,923828,927870,928037,928

16

6,928171,928180,928470,928477,929582
+/ofbiz/trunk:765933,766011,766015,766293,766307,766316,766325,766462,766522,766800,767060,767072,767093,767098-767099,767102,767123,767125,767127,767279,767287,767671,767688,767694,767822,767845,768358,768490,768550,768675,768686,768705,768811,768815,768960,769030,769500,770272,770308,770997,771073,771477,772401,772464-772465,773076,773557,773628,773659,773697,774014,774632,774661,774995,775292,775667,776227,776594,776620,776922,777004,777020,68,92,777893,777947,778078,778094,778107,778273,778278,778280,778364,778374,778402,778576,778594,778628,779020,779477,779496,779639,779834,779856,779866,779873,780111,780138,780180,780199,780203,780906,780945,781201,781534,781549,781669,781680,781694,782663,783257,783266,783833,783913,783917,785123,785764,785967,786778,787126,787435-787436,787442,787520,788965,788983,788987,789329,789337,789506,789548,796769,799185,800461,800846,801023,802346,804364,805307,806127,806377,806914,808786-808787,808792,809141,810370,810438,810465,

810

807,810809,810814,810832,810836,810878,810917,811020,811280,811297,811419,811528,811708,811714,811716,811793,811838,811860,811865,811870,812159,812182,812192,812456,812540,812724,813126,813131,813283,813672,813702,814168,814205,814251,814349,814531,814576,814681,814731,815158,815165,815350,815687,815977,816255,816863,

Re: Security Redesign and Release 10.x Branch

[Scott Gray]

On 13/04/2010, at 9:41 PM, Jacopo Cappellato wrote:

> 
> On Apr 13, 2010, at 11:36 AM, Jacopo Cappellato wrote:
> 
>> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
>> 
>>> Hi Jacopo,
>>> 
>>> What exactly does it mean to create an "alpha" release, compared to what we 
>>> have now where we create a release branch?
>> 
>> It fundamentally means that we can distribute it outside of the inner group 
>> of contributors because the we can guarantee that it is full compliant with 
>> ASF license requirements.
>> 
> 
> But apart from this (important, in my opinion) difference the "alpha" release 
> will be used exactly as we have used the release candidate: to build (with 
> the help of the community) a "stable" release.
> Having the ability of distribute it will increase our chances to get more 
> help (tests and bug fixes but also documentation) from the community and the 
> "stable" release will be an effort of the community (instead of the result of 
> backported patches done by committers only).
> 
> Jacopo

I'm very much in favor of moving away from svn as our core distribution method. 
 I believe that doing so would encourage service providers (or even the 
community) to build and offer migration tools and services.

Regards
Scott

>> Kind regards,
>> 
>> Jacopo
>> 
>>> 
>>> Thanks
>>> Scott
>>> 
>>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:
>>> 
 Sorry if I am hijacking this thread, but the more I think of it the more I 
 believe we should officially create an "alpha" release 10.04, instead of 
 simply creating a release candidate for 10.04.
 In this way we will have two official current releases:
 09.04 Stable Release
 10.04 Alpha Release
 
 Intended audiences:
 09.04: final users with no interest (or resources) in helping the 
 community to build and maintain stable releases
 10.04: users (they could be service providers, end user companies with 
 internal resources or longer term goals etc...) that are willing to help 
 the community to build and maintain a stable release
 
 If there will be interest around the 10.04 alpha release, we will get bug 
 fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or 
 a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable 
 than the predecessor).
 
 Jacopo
 
 On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
 
> Just to be clear though, I am NOT in favor of back-porting large chunks 
> of functionality to the release branch under the guise of bug fixes.
> 
> Regards
> Scott
> 
> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
> 
>> Looks like, none who participated in this thread have objections for 
>> merging of securitycontext20091231 branch with trunk. 
>> 
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>> 
>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
>> 
>>> Well I don't see any problem with dropping it in right now then.  The 
>>> real question will be what do people want to be able to backport once 
>>> the release branch is created.
>>> 
>>> Regards
>>> Scott
>>> 
>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
>>> 
 The security redesign implementation itself is mostly finished. There 
 are a few TODOs and they can be found in the BranchReadMe.txt file.
 
 I recently synchronized the branch with the trunk and there is a 
 remote chance something in the design might have broken in the 
 process. I need to run some tests and review the code to see if that 
 happened.
 
 The Example component has been switched over to the new design.
 
 There is a user login called "artifact-user" that demonstrates the new 
 design. That user login is restricted to using the Example component.
 
 If the branch was merged back to the trunk and the new security design 
 was enabled, the Example component would use the new design and the 
 remaining components would still use the current security design. The 
 two can co-exist.
 
 I imagine the process after that would be similar to when we 
 introduced the permission checking services - contributors can 
 contribute code that converts parts of the project over to the new 
 security design. Conversion involves removing hard-coded permission 
 checks and creating seed data to grant permission to component 
 artifacts.
 
 As I mentioned before, switching a component over to the new design 
 can create some unexpected problems. That's because our existing code 
 has security holes in it, and the new design plugs those holes - 
 making parts of the component unreachable. In other w

Re: Security Redesign and Release 10.x Branch

[Scott Gray]

On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:

> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
> 
>> Hi Jacopo,
>> 
>> What exactly does it mean to create an "alpha" release, compared to what we 
>> have now where we create a release branch?
> 
> It fundamentally means that we can distribute it outside of the inner group 
> of contributors because the we can guarantee that it is full compliant with 
> ASF license requirements.

Ah okay I see what you mean and that sounds fine to me.  I'm not entirely clear 
on the version numbering though, 10.04a, 10.04b, 10.04 (this is the stable 
one), 10.04.1 (post stable bug fix release?)

> 
> Kind regards,
> 
> Jacopo
> 
>> 
>> Thanks
>> Scott
>> 
>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:
>> 
>>> Sorry if I am hijacking this thread, but the more I think of it the more I 
>>> believe we should officially create an "alpha" release 10.04, instead of 
>>> simply creating a release candidate for 10.04.
>>> In this way we will have two official current releases:
>>> 09.04 Stable Release
>>> 10.04 Alpha Release
>>> 
>>> Intended audiences:
>>> 09.04: final users with no interest (or resources) in helping the community 
>>> to build and maintain stable releases
>>> 10.04: users (they could be service providers, end user companies with 
>>> internal resources or longer term goals etc...) that are willing to help 
>>> the community to build and maintain a stable release
>>> 
>>> If there will be interest around the 10.04 alpha release, we will get bug 
>>> fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or 
>>> a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable 
>>> than the predecessor).
>>> 
>>> Jacopo
>>> 
>>> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
>>> 
 Just to be clear though, I am NOT in favor of back-porting large chunks of 
 functionality to the release branch under the guise of bug fixes.
 
 Regards
 Scott
 
 On 8/04/2010, at 12:06 PM, Anil Patel wrote:
 
> Looks like, none who participated in this thread have objections for 
> merging of securitycontext20091231 branch with trunk. 
> 
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
> 
> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
> 
>> Well I don't see any problem with dropping it in right now then.  The 
>> real question will be what do people want to be able to backport once 
>> the release branch is created.
>> 
>> Regards
>> Scott
>> 
>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
>> 
>>> The security redesign implementation itself is mostly finished. There 
>>> are a few TODOs and they can be found in the BranchReadMe.txt file.
>>> 
>>> I recently synchronized the branch with the trunk and there is a remote 
>>> chance something in the design might have broken in the process. I need 
>>> to run some tests and review the code to see if that happened.
>>> 
>>> The Example component has been switched over to the new design.
>>> 
>>> There is a user login called "artifact-user" that demonstrates the new 
>>> design. That user login is restricted to using the Example component.
>>> 
>>> If the branch was merged back to the trunk and the new security design 
>>> was enabled, the Example component would use the new design and the 
>>> remaining components would still use the current security design. The 
>>> two can co-exist.
>>> 
>>> I imagine the process after that would be similar to when we introduced 
>>> the permission checking services - contributors can contribute code 
>>> that converts parts of the project over to the new security design. 
>>> Conversion involves removing hard-coded permission checks and creating 
>>> seed data to grant permission to component artifacts.
>>> 
>>> As I mentioned before, switching a component over to the new design can 
>>> create some unexpected problems. That's because our existing code has 
>>> security holes in it, and the new design plugs those holes - making 
>>> parts of the component unreachable. In other words, parts of code that 
>>> happily allow you to do things you don't have permission to do will 
>>> start to throw exceptions in the new design.
>>> 
>>> -Adrian
>>> 
>>> 
>>> Scott Gray wrote:
 Question:
 What exactly is the current status of the execution branch?  What is 
 it that needs to be done for it to be enabled in the trunk?
 I'm sorry if you feel you've already answered that question but I'm 
 afraid it still isn't entirely clear to me.
 Regards
 Scott
 On 7/04/2010, at 5:14 PM, Adrian Crum wrote:
> If we wait, then we're waiting for evaluation and testing of the 
> branch. I've done all

Re: svn commit: r933159 - in /ofbiz/branches/release09.04: ./ applications/humanres/widget/forms/EmploymentAppForms.xml

[Jacopo Cappellato]

Jacques,

I am going to create the tag for the release 09.04 before this bug fix: this 
means that the bug fix will not be included in the official release but of 
course it will be part of the next bug fix release for 09.04, if it will be 
released (as 09.04.1?).
I am sorry but the package with all the signatures have been created some days 
before it and the vote on it was still running for a few days when this fix has 
been committed yesterday.

Jacopo


On Apr 12, 2010, at 11:18 AM, jler...@apache.org wrote:

> Author: jleroux
> Date: Mon Apr 12 09:18:09 2010
> New Revision: 933159
> 
> URL: http://svn.apache.org/viewvc?rev=933159&view=rev
> Log:
> "Applied fix from trunk for revision: 933157" 
> 
> r933157 | jleroux | 2010-04-12 11:14:27 +0200 (lun. 12 avr. 2010) | 4 lignes
> 
> A patch from Bob Morley "Creating New Employment Application (non secure)" 
> https://issues.apache.org/jira/browse/OFBIZ-2894 - OFBIZ-2894
> 
> Removes the query string parms from the form action. The applicationId was 
> already in the form but the partyId had to be added.
> 
> 
> 
> 
> Modified:
>ofbiz/branches/release09.04/   (props changed)
>
> ofbiz/branches/release09.04/applications/humanres/widget/forms/EmploymentAppForms.xml
> 
> Propchange: ofbiz/branches/release09.04/
> --
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Mon Apr 12 09:18:09 2010
> @@ -1 +1 @@
> -/ofbiz/trunk:765933,766011,766015,766293,766307,766316,766325,766462,766522,766800,767060,767072,767093,767098-767099,767102,767123,767125,767127,767279,767287,767671,767688,767694,767822,767845,768358,768490,768550,768675,768686,768705,768811,768815,768960,769030,769500,770272,770308,770997,771073,771477,772401,772464-772465,773076,773557,773628,773659,773697,774014,774632,774661,774995,775292,775667,776227,776594,776620,776922,777004,777020,68,92,777893,777947,778078,778094,778107,778273,778278,778280,778364,778374,778402,778576,778594,778628,779020,779477,779496,779639,779834,779856,779866,779873,780111,780138,780180,780199,780203,780906,780945,781201,781534,781549,781669,781680,781694,782663,783257,783266,783833,783913,783917,785123,785764,785967,786778,787126,787435-787436,787442,787520,788965,788983,788987,789329,789337,789506,789548,796769,799185,800461,800846,801023,802346,804364,805307,806127,806377,806914,808786-808787,808792,809141,810370,810438,810465,810
> 807,810809,810814,810832,810836,810878,810917,811020,811280,811297,811419,811528,811708,811714,811716,811793,811838,811860,811865,811870,812159,812182,812192,812456,812540,812724,813126,813131,813283,813672,813702,814168,814205,814251,814349,814531,814576,814681,814731,815158,815165,815350,815687,815977,816255,816863,818030,818049,818150,818494,818500,818716,818976,819275-819276,819282,819337,821263,821270,822659,823877-823878,823883,823888,823892,824511,825181-825182,826253,827730,828971,829085,829376,829412,829416,829527,830091,830112,830366,830528,830677,830874,830880,831238,831801,832361,832698,832776,832908,833324,833686,833703,834825,835161,835357,835585,836015,881194,881713,882072,882326,882918,883933,884023,884529,884546,884758,885122,885702,887916,888111,888559,888587,889666,890050,890107,890245,891378,891620,896649,899188,899833,900024,900026,900050,900217,900273,901628,907342-907343,910460,912587,915332,916252,916703,916925,917435,922042,923828,927870,928037,92816
> 6,928171,928180,928470,928477,929582
> +/ofbiz/trunk:765933,766011,766015,766293,766307,766316,766325,766462,766522,766800,767060,767072,767093,767098-767099,767102,767123,767125,767127,767279,767287,767671,767688,767694,767822,767845,768358,768490,768550,768675,768686,768705,768811,768815,768960,769030,769500,770272,770308,770997,771073,771477,772401,772464-772465,773076,773557,773628,773659,773697,774014,774632,774661,774995,775292,775667,776227,776594,776620,776922,777004,777020,68,92,777893,777947,778078,778094,778107,778273,778278,778280,778364,778374,778402,778576,778594,778628,779020,779477,779496,779639,779834,779856,779866,779873,780111,780138,780180,780199,780203,780906,780945,781201,781534,781549,781669,781680,781694,782663,783257,783266,783833,783913,783917,785123,785764,785967,786778,787126,787435-787436,787442,787520,788965,788983,788987,789329,789337,789506,789548,796769,799185,800461,800846,801023,802346,804364,805307,806127,806377,806914,808786-808787,808792,809141,810370,810438,810465,810
> 807,810809,810814,810832,810836,810878,810917,811020,811280,811297,811419,811528,811708,811714,811716,811793,811838,811860,811865,811870,812159,812182,812192,812456,812540,812724,813126,813131,813283,813672,813702,814168,814205,814251,814349,814531,814576,814681,814731,815158,815165,815350,815687,815977,816255,816863,818030,818049,818150,818494,818500,818716,818976,819275-81

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 11:36 AM, Jacopo Cappellato wrote:

> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:
> 
>> Hi Jacopo,
>> 
>> What exactly does it mean to create an "alpha" release, compared to what we 
>> have now where we create a release branch?
> 
> It fundamentally means that we can distribute it outside of the inner group 
> of contributors because the we can guarantee that it is full compliant with 
> ASF license requirements.
> 

But apart from this (important, in my opinion) difference the "alpha" release 
will be used exactly as we have used the release candidate: to build (with the 
help of the community) a "stable" release.
Having the ability of distribute it will increase our chances to get more help 
(tests and bug fixes but also documentation) from the community and the 
"stable" release will be an effort of the community (instead of the result of 
backported patches done by committers only).

Jacopo



> Kind regards,
> 
> Jacopo
> 
>> 
>> Thanks
>> Scott
>> 
>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:
>> 
>>> Sorry if I am hijacking this thread, but the more I think of it the more I 
>>> believe we should officially create an "alpha" release 10.04, instead of 
>>> simply creating a release candidate for 10.04.
>>> In this way we will have two official current releases:
>>> 09.04 Stable Release
>>> 10.04 Alpha Release
>>> 
>>> Intended audiences:
>>> 09.04: final users with no interest (or resources) in helping the community 
>>> to build and maintain stable releases
>>> 10.04: users (they could be service providers, end user companies with 
>>> internal resources or longer term goals etc...) that are willing to help 
>>> the community to build and maintain a stable release
>>> 
>>> If there will be interest around the 10.04 alpha release, we will get bug 
>>> fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or 
>>> a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable 
>>> than the predecessor).
>>> 
>>> Jacopo
>>> 
>>> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
>>> 
 Just to be clear though, I am NOT in favor of back-porting large chunks of 
 functionality to the release branch under the guise of bug fixes.
 
 Regards
 Scott
 
 On 8/04/2010, at 12:06 PM, Anil Patel wrote:
 
> Looks like, none who participated in this thread have objections for 
> merging of securitycontext20091231 branch with trunk. 
> 
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
> 
> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
> 
>> Well I don't see any problem with dropping it in right now then.  The 
>> real question will be what do people want to be able to backport once 
>> the release branch is created.
>> 
>> Regards
>> Scott
>> 
>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
>> 
>>> The security redesign implementation itself is mostly finished. There 
>>> are a few TODOs and they can be found in the BranchReadMe.txt file.
>>> 
>>> I recently synchronized the branch with the trunk and there is a remote 
>>> chance something in the design might have broken in the process. I need 
>>> to run some tests and review the code to see if that happened.
>>> 
>>> The Example component has been switched over to the new design.
>>> 
>>> There is a user login called "artifact-user" that demonstrates the new 
>>> design. That user login is restricted to using the Example component.
>>> 
>>> If the branch was merged back to the trunk and the new security design 
>>> was enabled, the Example component would use the new design and the 
>>> remaining components would still use the current security design. The 
>>> two can co-exist.
>>> 
>>> I imagine the process after that would be similar to when we introduced 
>>> the permission checking services - contributors can contribute code 
>>> that converts parts of the project over to the new security design. 
>>> Conversion involves removing hard-coded permission checks and creating 
>>> seed data to grant permission to component artifacts.
>>> 
>>> As I mentioned before, switching a component over to the new design can 
>>> create some unexpected problems. That's because our existing code has 
>>> security holes in it, and the new design plugs those holes - making 
>>> parts of the component unreachable. In other words, parts of code that 
>>> happily allow you to do things you don't have permission to do will 
>>> start to throw exceptions in the new design.
>>> 
>>> -Adrian
>>> 
>>> 
>>> Scott Gray wrote:
 Question:
 What exactly is the current status of the execution branch?  What is 
 it that needs to be done for it to be enabled in the trunk?
 I'm sorry if you feel yo

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 11:33 AM, Scott Gray wrote:

> Hi Jacopo,
> 
> What exactly does it mean to create an "alpha" release, compared to what we 
> have now where we create a release branch?

It fundamentally means that we can distribute it outside of the inner group of 
contributors because the we can guarantee that it is full compliant with ASF 
license requirements.

Kind regards,

Jacopo

> 
> Thanks
> Scott
> 
> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:
> 
>> Sorry if I am hijacking this thread, but the more I think of it the more I 
>> believe we should officially create an "alpha" release 10.04, instead of 
>> simply creating a release candidate for 10.04.
>> In this way we will have two official current releases:
>> 09.04 Stable Release
>> 10.04 Alpha Release
>> 
>> Intended audiences:
>> 09.04: final users with no interest (or resources) in helping the community 
>> to build and maintain stable releases
>> 10.04: users (they could be service providers, end user companies with 
>> internal resources or longer term goals etc...) that are willing to help the 
>> community to build and maintain a stable release
>> 
>> If there will be interest around the 10.04 alpha release, we will get bug 
>> fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a 
>> "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than 
>> the predecessor).
>> 
>> Jacopo
>> 
>> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
>> 
>>> Just to be clear though, I am NOT in favor of back-porting large chunks of 
>>> functionality to the release branch under the guise of bug fixes.
>>> 
>>> Regards
>>> Scott
>>> 
>>> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
>>> 
 Looks like, none who participated in this thread have objections for 
 merging of securitycontext20091231 branch with trunk. 
 
 Thanks and Regards
 Anil Patel
 HotWax Media Inc
 Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
 
 On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
 
> Well I don't see any problem with dropping it in right now then.  The 
> real question will be what do people want to be able to backport once the 
> release branch is created.
> 
> Regards
> Scott
> 
> On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
> 
>> The security redesign implementation itself is mostly finished. There 
>> are a few TODOs and they can be found in the BranchReadMe.txt file.
>> 
>> I recently synchronized the branch with the trunk and there is a remote 
>> chance something in the design might have broken in the process. I need 
>> to run some tests and review the code to see if that happened.
>> 
>> The Example component has been switched over to the new design.
>> 
>> There is a user login called "artifact-user" that demonstrates the new 
>> design. That user login is restricted to using the Example component.
>> 
>> If the branch was merged back to the trunk and the new security design 
>> was enabled, the Example component would use the new design and the 
>> remaining components would still use the current security design. The 
>> two can co-exist.
>> 
>> I imagine the process after that would be similar to when we introduced 
>> the permission checking services - contributors can contribute code that 
>> converts parts of the project over to the new security design. 
>> Conversion involves removing hard-coded permission checks and creating 
>> seed data to grant permission to component artifacts.
>> 
>> As I mentioned before, switching a component over to the new design can 
>> create some unexpected problems. That's because our existing code has 
>> security holes in it, and the new design plugs those holes - making 
>> parts of the component unreachable. In other words, parts of code that 
>> happily allow you to do things you don't have permission to do will 
>> start to throw exceptions in the new design.
>> 
>> -Adrian
>> 
>> 
>> Scott Gray wrote:
>>> Question:
>>> What exactly is the current status of the execution branch?  What is it 
>>> that needs to be done for it to be enabled in the trunk?
>>> I'm sorry if you feel you've already answered that question but I'm 
>>> afraid it still isn't entirely clear to me.
>>> Regards
>>> Scott
>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote:
 If we wait, then we're waiting for evaluation and testing of the 
 branch. I've done all I can do - the code is written, I suggested we 
 do the merge before the release branch, and I gave my reasons for 
 suggesting it.
 
 At this point in time I have stepped out of the discussion (in a 
 positive way) to give others a chance to look at the design and the 
 code and decide for themselves if it should be included. In ot

Re: Security Redesign and Release 10.x Branch

[Scott Gray]

Hi Jacopo,

What exactly does it mean to create an "alpha" release, compared to what we 
have now where we create a release branch?

Thanks
Scott

On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote:

> Sorry if I am hijacking this thread, but the more I think of it the more I 
> believe we should officially create an "alpha" release 10.04, instead of 
> simply creating a release candidate for 10.04.
> In this way we will have two official current releases:
> 09.04 Stable Release
> 10.04 Alpha Release
> 
> Intended audiences:
> 09.04: final users with no interest (or resources) in helping the community 
> to build and maintain stable releases
> 10.04: users (they could be service providers, end user companies with 
> internal resources or longer term goals etc...) that are willing to help the 
> community to build and maintain a stable release
> 
> If there will be interest around the 10.04 alpha release, we will get bug 
> fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a 
> "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than 
> the predecessor).
> 
> Jacopo
> 
> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
> 
>> Just to be clear though, I am NOT in favor of back-porting large chunks of 
>> functionality to the release branch under the guise of bug fixes.
>> 
>> Regards
>> Scott
>> 
>> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
>> 
>>> Looks like, none who participated in this thread have objections for 
>>> merging of securitycontext20091231 branch with trunk. 
>>> 
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>> 
>>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
>>> 
 Well I don't see any problem with dropping it in right now then.  The real 
 question will be what do people want to be able to backport once the 
 release branch is created.
 
 Regards
 Scott
 
 On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
 
> The security redesign implementation itself is mostly finished. There are 
> a few TODOs and they can be found in the BranchReadMe.txt file.
> 
> I recently synchronized the branch with the trunk and there is a remote 
> chance something in the design might have broken in the process. I need 
> to run some tests and review the code to see if that happened.
> 
> The Example component has been switched over to the new design.
> 
> There is a user login called "artifact-user" that demonstrates the new 
> design. That user login is restricted to using the Example component.
> 
> If the branch was merged back to the trunk and the new security design 
> was enabled, the Example component would use the new design and the 
> remaining components would still use the current security design. The two 
> can co-exist.
> 
> I imagine the process after that would be similar to when we introduced 
> the permission checking services - contributors can contribute code that 
> converts parts of the project over to the new security design. Conversion 
> involves removing hard-coded permission checks and creating seed data to 
> grant permission to component artifacts.
> 
> As I mentioned before, switching a component over to the new design can 
> create some unexpected problems. That's because our existing code has 
> security holes in it, and the new design plugs those holes - making parts 
> of the component unreachable. In other words, parts of code that happily 
> allow you to do things you don't have permission to do will start to 
> throw exceptions in the new design.
> 
> -Adrian
> 
> 
> Scott Gray wrote:
>> Question:
>> What exactly is the current status of the execution branch?  What is it 
>> that needs to be done for it to be enabled in the trunk?
>> I'm sorry if you feel you've already answered that question but I'm 
>> afraid it still isn't entirely clear to me.
>> Regards
>> Scott
>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote:
>>> If we wait, then we're waiting for evaluation and testing of the 
>>> branch. I've done all I can do - the code is written, I suggested we do 
>>> the merge before the release branch, and I gave my reasons for 
>>> suggesting it.
>>> 
>>> At this point in time I have stepped out of the discussion (in a 
>>> positive way) to give others a chance to look at the design and the 
>>> code and decide for themselves if it should be included. In other 
>>> words, I don't want to be in a position where I have to convince the 
>>> community what it should do. If the design and the implementation are 
>>> good, then there will be no need to convince anyone, right?
>>> 
>>> I'll answer questions about the executioncontext branch, and I'll 
>>> continue to work on it here and there when I have th

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

On Apr 13, 2010, at 10:19 AM, Jacopo Cappellato wrote:

> Sorry if I am hijacking this thread, but the more I think of it the more I 
> believe we should officially create an "alpha" release 10.04, instead of 
> simply creating a release candidate for 10.04.
> In this way we will have two official current releases:
> 09.04 Stable Release
> 10.04 Alpha Release
> 
> Intended audiences:
> 09.04: final users with no interest (or resources) in helping the community 
> to build and maintain stable releases
> 10.04: users (they could be service providers, end user companies with 
> internal resources or longer term goals etc...) that are willing to help the 
> community to build and maintain a stable release
> 
> If there will be interest around the 10.04 alpha release, we will get bug 
> fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a 
> "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than 
> the predecessor).

From a technical point of view 09.04, 10.04 etc will be svn branches, while 
10.04.1, 10.04.2 etc... will be svn tags associated to the branch.

Jacopo

> 
> Jacopo
> 
> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:
> 
>> Just to be clear though, I am NOT in favor of back-porting large chunks of 
>> functionality to the release branch under the guise of bug fixes.
>> 
>> Regards
>> Scott
>> 
>> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
>> 
>>> Looks like, none who participated in this thread have objections for 
>>> merging of securitycontext20091231 branch with trunk. 
>>> 
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>> 
>>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
>>> 
 Well I don't see any problem with dropping it in right now then.  The real 
 question will be what do people want to be able to backport once the 
 release branch is created.
 
 Regards
 Scott
 
 On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
 
> The security redesign implementation itself is mostly finished. There are 
> a few TODOs and they can be found in the BranchReadMe.txt file.
> 
> I recently synchronized the branch with the trunk and there is a remote 
> chance something in the design might have broken in the process. I need 
> to run some tests and review the code to see if that happened.
> 
> The Example component has been switched over to the new design.
> 
> There is a user login called "artifact-user" that demonstrates the new 
> design. That user login is restricted to using the Example component.
> 
> If the branch was merged back to the trunk and the new security design 
> was enabled, the Example component would use the new design and the 
> remaining components would still use the current security design. The two 
> can co-exist.
> 
> I imagine the process after that would be similar to when we introduced 
> the permission checking services - contributors can contribute code that 
> converts parts of the project over to the new security design. Conversion 
> involves removing hard-coded permission checks and creating seed data to 
> grant permission to component artifacts.
> 
> As I mentioned before, switching a component over to the new design can 
> create some unexpected problems. That's because our existing code has 
> security holes in it, and the new design plugs those holes - making parts 
> of the component unreachable. In other words, parts of code that happily 
> allow you to do things you don't have permission to do will start to 
> throw exceptions in the new design.
> 
> -Adrian
> 
> 
> Scott Gray wrote:
>> Question:
>> What exactly is the current status of the execution branch?  What is it 
>> that needs to be done for it to be enabled in the trunk?
>> I'm sorry if you feel you've already answered that question but I'm 
>> afraid it still isn't entirely clear to me.
>> Regards
>> Scott
>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote:
>>> If we wait, then we're waiting for evaluation and testing of the 
>>> branch. I've done all I can do - the code is written, I suggested we do 
>>> the merge before the release branch, and I gave my reasons for 
>>> suggesting it.
>>> 
>>> At this point in time I have stepped out of the discussion (in a 
>>> positive way) to give others a chance to look at the design and the 
>>> code and decide for themselves if it should be included. In other 
>>> words, I don't want to be in a position where I have to convince the 
>>> community what it should do. If the design and the implementation are 
>>> good, then there will be no need to convince anyone, right?
>>> 
>>> I'll answer questions about the executioncontext branch, and I'll 
>>> continue to work on it here and there whe

Re: Security Redesign and Release 10.x Branch

[Jacopo Cappellato]

Sorry if I am hijacking this thread, but the more I think of it the more I 
believe we should officially create an "alpha" release 10.04, instead of simply 
creating a release candidate for 10.04.
In this way we will have two official current releases:
09.04 Stable Release
10.04 Alpha Release

Intended audiences:
09.04: final users with no interest (or resources) in helping the community to 
build and maintain stable releases
10.04: users (they could be service providers, end user companies with internal 
resources or longer term goals etc...) that are willing to help the community 
to build and maintain a stable release

If there will be interest around the 10.04 alpha release, we will get bug fixes 
that will be part of a future 10.04.1 "stable" (bug fix) release (or a "beta" 
release), or even 10.04.2,3,4,5 etc... (each of them more stable than the 
predecessor).

Jacopo

On Apr 8, 2010, at 8:11 PM, Scott Gray wrote:

> Just to be clear though, I am NOT in favor of back-porting large chunks of 
> functionality to the release branch under the guise of bug fixes.
> 
> Regards
> Scott
> 
> On 8/04/2010, at 12:06 PM, Anil Patel wrote:
> 
>> Looks like, none who participated in this thread have objections for merging 
>> of securitycontext20091231 branch with trunk. 
>> 
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>> 
>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote:
>> 
>>> Well I don't see any problem with dropping it in right now then.  The real 
>>> question will be what do people want to be able to backport once the 
>>> release branch is created.
>>> 
>>> Regards
>>> Scott
>>> 
>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote:
>>> 
 The security redesign implementation itself is mostly finished. There are 
 a few TODOs and they can be found in the BranchReadMe.txt file.
 
 I recently synchronized the branch with the trunk and there is a remote 
 chance something in the design might have broken in the process. I need to 
 run some tests and review the code to see if that happened.
 
 The Example component has been switched over to the new design.
 
 There is a user login called "artifact-user" that demonstrates the new 
 design. That user login is restricted to using the Example component.
 
 If the branch was merged back to the trunk and the new security design was 
 enabled, the Example component would use the new design and the remaining 
 components would still use the current security design. The two can 
 co-exist.
 
 I imagine the process after that would be similar to when we introduced 
 the permission checking services - contributors can contribute code that 
 converts parts of the project over to the new security design. Conversion 
 involves removing hard-coded permission checks and creating seed data to 
 grant permission to component artifacts.
 
 As I mentioned before, switching a component over to the new design can 
 create some unexpected problems. That's because our existing code has 
 security holes in it, and the new design plugs those holes - making parts 
 of the component unreachable. In other words, parts of code that happily 
 allow you to do things you don't have permission to do will start to throw 
 exceptions in the new design.
 
 -Adrian
 
 
 Scott Gray wrote:
> Question:
> What exactly is the current status of the execution branch?  What is it 
> that needs to be done for it to be enabled in the trunk?
> I'm sorry if you feel you've already answered that question but I'm 
> afraid it still isn't entirely clear to me.
> Regards
> Scott
> On 7/04/2010, at 5:14 PM, Adrian Crum wrote:
>> If we wait, then we're waiting for evaluation and testing of the branch. 
>> I've done all I can do - the code is written, I suggested we do the 
>> merge before the release branch, and I gave my reasons for suggesting it.
>> 
>> At this point in time I have stepped out of the discussion (in a 
>> positive way) to give others a chance to look at the design and the code 
>> and decide for themselves if it should be included. In other words, I 
>> don't want to be in a position where I have to convince the community 
>> what it should do. If the design and the implementation are good, then 
>> there will be no need to convince anyone, right?
>> 
>> I'll answer questions about the executioncontext branch, and I'll 
>> continue to work on it here and there when I have the time. If the 
>> release branch is created without it, then that will be fine with me.
>> 
>> :-)
>> 
>> -Adrian
>> 
>> 
>> Scott Gray wrote:
>>> Considering we have yet to do an official release after 3.5 years and 
>>> the lack of user interest in our release branches (partly because we 

[jira] Commented: (OFBIZ-3587) application - marketing

[Jacques Le Roux (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856340#action_12856340
 ] 

Jacques Le Roux commented on OFBIZ-3587:


Thanks Bob,

It's months now that I want to refactor all the file. I will certainly do it 
one day...

> application - marketing
> ---
>
> Key: OFBIZ-3587
> URL: https://issues.apache.org/jira/browse/OFBIZ-3587
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Bob Morley
> Attachments: OFBIZ-3587_ResolveWarningsMarketing.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (OFBIZ-3446) Allow to open a layer lookup from a layer lookup

[Sascha Rodekamp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sascha Rodekamp updated OFBIZ-3446:
---

Attachment: OFBIZ-3446_LayoutFix.patch

Hi Jacques,
i extend my previous patch.
color issuses for buttons and links in flat grey, dropping crumbs, blue light, 
bizzness time fixed. 
next-last buttons in flat grey seems to be ok.


So long
Sascha

> Allow to open a layer lookup from a layer lookup
> 
>
> Key: OFBIZ-3446
> URL: https://issues.apache.org/jira/browse/OFBIZ-3446
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: SVN trunk
>
> Attachments: lookup.patch, OFBIZ-3446_FixCloseButton.patch, 
> OFBIZ-3446_LayoutFix.patch, OFBIZ-3446_LayoutFix.patch, 
> OFBIZ-3446_Lookup_in_Lookup.patch, OFBIZ-3446_Lookup_in_Lookup.patch
>
>
> This issue is really a blocker else we need to duplicate a lot of things. I 
> began to work in this direction but after few hours on them I think I will 
> preferably find a real solution than mucking around.
> I was not quite sure this was possible, but as Calendars are also called from 
> layered popups, it seems possible. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

OFBiz development and high level stories/requirements WAS: Re: squareFootage with decimals

[Jacopo Cappellato]

I would like to keep this conversation alive because I think it is an important 
one.
What do you think about the idea of creating and maintaining stories (*) that 
have to be referenced in commit logs (ideally each and every commit log should 
be associated to a story; the same story can be associated to several commit 
logs) as a way to focus the attention of the community around requirements 
behind commits?
I think it would be a valuable approach to enable the community interaction 
around requirements (instead of implementation as it is happening now) with the 
final goal of:
1) documenting the high level requirements (stories) available implemented by 
screens and artifacts in OFBiz
2) facilitate the participation in the growth of OFBiz of less technical 
contributors (e.g. analysts)

Jacopo

(*) An example of story could be the following one:
"Sales Orders are approved automatically when paid by credit card and CC 
authorization is successful.
Sales Orders are placed in Pending status approval after checkout then 
auto-approve once third-party payment processor (PayPal, GoogleCheckout, etc) 
sends notification.
Sales Orders are placed in Rejected status when authorization fails.
Once order is approved inventory is automatically reserved, reducing Available 
To Promise (ATP) quantity. If inventory is not available negative inventory 
reservations are created and the order is placed on back-order."

Company sends confirmation email to the Placing Customer."
On Apr 8, 2010, at 2:34 PM, Jacopo Cappellato wrote:

> This is an interesting comment. What we can d to improve this?
> Here is a suggestion: from now on each and every commit to trunk will have to 
> contain the reference to a (short) story that describes the context (i.e. 
> generic business process) that the commit is enhancing.
> This doesn't mean that there will be a story for each commit since several 
> commits will share the same story; over time we will create a good set of 
> stories and it will be easier, when a new story is added, to verify if it 
> represents an alternative/redundant feature etc...
> At the beginning there will be some overhead on the shoulders of committers, 
> but if we are good at keeping the stories consistent this would also help the 
> participation to non-tech guys.
> The stories could stay in Confluence or (maybe better) in Jira (easier to 
> associate commits to Jira tasks).
> 
> Jacopo
> 
> 
> On Apr 8, 2010, at 12:50 AM, David E Jones wrote:
> 
>> 
>> This may or may not help this conversation, but to be clear I no longer 
>> believe in the vision of a developer friendly community. Some good things 
>> certainly come from the model of community over code and developers being 
>> the most important part of a community, but my opinion these days is that e 
>> problems trump the benefits.
>> 
>> In an effort where there is a clear design with a written and accepted 
>> specification this model seems to work fine. However when the project is not 
>> simply implementing an established design what ensues is nothing short of 
>> chaos and fighting over design with no clear targets or requirements to help 
>> people make decisions.
>> 
>> In short that is why I don't believe in this model for OFBiz. We have 
>> problems with designs and not so much with implementation. Most of the 
>> problems in the project are due to bad design (or no design other than 
>> whatever the code happens to do) and no amount of good implementation can 
>> fix that. With testing efforts this will only become more pronounced. 
>> Testing efforts will reveal the lack of designs more and more,and while 
>> writing tests some functionality gaps will certainly be filled in, but the 
>> mind set of testing that includes trying all possibilities will result in 
>> enormous scope creep to add to the already staggering amount of unused code. 
>> Actually I'm wrong in using the term scope creep because that would imply 
>> that some sort of scope had been established before.
>> 
>> I mentioned some stuff about a better approach, or better priorities, in 
>> another email where I wrote a little about the NUMMI car plant as an 
>> interesting example of a possibly better way to go. Maybe it was silly to 
>> think it would ever work well this way and you can't get around prioritizing 
>> users over developers and code quality and good design over developers.
>> 
>> -David
>>