date:20110110


[ 
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979626#action_12979626
 ] 

Ryan Foster commented on OFBIZ-4092:


Oops, sorry Adrian.  I actually just did all these same things from your latest 
patch over the weekend. No big deal, I'll just patch your patch and go from 
there.  What other items do you have on your priority list that you are working 
on so we are not stepping on each others toes?

 Update The Flat Grey Visual Theme
 -

 Key: OFBIZ-4092
 URL: https://issues.apache.org/jira/browse/OFBIZ-4092
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
 Attachments: accounting800x600.png, catalog800x600.png, 
 catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, 
 flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, 
 partyDetail.png, partyManager.png, screenshot.gif, timeSheet.png


 Update the Flat Grey visual theme. Design objectives:
 1. Floating, flexible layout - screen can be resized.
 2. Sight impaired accessible - users can change font size in their browser.
 3. Supports RTL layout.
 4. Does not require JavaScript. JavaScript can be used to add embellishments, 
 but the theme can't depend on it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme

[
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979632#action_12979632
]

Ryan Foster commented on OFBIZ-4092:

I'm not sure that hard-coding the column count to 7 is that big of a deal.
That 7 is actually a max of 7, not a hard seven. The script loops through the
list items and fills the columns from top to bottom, left to right until it
reaches the end of the list. So, if there are only 8 applications in the list,
you will only have 2 columns, 12 apps means 3 columns, etc. 7 was chosen
because that is the break point of the horizontal fold. Anymore that 7 columns
and a horizontal scrollbar is created on an 800px width browser viewport.

Update The Flat Grey Visual Theme
-

Key: OFBIZ-4092
URL: https://issues.apache.org/jira/browse/OFBIZ-4092
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
Attachments: accounting800x600.png, catalog800x600.png,
catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch,
flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif,
partyDetail.png, partyManager.png, screenshot.gif, timeSheet.png

Update the Flat Grey visual theme. Design objectives:
1. Floating, flexible layout - screen can be resized.
2. Sight impaired accessible - users can change font size in their browser.
3. Supports RTL layout.
4. Does not require JavaScript. JavaScript can be used to add embellishments,
but the theme can't depend on it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme

[
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979640#action_12979640
]

Adrian Crum commented on OFBIZ-4092:

Ryan,

No worries. I also worked on making the masthead and main-navigation resizable
- so they grow and shrink with font size changes.

I would prefer to defer to you - you're the master, I'm the grasshopper. I will
wait for your update before proceeding further.

The main thing is to use Firefox, turn off JavaScript, change the default font
to 24 or higher, resize the screen and see what happens. The layout in the
patch you provided breaks badly under those conditions.

Update The Flat Grey Visual Theme
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme

[
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979639#action_12979639
]

Ryan Foster commented on OFBIZ-4092:

I also noticed you changed the design objectives to include a statement that
javascript should not be required. If that is the case, then I will really
have to step back and think about my approach for graceful degradation on the
main navigation since the key design principle for this section is based on the
fact that the list falls into columns.

I am curious as to why you feel this should be a key objective. Since the
framework web apps themselves are heavily dependent on javascript in certain
areas, shouldn't it be assumed that the user will always have javascript
available? If they don't, they are going have a lot more issues with
functionality than just having a visual display that is a little off.

Update The Flat Grey Visual Theme
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme


[ 
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979641#action_12979641
 ] 

Adrian Crum commented on OFBIZ-4092:


I added the 4th item because it was a part of the original Flat Grey theme, but 
I forgot to include it when I created this issue.

As far as I know, the screen widget renderers check to see if JavaScript is 
enabled and output the appropriate markup.


 Update The Flat Grey Visual Theme
 -

 Key: OFBIZ-4092
 URL: https://issues.apache.org/jira/browse/OFBIZ-4092
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
 Attachments: accounting800x600.png, catalog800x600.png, 
 catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, 
 flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, 
 partyDetail.png, partyManager.png, screenshot.gif, timeSheet.png


 Update the Flat Grey visual theme. Design objectives:
 1. Floating, flexible layout - screen can be resized.
 2. Sight impaired accessible - users can change font size in their browser.
 3. Supports RTL layout.
 4. Does not require JavaScript. JavaScript can be used to add embellishments, 
 but the theme can't depend on it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme

[
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979652#action_12979652
]

Ryan Foster commented on OFBIZ-4092:

hmm... Is there a way we can do something similar using FreeMarker in
appbar.ftl instead of using Javascript? Could we create a macro that reads the
numbers of apps then outputs a series of lists in the appropriate amount of
columns. If that is possible that would actually be a better solution since
then we wouldn't have to wait until the page fully loads and the DOM is ready
before applying the column styling.

Update The Flat Grey Visual Theme
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme


[ 
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979657#action_12979657
 ] 

Adrian Crum commented on OFBIZ-4092:


It's in my patch.


 Update The Flat Grey Visual Theme
 -

 Key: OFBIZ-4092
 URL: https://issues.apache.org/jira/browse/OFBIZ-4092
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
 Attachments: accounting800x600.png, catalog800x600.png, 
 catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, 
 flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, 
 partyDetail.png, partyManager.png, screenshot.gif, timeSheet.png


 Update the Flat Grey visual theme. Design objectives:
 1. Floating, flexible layout - screen can be resized.
 2. Sight impaired accessible - users can change font size in their browser.
 3. Supports RTL layout.
 4. Does not require JavaScript. JavaScript can be used to add embellishments, 
 but the theme can't depend on it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discussion: UI Best Practices - Edit versus Update

2011-01-10 Thread Jacques Le Roux


From: Adrian Crum adrian.c...@yahoo.com

I updated the UI Best Practices Wiki page with the information from our last 
discussion about Create versus Add versus New. We
ended up with +1 for Create, +2 for New, and +2 for Create New. I used the one 
common to all - Create New. Keep in mind this isn't
set in stone - we can still change it.


This sounds good to me, though for a purist in French it would be a pleonasm ;o)


See the Terminology section:

https://cwiki.apache.org/confluence/display/OFBADMIN/User+Interface+Layout+Best+Practices

In this discussion, I would like for us to come up with a best practice for 
Edit/Update terminology. If the user is modifying
existing data, what is the correct term to use in the UI? Edit? Modify? Update? 
Edit Existing? Update Existing? Or something else?


Modify, but I'm certainly biased by my mother tongue


While we are on that subject, what is the correct term to be used in the form's 
submit button? Save or Update?


Save (but Update would be as good for me, only that in French it's Mettre à jour vs 
Enregistrer - Sauvegarder being too
specific)

Sorry, not sure my comments are hepful at all :/

Jacques


Keep in mind there are no right or wrong answers, we are just trying to make 
the UI consistent.

-Adrian

Re: Discussion: UI Best Practices - Edit versus Update

2011-01-10 Thread Adrian Crum


Jacques,

Thank you for your comments! I thought we might have a problem setting 
up best practices for terminology - since the terms used will vary 
depending on the language.


I am not sure how to proceed. If we continue in English, then the best 
practices will be English-centric. Maybe have a section for each 
language? The text of the term isn't as important as using it consistently.


-Adrian

On 1/10/2011 9:54 AM, Jacques Le Roux wrote:

From: Adrian Crum adrian.c...@yahoo.com

I updated the UI Best Practices Wiki page with the information from
our last discussion about Create versus Add versus New. We
ended up with +1 for Create, +2 for New, and +2 for Create New. I used
the one common to all - Create New. Keep in mind this isn't
set in stone - we can still change it.


This sounds good to me, though for a purist in French it would be a
pleonasm ;o)


See the Terminology section:

https://cwiki.apache.org/confluence/display/OFBADMIN/User+Interface+Layout+Best+Practices


In this discussion, I would like for us to come up with a best
practice for Edit/Update terminology. If the user is modifying
existing data, what is the correct term to use in the UI? Edit?
Modify? Update? Edit Existing? Update Existing? Or something else?


Modify, but I'm certainly biased by my mother tongue


While we are on that subject, what is the correct term to be used in
the form's submit button? Save or Update?


Save (but Update would be as good for me, only that in French it's
Mettre à jour vs Enregistrer - Sauvegarder being too
specific)

Sorry, not sure my comments are hepful at all :/

Jacques


Keep in mind there are no right or wrong answers, we are just trying
to make the UI consistent.

-Adrian

Re: Discussion: UI Best Practices - Edit versus Update

2011-01-10 Thread Jacques Le Roux


Adrian,

I think we should focus on English, there already enough possible conflicts ;o)

Jacques

From: Adrian Crum adri...@hlmksw.com

Jacques,

Thank you for your comments! I thought we might have a problem setting up best practices for terminology - since the terms used 
will vary depending on the language.


I am not sure how to proceed. If we continue in English, then the best practices will be English-centric. Maybe have a section for 
each language? The text of the term isn't as important as using it consistently.


-Adrian

On 1/10/2011 9:54 AM, Jacques Le Roux wrote:

From: Adrian Crum adrian.c...@yahoo.com

I updated the UI Best Practices Wiki page with the information from
our last discussion about Create versus Add versus New. We
ended up with +1 for Create, +2 for New, and +2 for Create New. I used
the one common to all - Create New. Keep in mind this isn't
set in stone - we can still change it.


This sounds good to me, though for a purist in French it would be a
pleonasm ;o)


See the Terminology section:

https://cwiki.apache.org/confluence/display/OFBADMIN/User+Interface+Layout+Best+Practices


In this discussion, I would like for us to come up with a best
practice for Edit/Update terminology. If the user is modifying
existing data, what is the correct term to use in the UI? Edit?
Modify? Update? Edit Existing? Update Existing? Or something else?


Modify, but I'm certainly biased by my mother tongue


While we are on that subject, what is the correct term to be used in
the form's submit button? Save or Update?


Save (but Update would be as good for me, only that in French it's
Mettre à jour vs Enregistrer - Sauvegarder being too
specific)

Sorry, not sure my comments are hepful at all :/

Jacques


Keep in mind there are no right or wrong answers, we are just trying
to make the UI consistent.

-Adrian

Re: Discussion: UI Best Practices - Edit versus Update

2011-01-10 Thread Bruno Busco

Adrian,
I would use Edit and Save.

Thank you for your effort on improving consistency.

-Bruno

2011/1/10 Jacques Le Roux jacques.le.r...@les7arts.com

Adrian,

I think we should focus on English, there already enough possible conflicts
;o)

Jacques

From: Adrian Crum adri...@hlmksw.com

Jacques,

Thank you for your comments! I thought we might have a problem setting up
best practices for terminology - since the terms used will vary depending on
the language.

I am not sure how to proceed. If we continue in English, then the best
practices will be English-centric. Maybe have a section for each language?
The text of the term isn't as important as using it consistently.

-Adrian

On 1/10/2011 9:54 AM, Jacques Le Roux wrote:

From: Adrian Crum adrian.c...@yahoo.com

I updated the UI Best Practices Wiki page with the information from
our last discussion about Create versus Add versus New. We
ended up with +1 for Create, +2 for New, and +2 for Create New. I used
the one common to all - Create New. Keep in mind this isn't
set in stone - we can still change it.

This sounds good to me, though for a purist in French it would be a
pleonasm ;o)

See the Terminology section:

https://cwiki.apache.org/confluence/display/OFBADMIN/User+Interface+Layout+Best+Practices

In this discussion, I would like for us to come up with a best
practice for Edit/Update terminology. If the user is modifying
existing data, what is the correct term to use in the UI? Edit?
Modify? Update? Edit Existing? Update Existing? Or something else?

Modify, but I'm certainly biased by my mother tongue

While we are on that subject, what is the correct term to be used in
the form's submit button? Save or Update?

Save (but Update would be as good for me, only that in French it's
Mettre à jour vs Enregistrer - Sauvegarder being too
specific)

Sorry, not sure my comments are hepful at all :/

Jacques

Keep in mind there are no right or wrong answers, we are just trying
to make the UI consistent.

-Adrian

Tax

2011-01-10 Thread Luís Maranesi

Hello,

I'd like to if any of you can point me some document to understand better
how the taxation is dealt in OFBiz. I've already read this document
https://cwiki.apache.org/confluence/display/OFBIZ/Guide+to+OFBiz-i18n%2C++
Internationalisation+of+OFBiz but there is nothing written there yet.

If I needed, for example, to adapt it for Brazilian taxation what would be
the first step? Could someone indicate me where in the code I can start my
investigation?

Thanks,
Luís Maranesi

Re: Party Classification Data Modeling

2011-01-10 Thread Adrian Crum

I spent some time in Party Manager trying to make sense of the Party 
Classification feature, and I can't seem to make it do anything meaningful. 
Maybe I'm not understanding something, so I'll provide an example and see if 
anyone knows how to implement it in the current code.

In table 2.3 of the Data Model Resource Book, there is a party named Marc 
Martinez who has been classified as Hispanic. I will use him for my example.

In Party Manager I create a person named Marc Martinez and I want to classify 
him as Hispanic. I would also like to include the Hispanic classification in 
two classification groups: US Minorities and Non-White. I go to the 
Classifications tab - where I can create classification groups from a list of 
pre-defined group types. I choose the Minority type, type US Minorities in 
the Description field, and save the group. I want to add the Hispanic 
classification to this group, but I don't see any way to add classifications. I 
go to Marc's profile page and try to assign him a classification, but I can 
only assign him to a classification group. If I assign him to the US 
Minorities group that still doesn't classify him as Hispanic. 

As far as I can tell, Party Classification doesn't work.

Any ideas?

-Adrian


--- On Mon, 1/3/11, Adrian Crum adrian.c...@yahoo.com wrote:
 Understood. If we wanted to create
 entities to avoid the sub-types mentioned in the book
 (Organization Classification, Person Classisfication, etc)
 then I think we could have done that in a simpler way and
 still keep the book's model:
 
 PartyClassificationGroupType
 
 *groupTypeId
 description
 parentGroupTypeId
 
 PartyClassificationGroup
 
 *groupTypeId
 *partyTypeId
 
 Anyways, I have come up with a workaround. I'll just use
 the existing PartyClassificationGroup the way the book uses
 PartyType.
 
 -Adrian
 
 
 --- On Mon, 1/3/11, David E Jones d...@me.com
 wrote:
  Every single *Type entity in OFBiz is a deviation from
 the
  book (ie the *Type entities are an OFBiz pattern to
 avoid
  redundant entities and keep track of entity extensions
 like
  the Party - PartyGroup,Person thingy), as are
 dozens of
  other entities and hundreds of fields. That book is
 valuable
  for general concepts and patterns, and is not an
 actual data
  model to be used as-is.
  
  -David
  
  
  On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote:
  
   I don't think I'm generalizing anything. The book
 is
  pretty specific and clear: Party Classification is an
  intersection entity that sets up a many-to-many
 relationship
  between the Party entity and the Party Type entity.
   
   I understand OFBiz deviates from the book here
 and
  there, and if this is one of those cases, then I'll
 ask
  again: Why was it done that way?
   
   I'm trying to make sense of the OFBiz Party
  Classification model, and so far it doesn't make
 sense. The
  way it is set up, I can't give a party a
 classification
  without first creating a classification group, assign
 a
  classification type to it, and then assign the party
 to the
  classification group using party classification.
   
   In the book it's much simpler - I just assign a
 party
  type to a party using a party classification.
 Classification
  groups are Party Classification sub-types and they
 aren't
  necessary unless I want to group things a certain
 way.
   
   -Adrian
   
   --- On Mon, 1/3/11, David E Jones d...@me.com
  wrote:
   I think you may be taking the specific term
 type
  and
   generalizing it. Consider that *Type entities
 in
  OFBiz mean
   something very specific, and it is different
 from
  the more
   general use of the term in the book.
   
   -David
   
   
   On Jan 3, 2011, at 3:24 PM, Adrian Crum
 wrote:
   
   That's not what the book shows. There is
 a
  simple
   relationship:
   
   Party - PartyClassification -
  PartyType
   
   If you want to group classifications,
 give
  them
   parent/child relationships, etc then you do
 it
  with
   PartyType, not PartyClassification. Look at
 table
  2.3 on
   page 32.
   
   -Adrian
   
   --- On Mon, 1/3/11, BJ Freeman bjf...@free-man.net
   wrote:
   how about a pattern of parent child
   for PartyClassification of supertype
 
      and the sub types then use a
   table for the
   attributess of the subtype.
   this would allow walking the parnent
  child
   relationships.
   PartyClassification 
   
  
 
 ---organizationClassificationminorityClassification
             
    
     
           
     
   
     industryclassification
   
   =
   BJ Freeman
   Strategic Power Office with Supplier
  Automation 
   http://www.businessesnetwork.com/automation/viewforum.php?f=52
   Specialtymarket.com  http://www.specialtymarket.com/
   Systems Integrator-- Glad to Assist
   
   Chat  Y! messenger: bjfr33man
   
   
   Adrian Crum sent the following on
 1/3/2011
  2:46
   PM:
   PartyClassificationGroup should
 have
  a

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme

[
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979870#action_12979870
]

Ryan Foster commented on OFBIZ-4092:

duh, I guess I should have actually read your patch first before I started
thinking out loud. Your solution looks great. I made couple of small tweaks
to it to remove some markup that I thought wasn't really necessary. For
instance, we don't really need to enclose each app title in in a p tag since
the a is already set to display block. I also put a set height to the li
tag and removed the empty p tags with spaces from the last li. Please
don't take this personally, but one of my biggest pet peeves is using spaces
and breaks in markup to control layout. Let's try to avoid that as much as
possible.

I have incorporated the changes from your last patch and made a few more design
changes as well in my latest patch.

1. added additional styling to the main navigation to highlight the select app
a bit more.
2. expanded on your change to the selected app navigation link to give it even
more distinction
3. enhanced the styling of the tab-bar area.
4. added some misc. CSS3 styling enhancements to main nav and app nav areas
for browsers that support text-shadow.

Update The Flat Grey Visual Theme
-

Key: OFBIZ-4092
URL: https://issues.apache.org/jira/browse/OFBIZ-4092
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
Attachments: accounting800x600.png, catalog800x600.png,
catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch,
flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip,
ofbiz_logo.gif, partyDetail.png, partyManager.png, screenshot.gif,
timeSheet.png

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4092) Update The Flat Grey Visual Theme


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

Ryan Foster updated OFBIZ-4092:
---

Attachment: flatgrey.patch

 Update The Flat Grey Visual Theme
 -

 Key: OFBIZ-4092
 URL: https://issues.apache.org/jira/browse/OFBIZ-4092
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
 Attachments: accounting800x600.png, catalog800x600.png, 
 catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, 
 flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, 
 ofbiz_logo.gif, partyDetail.png, partyManager.png, screenshot.gif, 
 timeSheet.png


 Update the Flat Grey visual theme. Design objectives:
 1. Floating, flexible layout - screen can be resized.
 2. Sight impaired accessible - users can change font size in their browser.
 3. Supports RTL layout.
 4. Does not require JavaScript. JavaScript can be used to add embellishments, 
 but the theme can't depend on it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Party Classification Data Modeling

2011-01-10 Thread David E Jones


Your understanding of the data model is not correct.

The PartyClassification entity is just a join entity between Party and 
PartyClassificationGroup. The entity definition itself can help clarify this 
because it follows the same pattern as join entities in general in OFBiz, ie 
the fields are (the first 3 are pks):

partyId*
partyClassificationGroupId*
fromDate*
thruDate

This is the basic pattern for join entities. Other example include 
PartyContent, ProductContent, ProductCategoryMember, and dozens (hundreds?) of 
others. Any time two entities have a many-to-many relationship a join entity is 
needed to go between them.

For PartyClassificationGroup note that it has a parentGroupId field making 
the structure hierarchical (like many other *Type and other entities that need 
a simple hierarchy).

In your example Hispanic would be a PartyClassificationGroup that is a child of 
the US Minorities group. Note that the current structure is a pure hierarchy, 
ie it is not a graph, and each node can only have a single parent. If you want 
a PartyClassificationGroup to have multiple parents then you'll need another 
join entity to model that many-to-many relationship (much like 
ProductCategoryRollup).

-David


On Jan 10, 2011, at 4:27 PM, Adrian Crum wrote:

 I spent some time in Party Manager trying to make sense of the Party 
 Classification feature, and I can't seem to make it do anything meaningful. 
 Maybe I'm not understanding something, so I'll provide an example and see if 
 anyone knows how to implement it in the current code.
 
 In table 2.3 of the Data Model Resource Book, there is a party named Marc 
 Martinez who has been classified as Hispanic. I will use him for my example.
 
 In Party Manager I create a person named Marc Martinez and I want to classify 
 him as Hispanic. I would also like to include the Hispanic classification in 
 two classification groups: US Minorities and Non-White. I go to the 
 Classifications tab - where I can create classification groups from a list of 
 pre-defined group types. I choose the Minority type, type US Minorities in 
 the Description field, and save the group. I want to add the Hispanic 
 classification to this group, but I don't see any way to add classifications. 
 I go to Marc's profile page and try to assign him a classification, but I can 
 only assign him to a classification group. If I assign him to the US 
 Minorities group that still doesn't classify him as Hispanic. 
 
 As far as I can tell, Party Classification doesn't work.
 
 Any ideas?
 
 -Adrian
 
 
 --- On Mon, 1/3/11, Adrian Crum adrian.c...@yahoo.com wrote:
 Understood. If we wanted to create
 entities to avoid the sub-types mentioned in the book
 (Organization Classification, Person Classisfication, etc)
 then I think we could have done that in a simpler way and
 still keep the book's model:
 
 PartyClassificationGroupType
 
 *groupTypeId
 description
 parentGroupTypeId
 
 PartyClassificationGroup
 
 *groupTypeId
 *partyTypeId
 
 Anyways, I have come up with a workaround. I'll just use
 the existing PartyClassificationGroup the way the book uses
 PartyType.
 
 -Adrian
 
 
 --- On Mon, 1/3/11, David E Jones d...@me.com
 wrote:
 Every single *Type entity in OFBiz is a deviation from
 the
 book (ie the *Type entities are an OFBiz pattern to
 avoid
 redundant entities and keep track of entity extensions
 like
 the Party - PartyGroup,Person thingy), as are
 dozens of
 other entities and hundreds of fields. That book is
 valuable
 for general concepts and patterns, and is not an
 actual data
 model to be used as-is.
 
 -David
 
 
 On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote:
 
 I don't think I'm generalizing anything. The book
 is
 pretty specific and clear: Party Classification is an
 intersection entity that sets up a many-to-many
 relationship
 between the Party entity and the Party Type entity.
 
 I understand OFBiz deviates from the book here
 and
 there, and if this is one of those cases, then I'll
 ask
 again: Why was it done that way?
 
 I'm trying to make sense of the OFBiz Party
 Classification model, and so far it doesn't make
 sense. The
 way it is set up, I can't give a party a
 classification
 without first creating a classification group, assign
 a
 classification type to it, and then assign the party
 to the
 classification group using party classification.
 
 In the book it's much simpler - I just assign a
 party
 type to a party using a party classification.
 Classification
 groups are Party Classification sub-types and they
 aren't
 necessary unless I want to group things a certain
 way.
 
 -Adrian
 
 --- On Mon, 1/3/11, David E Jones d...@me.com
 wrote:
 I think you may be taking the specific term
 type
 and
 generalizing it. Consider that *Type entities
 in
 OFBiz mean
 something very specific, and it is different
 from
 the more
 general use of the term in the book.
 
 -David
 
 
 On Jan 3, 2011, at 3:24 PM, Adrian

[jira] Updated: (OFBIZ-2361) Category URL conflicts with product URL

2011-01-10 Thread Wasun Sriwichai (JIRA)

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

Wasun Sriwichai updated OFBIZ-2361:
---

Attachment: CatalogUrlServlet.patch

This patch will solve the problem when the category_id and product_id URLs are
the same, It can identify which id belong to the category or product.

The process is URL checking, suppose that category_id = 100 as same as
product_id and first the category URL is URL = ecommerce/products/100, the
process will check that the first ID in the URL always be the category_id so
the category page will display. Secondly, the category URL is URL =
ecommerce/products/100/100, the process will check that the first ID is always
the category_id and it cannot be duplicate in the URL so the next ID have to be
the product_id and product page will be displayed.

Category URL conflicts with product URL
---

Key: OFBIZ-2361
URL: https://issues.apache.org/jira/browse/OFBIZ-2361
Project: OFBiz
Issue Type: Bug
Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Environment: red hat, postgres
Reporter: Rohit Sureka
Attachments: CatalogUrlServlet.patch

Hi,
I just found out a potential bug in the new URL structure for category links
in the ecommerce page.
The new URL's for a category link reads as
http://demo.ofbiz.org/ecommerce/products/100/100
here 100 is the category ID, this URL should ideally list all products in the
category with ID 100. However if we create a product with ID 100 ie.
product_id=100, there arise the bug. Instead of all item being shown in the
category, the product page for product_id 100 is displayed, irrespective of
the category/catalog/store that product ID belongs to.
I think this is a unusual behavior, and may cause problems for people wanting
to move on to newer code.
Please let me know if should open a jira issue for it.
Rohit

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Party Classification Data Modeling

2011-01-10 Thread Adrian Crum

Yeah, the PartyClassificationGroup would have many parents - that's how the 
book has it modeled. PartyType has a one-to-many relationship with the 
PartyClassification super type, so a PartyType could point to more than one 
PartyClassification subtype.

I'm starting to have a sense of deja-vu - like we've discussed this before in 
the past. I'll have to dig through my mail archives.

Thanks for the clarification!

-Adrian

--- On Mon, 1/10/11, David E Jones d...@me.com wrote:
 Your understanding of the data model is not correct.
 
 The PartyClassification entity is just a join entity
 between Party and PartyClassificationGroup. The entity
 definition itself can help clarify this because it follows
 the same pattern as join entities in general in OFBiz, ie
 the fields are (the first 3 are pks):
 
 partyId*
 partyClassificationGroupId*
 fromDate*
 thruDate
 
 This is the basic pattern for join entities. Other example
 include PartyContent, ProductContent, ProductCategoryMember,
 and dozens (hundreds?) of others. Any time two entities have
 a many-to-many relationship a join entity is needed to go
 between them.
 
 For PartyClassificationGroup note that it has a
 parentGroupId field making the structure hierarchical
 (like many other *Type and other entities that need a simple
 hierarchy).
 
 In your example Hispanic would be a
 PartyClassificationGroup that is a child of the US
 Minorities group. Note that the current structure is a pure
 hierarchy, ie it is not a graph, and each node can only have
 a single parent. If you want a PartyClassificationGroup to
 have multiple parents then you'll need another join entity
 to model that many-to-many relationship (much like
 ProductCategoryRollup).
 
 -David
 
 
 On Jan 10, 2011, at 4:27 PM, Adrian Crum wrote:
 
  I spent some time in Party Manager trying to make
 sense of the Party Classification feature, and I can't seem
 to make it do anything meaningful. Maybe I'm not
 understanding something, so I'll provide an example and see
 if anyone knows how to implement it in the current code.
  
  In table 2.3 of the Data Model Resource Book, there is
 a party named Marc Martinez who has been classified as
 Hispanic. I will use him for my example.
  
  In Party Manager I create a person named Marc Martinez
 and I want to classify him as Hispanic. I would also like to
 include the Hispanic classification in two classification
 groups: US Minorities and Non-White. I go to the
 Classifications tab - where I can create classification
 groups from a list of pre-defined group types. I choose the
 Minority type, type US Minorities in the Description
 field, and save the group. I want to add the Hispanic
 classification to this group, but I don't see any way to add
 classifications. I go to Marc's profile page and try to
 assign him a classification, but I can only assign him to a
 classification group. If I assign him to the US Minorities
 group that still doesn't classify him as Hispanic. 
  
  As far as I can tell, Party Classification doesn't
 work.
  
  Any ideas?
  
  -Adrian
  
  
  --- On Mon, 1/3/11, Adrian Crum adrian.c...@yahoo.com
 wrote:
  Understood. If we wanted to create
  entities to avoid the sub-types mentioned in the
 book
  (Organization Classification, Person
 Classisfication, etc)
  then I think we could have done that in a simpler
 way and
  still keep the book's model:
  
  PartyClassificationGroupType
  
  *groupTypeId
  description
  parentGroupTypeId
  
  PartyClassificationGroup
  
  *groupTypeId
  *partyTypeId
  
  Anyways, I have come up with a workaround. I'll
 just use
  the existing PartyClassificationGroup the way the
 book uses
  PartyType.
  
  -Adrian
  
  
  --- On Mon, 1/3/11, David E Jones d...@me.com
  wrote:
  Every single *Type entity in OFBiz is a
 deviation from
  the
  book (ie the *Type entities are an OFBiz
 pattern to
  avoid
  redundant entities and keep track of entity
 extensions
  like
  the Party - PartyGroup,Person thingy), as
 are
  dozens of
  other entities and hundreds of fields. That
 book is
  valuable
  for general concepts and patterns, and is not
 an
  actual data
  model to be used as-is.
  
  -David
  
  
  On Jan 3, 2011, at 5:57 PM, Adrian Crum
 wrote:
  
  I don't think I'm generalizing anything.
 The book
  is
  pretty specific and clear: Party
 Classification is an
  intersection entity that sets up a
 many-to-many
  relationship
  between the Party entity and the Party Type
 entity.
  
  I understand OFBiz deviates from the book
 here
  and
  there, and if this is one of those cases, then
 I'll
  ask
  again: Why was it done that way?
  
  I'm trying to make sense of the OFBiz
 Party
  Classification model, and so far it doesn't
 make
  sense. The
  way it is set up, I can't give a party a
  classification
  without first creating a classification group,
 assign
  a
  classification type to it, and then assign the
 party
  to the
  classification

Re: Party Classification Data Modeling

2011-01-10 Thread David E Jones


Quick note: as per our earlier discussion keep in mind that PartyType in OFBiz 
has nothing/zippo/zero to do with what is referred to as party type in the 
book.

-David


On Jan 10, 2011, at 8:55 PM, Adrian Crum wrote:

 Yeah, the PartyClassificationGroup would have many parents - that's how the 
 book has it modeled. PartyType has a one-to-many relationship with the 
 PartyClassification super type, so a PartyType could point to more than one 
 PartyClassification subtype.
 
 I'm starting to have a sense of deja-vu - like we've discussed this before in 
 the past. I'll have to dig through my mail archives.
 
 Thanks for the clarification!
 
 -Adrian
 
 --- On Mon, 1/10/11, David E Jones d...@me.com wrote:
 Your understanding of the data model is not correct.
 
 The PartyClassification entity is just a join entity
 between Party and PartyClassificationGroup. The entity
 definition itself can help clarify this because it follows
 the same pattern as join entities in general in OFBiz, ie
 the fields are (the first 3 are pks):
 
 partyId*
 partyClassificationGroupId*
 fromDate*
 thruDate
 
 This is the basic pattern for join entities. Other example
 include PartyContent, ProductContent, ProductCategoryMember,
 and dozens (hundreds?) of others. Any time two entities have
 a many-to-many relationship a join entity is needed to go
 between them.
 
 For PartyClassificationGroup note that it has a
 parentGroupId field making the structure hierarchical
 (like many other *Type and other entities that need a simple
 hierarchy).
 
 In your example Hispanic would be a
 PartyClassificationGroup that is a child of the US
 Minorities group. Note that the current structure is a pure
 hierarchy, ie it is not a graph, and each node can only have
 a single parent. If you want a PartyClassificationGroup to
 have multiple parents then you'll need another join entity
 to model that many-to-many relationship (much like
 ProductCategoryRollup).
 
 -David
 
 
 On Jan 10, 2011, at 4:27 PM, Adrian Crum wrote:
 
 I spent some time in Party Manager trying to make
 sense of the Party Classification feature, and I can't seem
 to make it do anything meaningful. Maybe I'm not
 understanding something, so I'll provide an example and see
 if anyone knows how to implement it in the current code.
 
 In table 2.3 of the Data Model Resource Book, there is
 a party named Marc Martinez who has been classified as
 Hispanic. I will use him for my example.
 
 In Party Manager I create a person named Marc Martinez
 and I want to classify him as Hispanic. I would also like to
 include the Hispanic classification in two classification
 groups: US Minorities and Non-White. I go to the
 Classifications tab - where I can create classification
 groups from a list of pre-defined group types. I choose the
 Minority type, type US Minorities in the Description
 field, and save the group. I want to add the Hispanic
 classification to this group, but I don't see any way to add
 classifications. I go to Marc's profile page and try to
 assign him a classification, but I can only assign him to a
 classification group. If I assign him to the US Minorities
 group that still doesn't classify him as Hispanic. 
 
 As far as I can tell, Party Classification doesn't
 work.
 
 Any ideas?
 
 -Adrian
 
 
 --- On Mon, 1/3/11, Adrian Crum adrian.c...@yahoo.com
 wrote:
 Understood. If we wanted to create
 entities to avoid the sub-types mentioned in the
 book
 (Organization Classification, Person
 Classisfication, etc)
 then I think we could have done that in a simpler
 way and
 still keep the book's model:
 
 PartyClassificationGroupType
 
 *groupTypeId
 description
 parentGroupTypeId
 
 PartyClassificationGroup
 
 *groupTypeId
 *partyTypeId
 
 Anyways, I have come up with a workaround. I'll
 just use
 the existing PartyClassificationGroup the way the
 book uses
 PartyType.
 
 -Adrian
 
 
 --- On Mon, 1/3/11, David E Jones d...@me.com
 wrote:
 Every single *Type entity in OFBiz is a
 deviation from
 the
 book (ie the *Type entities are an OFBiz
 pattern to
 avoid
 redundant entities and keep track of entity
 extensions
 like
 the Party - PartyGroup,Person thingy), as
 are
 dozens of
 other entities and hundreds of fields. That
 book is
 valuable
 for general concepts and patterns, and is not
 an
 actual data
 model to be used as-is.
 
 -David
 
 
 On Jan 3, 2011, at 5:57 PM, Adrian Crum
 wrote:
 
 I don't think I'm generalizing anything.
 The book
 is
 pretty specific and clear: Party
 Classification is an
 intersection entity that sets up a
 many-to-many
 relationship
 between the Party entity and the Party Type
 entity.
 
 I understand OFBiz deviates from the book
 here
 and
 there, and if this is one of those cases, then
 I'll
 ask
 again: Why was it done that way?
 
 I'm trying to make sense of the OFBiz
 Party
 Classification model, and so far it doesn't
 make
 sense. The
 way it is set up, I can't give a party a

[jira] Created: (OFBIZ-4105) findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

findOrdersToPickMove: EntityListIterator not closed if no Picklist generated


 Key: OFBIZ-4105
 URL: https://issues.apache.org/jira/browse/OFBIZ-4105
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: SVN trunk
Reporter: Paul Foxworthy
Priority: Minor
 Fix For: SVN trunk


Got to ordermgr/control/orderview for an order that doesn't have stock ready 
for picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking, 
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed, so 
a warning message was logged when the finalize was executed.

The problem is in

applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml

There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.

After the entity-conditon is created, there's an if element, and the iterator 
is only used when the if condition is false, i.e. the else part is executed.

My fix is simply to move the entity-condition, complete with use-iterator, 
within the else element so the condition is evaluated and the iterator created 
only when the iterator will be used.

I'm not 100% sure this is the best fix and would appreciate some feedback.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4092) Update The Flat Grey Visual Theme

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

Adrian Crum updated OFBIZ-4092:
---

Attachment: ac_images.zip
ac_flatgrey.patch

Ryan,

I have attached files that represent what I had developed just prior to today's
conversation. Take a look at the changes and see if you can use any more ideas
from them. The masthead, main-application, and app-navigation areas grow with
font size changes - try it out. That required some background changes in CSS
and PNG files.

I tried out your new patch. I think you went a little too far to the other
extreme. ;-) Maybe we could stick with the styles in my last patch.

I really like the idea of visual elements floating on sand. In this updated
patch I made it the background for the HTML element - that way we can move
things around if we want. The page-title style might benefit from a drop
shadow. I'm not sure about the drop shadow on the app-navigation - it looks odd
to me.

Btw, I tested my changes with Firefox, Safari, and IE8.

I think we're almost there!

Update The Flat Grey Visual Theme
-

Key: OFBIZ-4092
URL: https://issues.apache.org/jira/browse/OFBIZ-4092
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
Attachments: ac_flatgrey.patch, ac_images.zip, accounting800x600.png,
catalog800x600.png, catalogManager.png, content800x600.png,
contentManager.png, flatgrey.patch, flatgrey.patch, flatgrey.patch,
flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, partyDetail.png,
partyManager.png, screenshot.gif, timeSheet.png

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4105) findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

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

Paul Foxworthy updated OFBIZ-4105:
--

Attachment: OFBIZ-4105_iterator_not_closed.patch

findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

Key: OFBIZ-4105
URL: https://issues.apache.org/jira/browse/OFBIZ-4105
Project: OFBiz
Issue Type: Bug
Components: order
Affects Versions: SVN trunk
Reporter: Paul Foxworthy
Priority: Minor
Fix For: SVN trunk

Attachments: OFBIZ-4105_iterator_not_closed.patch

Got to ordermgr/control/orderview for an order that doesn't have stock ready
for picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking,
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed,
so a warning message was logged when the finalize was executed.
The problem is in
applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml
There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.
After the entity-conditon is created, there's an if element, and the
iterator is only used when the if condition is false, i.e. the else part
is executed.
My fix is simply to move the entity-condition, complete with
use-iterator, within the else element so the condition is evaluated and the
iterator created only when the iterator will be used.
I'm not 100% sure this is the best fix and would appreciate some feedback.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4105) findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

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

Paul Foxworthy updated OFBIZ-4105:
--

Description:
Go to ordermgr/control/orderview for an order that doesn't have stock ready for
picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking,
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed, so
a warning message was logged when the finalize was executed.

The problem is in

applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml

There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.

After the entity-conditon is created, there's an if element, and the iterator
is only used when the if condition is false, i.e. the else part is executed.

My fix is simply to move the entity-condition, complete with use-iterator,
within the else element so the condition is evaluated and the iterator
created only when the iterator will be used.

I'm not 100% sure this is the best fix and would appreciate some feedback.

was:
Got to ordermgr/control/orderview for an order that doesn't have stock ready
for picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking,
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed, so
a warning message was logged when the finalize was executed.

The problem is in

applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml

There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.

After the entity-conditon is created, there's an if element, and the iterator
is only used when the if condition is false, i.e. the else part is executed.

My fix is simply to move the entity-condition, complete with use-iterator,
within the else element so the condition is evaluated and the iterator created
only when the iterator will be used.

I'm not 100% sure this is the best fix and would appreciate some feedback.

findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

Attachments: OFBIZ-4105_iterator_not_closed.patch

Go to ordermgr/control/orderview for an order that doesn't have stock ready
for picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking,
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed,
so a warning message was logged when the finalize was executed.
The problem is in
applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml
There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.
After the entity-conditon is created, there's an if element, and the
iterator is only used when the if condition is false, i.e. the else part
is executed.
My fix is simply to move the entity-condition, complete with
use-iterator, within the else element so the condition is evaluated and
the iterator created only when the iterator will be used.
I'm not 100% sure this is the best fix and would appreciate some feedback.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme


[ 
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979955#action_12979955
 ] 

Adrian Crum commented on OFBIZ-4092:


Also note that I changed the bevels in the main-navigation so their shadow 
matches the other elements.

 Update The Flat Grey Visual Theme
 -

 Key: OFBIZ-4092
 URL: https://issues.apache.org/jira/browse/OFBIZ-4092
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
 Attachments: ac_flatgrey.patch, ac_images.zip, accounting800x600.png, 
 catalog800x600.png, catalogManager.png, content800x600.png, 
 contentManager.png, flatgrey.patch, flatgrey.patch, flatgrey.patch, 
 flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, partyDetail.png, 
 partyManager.png, screenshot.gif, timeSheet.png


 Update the Flat Grey visual theme. Design objectives:
 1. Floating, flexible layout - screen can be resized.
 2. Sight impaired accessible - users can change font size in their browser.
 3. Supports RTL layout.
 4. Does not require JavaScript. JavaScript can be used to add embellishments, 
 but the theme can't depend on it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4105) findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

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

Paul Foxworthy updated OFBIZ-4105:
--

The problem is in

applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml

There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.

After the entity-condition element, there's an if element, and the iterator
is only used when the if condition is false, i.e. the else part is executed.

My fix is simply to move the entity-condition, complete with use-iterator,
within the else element so the condition is evaluated and the iterator
created only when the iterator will be used.

I'm not 100% sure this is the best fix and would appreciate some feedback.

was:
Go to ordermgr/control/orderview for an order that doesn't have stock ready for
picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking,
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed, so
a warning message was logged when the finalize was executed.

The problem is in

applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml

There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.

After the entity-conditon is created, there's an if element, and the iterator
is only used when the if condition is false, i.e. the else part is executed.

My fix is simply to move the entity-condition, complete with use-iterator,
within the else element so the condition is evaluated and the iterator
created only when the iterator will be used.

I'm not 100% sure this is the best fix and would appreciate some feedback.

findOrdersToPickMove: EntityListIterator not closed if no Picklist generated

Attachments: OFBIZ-4105_iterator_not_closed.patch

Go to ordermgr/control/orderview for an order that doesn't have stock ready
for picking.
Click on Prink Pick Sheet
You'll get a Pick Sheet PDF with the message Order not ready for picking,
needs stock move
Look at logs, you'll see an EntityListIterator was created and never closed,
so a warning message was logged when the finalize was executed.
The problem is in
applications/product/script/org/ofbiz/shipment/picklist/PicklistServices.xml
There's a use-iterator/ for the OrderHeaderAndItemFacilityLocation entity.
After the entity-condition element, there's an if element, and the iterator
is only used when the if condition is false, i.e. the else part is
executed.
My fix is simply to move the entity-condition, complete with
use-iterator, within the else element so the condition is evaluated and
the iterator created only when the iterator will be used.
I'm not 100% sure this is the best fix and would appreciate some feedback.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4105) findOrdersToPickMove: EntityListIterator not closed if no Picklist generated