[jira] [Updated] (OFBIZ-4713) Add german translation to AccountingErrorUiLabels.xml
[ https://issues.apache.org/jira/browse/OFBIZ-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4713: - Attachment: OFBIZ-4713-add-german-translation-to-AccountingErrorUiLabels.patch First minor adoption of some translations, there are still a lot translations missing. Add german translation to AccountingErrorUiLabels.xml - Key: OFBIZ-4713 URL: https://issues.apache.org/jira/browse/OFBIZ-4713 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Markus M. May Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-4713-add-german-translation-to-AccountingErrorUiLabels.patch The German translation is missing in AccountingErrorUiLabels.xml . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-4713) Add german translation to AccountingErrorUiLabels.xml
[ https://issues.apache.org/jira/browse/OFBIZ-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp reassigned OFBIZ-4713: -- Assignee: Sascha Rodekamp Add german translation to AccountingErrorUiLabels.xml - Key: OFBIZ-4713 URL: https://issues.apache.org/jira/browse/OFBIZ-4713 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Markus M. May Assignee: Sascha Rodekamp Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-4713-add-german-translation-to-AccountingErrorUiLabels.patch The German translation is missing in AccountingErrorUiLabels.xml . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4713) Add german translation to AccountingErrorUiLabels.xml
[ https://issues.apache.org/jira/browse/OFBIZ-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp closed OFBIZ-4713. -- Resolution: Fixed Hi Markus, thanks for the translation, the patch is in trunk @Rev1292703 I will close the issue, if you have more translation for translations for this uiLabel file we can reopen it. Add german translation to AccountingErrorUiLabels.xml - Key: OFBIZ-4713 URL: https://issues.apache.org/jira/browse/OFBIZ-4713 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Markus M. May Assignee: Sascha Rodekamp Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-4713-add-german-translation-to-AccountingErrorUiLabels.patch The German translation is missing in AccountingErrorUiLabels.xml . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Proposal to close the 4.0 and 09.04 release branches
Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
[jira] [Created] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposal to close the 4.0 and 09.04 release branches
I'm all for it +1 Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: Proposal to close the 4.0 and 09.04 release branches
+1 Hans On 02/23/2012 03:35 PM, Jacopo Cappellato wrote: Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: [VOTE] [RELEASE] Apache OFBiz 09.04.02
+1 Pierre Smits 2012/2/23 Jacques Le Roux jacques.le.r...@les7arts.com +1 Jacques From: Jacopo Cappellato jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com This is the vote thread to release a new (bug fix) release for the 09.04 branch. This new release, Apache OFBiz 09.04.02 (major release number: 09.04; minor release number: 02), will supersede the release Apache OFBiz 09.04.01. The release files can be downloaded from here: http://people.apache.org/~**jacopoc/dist/http://people.apache.org/~jacopoc/dist/ and are: * apache-ofbiz-09.04.02.zip: the release package, based on the 09.04 branch at revision 1291780 (latest as of now) * KEYS: text file with keys * apache-ofbiz-09.04.02.zip.asc: the detached signature file * apache-ofbiz-09.04.02.zip.md5, apache-ofbiz-09.04.02.zip.sha: hashes Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/** verification.html http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 09.04.02 [ -1] do not release This vote will be closed in 72 hours. For more details about this process please read http://www.apache.org/** foundation/voting.html http://www.apache.org/foundation/voting.html The following text is quoted from the above url: Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. Kind Regards, Jacopo
Re: Proposal to close the 4.0 and 09.04 release branches
+1 Pierre Smits 2012/2/23 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: Proposal about a time based release plan
Hi All, I am all for a roadmap. This will help us in communications with existing and potential customers. It will also help us with planning of internal activities related to the OFBiz product. +1 Pierre Smits 2012/2/21 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi all, I would like to share some ideas I have to make our release plan more clearer, public and well defined. This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful. This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates. For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this: * release 11.04 around 2012-04-15 * release 11.04.01 around 2012-08-15 * release 11.04.02 around 2012-12-15 * release 10.04.01 around 2012-03-15 * release 10.04.02 around 2012-07-15 * release 10.04.03 around 2012-11-15 * release 09.04.02 around 2012-02-15 * release 09.04.03 around 2012-06-15 * release 09.04.04 around 2012-10-15 Or we could decide on a less aggressive schedule and release each branch every 6 months etc... And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen it). In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on this information could prepare in time for the upgrades (or switch between major releases). Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could skip a release if no changes since the previous one were committed etc... When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement and effort... we can (and should) always try to do that also but this is another topic (for another thread). In the meantime, with this time based release plan we will have something real to play with. Please let me know what you think. Thanks, Jacopo
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214495#comment-13214495 ] Pierre Smits commented on OFBIZ-4715: - The location and composition of the postal code is dependent on national definition. For instance, some countries have the country code before the postal code before the name of the city. Others have country code and postal code on a new line below the name of the city. See http://en.wikipedia.org/wiki/Postal_code In stead of removal, I suggest to look a bit deeper in all the variations and devise a solution that facilitates all. Regards, Pierre Smits Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4715: - Attachment: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch Determine the country with the locale, remove stateProvinceGeoId if country is not equal US in Contact.ftl Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposal to close the 4.0 and 09.04 release branches
like it!! Regards, Kiran Gawde Senior Software Architect Object Edge Inc (925) 943 5558 x108 There are two kind of people: Those who do the work and those who take the credit. Try to be in the first group because there is less competition there. Never give up on what you really want to do. The person with big dreams is more powerful than one with all the facts. From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com To: dev@ofbiz.apache.org Date: 02/23/2012 12:35 AM Subject:Proposal to close the 4.0 and 09.04 release branches Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: Proposal to close the 4.0 and 09.04 release branches
+1 Regards, Ankit Jain On Thu, Feb 23, 2012 at 2:05 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: Proposal about a time based release plan
it's a clear vision for end user :) +1 Nicolas Le 21/02/2012 10:18, Jacopo Cappellato a écrit : Hi all, I would like to share some ideas I have to make our release plan more clearer, public and well defined. This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful. This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates. For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this: * release 11.04 around 2012-04-15 * release 11.04.01 around 2012-08-15 * release 11.04.02 around 2012-12-15 * release 10.04.01 around 2012-03-15 * release 10.04.02 around 2012-07-15 * release 10.04.03 around 2012-11-15 * release 09.04.02 around 2012-02-15 * release 09.04.03 around 2012-06-15 * release 09.04.04 around 2012-10-15 Or we could decide on a less aggressive schedule and release each branch every 6 months etc... And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen it). In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on this information could prepare in time for the upgrades (or switch between major releases). Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could skip a release if no changes since the previous one were committed etc... When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement and effort... we can (and should) always try to do that also but this is another topic (for another thread). In the meantime, with this time based release plan we will have something real to play with. Please let me know what you think. Thanks, Jacopo
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214506#comment-13214506 ] Sascha Rodekamp commented on OFBIZ-4709: Yes Jacopo, we should definitely the existing tables. I'm a little bit afraid, that to much content information will be stored in the database tables. But i see no way handling content without a connection to the DB so it's ok to use the content entities to manage it, if we have a DB lookup anyway we can use the from/thruDate filter. Anyway another point which comes to my mind. Would you disable the current product content storage? Or should we use the current entity based storage and the repository storage parallel? I think of saying the *ContentWorker which storage point he have to use (entity or repository). Means if someone want to use the DB, he can configure to use a ProductEntityContentWorker if he otherwise want to use the repository he can configure the ProductRepositoryContentWorker. The content Worker encapsulate all the access to the content store point. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposal to close the 4.0 and 09.04 release branches
+1 Good idea. That will simplify a few things! Regards Am 23.02.2012 um 09:35 schrieb Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com: Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: Proposal to close the 4.0 and 09.04 release branches
+1 Thanks Regards -- Deepak Dixit On Feb 23, 2012, at 3:13 PM, Sascha Rodekamp wrote: +1 Good idea. That will simplify a few things! Regards Am 23.02.2012 um 09:35 schrieb Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com: Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214514#comment-13214514 ] Pierre Smits commented on OFBIZ-4709: - Perhaps it is a good idea to include end-of-life for current content storage somewhere in the roadmap, if the jcr approach proves to be more flexible and easier to use. This will help with communications and planning of phasing-out activities. Regards, Pierre Smits Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214522#comment-13214522 ] Markus M. May commented on OFBIZ-4715: -- These are a lot of different ways on how to do this. How should this be implemented in a common way. I am thinking about a configuration via an XML-Locale file. This is on the other hand a misuse of locales, since I would retrieve the locale via the country code and not from the user locale. What do you think? Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214529#comment-13214529 ] Jacopo Cappellato commented on OFBIZ-4709: -- Sascha, I was thinking that, if for example we add a new contentTypeId of JCR_CONTENT (or similar), then all Content records with that type will use the external JCR repository, while the old Content records will still use the OFBiz DB; in this way the two mechanisms will fit together nicely. This is the general idea... as regards *ContentWorker specific implementation I don't know... some of the classes are rather old and not perfect but if it makes sense we could extend them to check the contentTypeId and use JCR if the type is JCR_CONTENT. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214540#comment-13214540 ] Jose F. Fernandez commented on OFBIZ-4715: -- I think that the address template must be personalized by locales, but not by user locale or country, because is a user from Spain (for example, me) send an invoice to a USA costumer, the address must be formatted according to the USA locale. So it must be by the address locale. I'm thinking right? Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[
https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214541#comment-13214541
]
Jacopo Cappellato commented on OFBIZ-4715:
--
Maybe a better way is to create a simple dynamic mechanism to lookup, based on
the postalAddress.countryGeoId, if there is a country specific ftl; if not use
the default one.
Steps to implement this feature could be:
* extract from Contact.ftl the existing code that formats the postal address
into a separate PostalAddress.ftl (or similar) template;
* in Contact.ftl, where the postal address needs to be rendered, get the
postalAddress.countryGeoId and try to locate a template with file name:
PostalAddress_${postalAddress.countryGeoId}.ftl (e.g. PostalAddress_USA.ftl or
PostalAddress_FRA.ftl); if not found then default to PostalAddress.ftl
* the same mechanism could be reused for invoices etc...
* it would be nice (but maybe not too easy) to try to implement all the
PostalAddress_*.ftl templates in a way that will let them to be reused in
various screens, possibly using the @htmlTemplate/ tags, with minimal to no
formatting/styling; but it would be also nice to be able to reuse them for PDF
rendering (form widgets?)
Just my 2 cents
Invoice PDF and Contact Information show Region Code instead of Country Code
before the Zip Code
Key: OFBIZ-4715
URL: https://issues.apache.org/jira/browse/OFBIZ-4715
Project: OFBiz
Issue Type: Bug
Components: party, specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Markus M. May
Priority: Minor
Fix For: SVN trunk
Attachments:
OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch
The Invoice PDF and the Contact Information in the Party application show the
Region Code instead of the Country Code before the Zip Code. This will be
fine for the US, here in Germany it is rather unusual.
I propose to avoid this by removing the Region Code if the country is
different then US.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[
https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214564#comment-13214564
]
Sascha Rodekamp commented on OFBIZ-4709:
Yap we need a separate content type: I would suggest JCR_CONTENT_* to
differentiate between images, text, html and so on.
{quote}
*ContentWorker ... some of the classes are rather old and not perfect
{quote}
Right, but i don't like the idea to extend tho old code, because i think we can
do much better.
Leave the old class as it is and let us use a factory which decided which
implementation for the specific content should be used (maybe depending on the
content type). That gives us the ability to:
1.) create new clean code (and test drive it :))
2.) make the DB and repository code independent (at some point in the feature
we can simply remove one implementation)
3.) we haven't to worry to break anything from the exciting code
|---can load--- *EntityContentWorker (implements
ContentWorker)
*ContentWorkerFactory |
|---can load--- *RepositoryContentWorker (implements
ContentWorker)
Support jcr-stored file content within Applications
---
Key: OFBIZ-4709
URL: https://issues.apache.org/jira/browse/OFBIZ-4709
Project: OFBiz
Issue Type: Sub-task
Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Anne Jessel
Assignee: Sascha Rodekamp
My current requirements:
* store uploaded documents (pdf and scans), mainly for legal compliance
reasons
* old document versions should be accessible
* documents should be associated with existing entities. So far I've
identified a need to associate with Product, Party, OrderHeader,
ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not
be surprised if we discover more as this project proceeds.
* documents may have a type and a purpose, though sometimes I'm not sure of
the difference. For example, type: drivers_licence might be purpose:
identification, and/or purpose: permission_to_drive, while type:
shipping_label would be purpose: shipping_label
* many documents have an expiry date (e.g. drivers licence)
* a document may become invalid before its expiry date (e.g. because the law
changed)
* a specific version of a document may need to be associated with an entity.
For example, a licence agreement document accessed via a Product should
always be the latest version. However the version of that document actually
shipped with the product should be associated with the ShipmentItem.
* a single document might be associated with more than one entity type: see
the example in the previous point
Not all documents require all of the above. For example, there are some
documents where we don't need to track which version was used when, and some
without expiry dates.
I'm thinking of using the from/thruDate pattern to handle expiry related
needs. I'd like to put as much information into the jcr path as possible, so
less needs to go into entities, as per Sascha's suggestion on the dev ML.
However (at least) from/thruDate and which version of a document was actually
used where will presumably need to be stored in an entity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OFBIZ-4709) Support jcr-stored file content within Applications
[
https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214564#comment-13214564
]
Sascha Rodekamp edited comment on OFBIZ-4709 at 2/23/12 11:48 AM:
--
Yap we need a separate content type: I would suggest JCR_CONTENT_* to
differentiate between images, text, html and so on.
{quote}
*ContentWorker ... some of the classes are rather old and not perfect
{quote}
Right, but i don't like the idea to extend tho old code, because i think we can
do much better.
Leave the old class as it is and let us use a factory which decided which
implementation for the specific content should be used (maybe depending on the
content type). That gives us the ability to:
1.) create new clean code (and test drive it :))
2.) make the DB and repository code independent (at some point in the feature
we can simply remove one implementation)
3.) we haven't to worry to break anything from the exciting code
||--- can load --- *EntityContentWorker
(implements ContentWorker)
|*ContentWorkerFactory |
||--- can load --- *RepositoryContentWorker
(implements ContentWorker)
was (Author: sascha):
Yap we need a separate content type: I would suggest JCR_CONTENT_* to
differentiate between images, text, html and so on.
{quote}
*ContentWorker ... some of the classes are rather old and not perfect
{quote}
Right, but i don't like the idea to extend tho old code, because i think we can
do much better.
Leave the old class as it is and let us use a factory which decided which
implementation for the specific content should be used (maybe depending on the
content type). That gives us the ability to:
1.) create new clean code (and test drive it :))
2.) make the DB and repository code independent (at some point in the feature
we can simply remove one implementation)
3.) we haven't to worry to break anything from the exciting code
|---can load--- *EntityContentWorker (implements
ContentWorker)
*ContentWorkerFactory |
|---can load--- *RepositoryContentWorker (implements
ContentWorker)
Support jcr-stored file content within Applications
---
Key: OFBIZ-4709
URL: https://issues.apache.org/jira/browse/OFBIZ-4709
Project: OFBiz
Issue Type: Sub-task
Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Anne Jessel
Assignee: Sascha Rodekamp
My current requirements:
* store uploaded documents (pdf and scans), mainly for legal compliance
reasons
* old document versions should be accessible
* documents should be associated with existing entities. So far I've
identified a need to associate with Product, Party, OrderHeader,
ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not
be surprised if we discover more as this project proceeds.
* documents may have a type and a purpose, though sometimes I'm not sure of
the difference. For example, type: drivers_licence might be purpose:
identification, and/or purpose: permission_to_drive, while type:
shipping_label would be purpose: shipping_label
* many documents have an expiry date (e.g. drivers licence)
* a document may become invalid before its expiry date (e.g. because the law
changed)
* a specific version of a document may need to be associated with an entity.
For example, a licence agreement document accessed via a Product should
always be the latest version. However the version of that document actually
shipped with the product should be associated with the ShipmentItem.
* a single document might be associated with more than one entity type: see
the example in the previous point
Not all documents require all of the above. For example, there are some
documents where we don't need to track which version was used when, and some
without expiry dates.
I'm thinking of using the from/thruDate pattern to handle expiry related
needs. I'd like to put as much information into the jcr path as possible, so
less needs to go into entities, as per Sascha's suggestion on the dev ML.
However (at least) from/thruDate and which version of a document was actually
used where will presumably need to be stored in an entity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214573#comment-13214573 ] Markus M. May commented on OFBIZ-4715: -- Jacopo: This solution is interesting. The only problem I do see is that we do need a new database entity (PostalAddressFTL) which references the CountryCode and also the ftl for this (e.g. PostalAddress_USA.ftl). Furthermore if an FTL does not exist for a countryCode we need a default ftl (PostalAddress.ftl). Then this data needs to get retrieved from the DB (which is quite easy), and the seed data needs to get extended for each FTL. Sounds like a lot of effort and also a lot of things, which could be forgotten or could go wrong. WDYT? Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214654#comment-13214654 ] Anil K Patel commented on OFBIZ-4715: - Ofbiz is designed to be customized. Templates used for rendering data are some of the objects in Ofbiz that gets customized the most. Keeping these two things in mind, its better to not try to make templates do to much. Instead if they are simple, users (in this case developers implementing ofbiz) will be able to understand the code much easy and might customize them to fit their project needs. My two cents :) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214664#comment-13214664 ] Jacopo Cappellato commented on OFBIZ-4709: -- Yes, it is fine to me, it will maybe require to change more code initially (all the code that is currently using *ContentWorker or *ContentWrappers methods) but it may be a nice refactoring. At the end, the important thing imo is to continue to use the Content and PartyContent/ProductContent... entities following a similar pattern: the actual implementation of util methods/wrappers can take several similar shapes. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214669#comment-13214669 ] Jacopo Cappellato commented on OFBIZ-4715: -- Markus, I was not suggesting to add new entities but simply to adopt the naming convention I explained above: nothing more or less than this; all the country variant templates could stay in the same folder and the system could easily try to locate them in the filesystem without the need to lookup custom entities. And adding a custom template would be a matter of copying it in that folder with the proper naming convention. I hope it clarifies what I was suggesting. Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214779#comment-13214779 ] Joe Eckard commented on OFBIZ-4715: --- I agree with the general idea (see [this dev list message from 2008|http://mail-archives.apache.org/mod_mbox/ofbiz-dev/200811.mbox/%3ce1b0d743-b98e-4d7e-a843-a9dddcd5b...@redrocketcorp.com%3e]), but something else to consider is that you will most like want different templates for HTML XSL:FO. Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214779#comment-13214779 ] Joe Eckard edited comment on OFBIZ-4715 at 2/23/12 2:50 PM: I agree with the general idea (see [this dev list message from 2008|http://mail-archives.apache.org/mod_mbox/ofbiz-dev/200811.mbox/%3ce1b0d743-b98e-4d7e-a843-a9dddcd5b...@redrocketcorp.com%3e]), but something else to consider is that you will most like want different templates for HTML display, HTML form input XSL:FO. was (Author: eckardjf): I agree with the general idea (see [this dev list message from 2008|http://mail-archives.apache.org/mod_mbox/ofbiz-dev/200811.mbox/%3ce1b0d743-b98e-4d7e-a843-a9dddcd5b...@redrocketcorp.com%3e]), but something else to consider is that you will most like want different templates for HTML XSL:FO. Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214786#comment-13214786 ] Jacopo Cappellato commented on OFBIZ-4715: -- Yeah, I agree... we may simply use the same lookup mechanism for XSL-FO but search for files with the fo.ftl suffix. Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214884#comment-13214884 ] Markus M. May commented on OFBIZ-4715: -- I am currently a little lost in this task. Guess I will push it back a little ;-( Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[
https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214884#comment-13214884
]
Markus M. May edited comment on OFBIZ-4715 at 2/23/12 5:55 PM:
---
I am currently a little lost in this task.
My current setup is as follows:
1) A groovy component to determine the countryCode and with this determines the
ftl-name and if it is available, if not, it will return the usual
PostalAddress.ftl
2) new PostalAddressScreen, which calls the above mentioned groovy component
and calls the html-template PostalAddress* from the groovy script from the
context
3) Adopt the Contact.ftl to call the new screen with the postalAddress in the
context, so that I do have access to this in the screen
#assign postalAddress = contactMechMap.postalAddress
${setRequestAttribute(postalAddress, postalAddress)}
${screens.render(component://party/widget/partymgr/PostalAddressScreens.xml#postalAddress)}
4) new PostalAddress.ftl, which can have several instances
(PostalAddress_DE.ftl, PostalAddress_USA.ftl, ...)
Am I walking in the right direction?
was (Author: m...@apache.org):
I am currently a little lost in this task. Guess I will push it back a
little ;-(
Invoice PDF and Contact Information show Region Code instead of Country Code
before the Zip Code
Key: OFBIZ-4715
URL: https://issues.apache.org/jira/browse/OFBIZ-4715
Project: OFBiz
Issue Type: Bug
Components: party, specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Markus M. May
Priority: Minor
Fix For: SVN trunk
Attachments:
OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch
The Invoice PDF and the Contact Information in the Party application show the
Region Code instead of the Country Code before the Zip Code. This will be
fine for the US, here in Germany it is rather unusual.
I propose to avoid this by removing the Region Code if the country is
different then US.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Service alert: ofbiz-vm.apache.org/HTTP - Ofbiz Demo Trunk is CRITICAL
Again a Derby crash. It was hight time to kill the process, we had already 24 GB of console.log Jacques From: nag...@monitoring.apache.org *** ASF Nagios *** Notification Type: PROBLEM Host: ofbiz-vm.apache.org Address: 140.211.11.41 Service: HTTP - Ofbiz Demo Trunk State: CRITICAL Info: HTTP CRITICAL: HTTP/1.1 500 Internal Server Error Date/Time: Thu Feb 23 14:34:19 UTC 2012
Re: Service alert: ofbiz-vm.apache.org/HTTP - Ofbiz Demo Stable is CRITICAL
I guess we got some disk issues(?), no time to dig... simply restarted Jacques From: nag...@monitoring.apache.org *** ASF Nagios *** Notification Type: PROBLEM Host: ofbiz-vm.apache.org Address: 140.211.11.41 Service: HTTP - Ofbiz Demo Stable State: CRITICAL Info: HTTP CRITICAL: HTTP/1.1 500 Internal Server Error Date/Time: Thu Feb 23 17:10:59 UTC 2012
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215192#comment-13215192 ] Anne Jessel commented on OFBIZ-4709: Thanks everyone for the comments. I like the direction this is heading. I think the treatment of contentTypeId needs more work. Currently this has values such as ANNOTATION, DECORATOR, TOPIC. Adding JCR_CONTENT_ANNOTATION and similar would make it difficult to find all the ANNOTATION content. Perhaps we should add an extra field to Content, called storageTypeId? It could have two possible values (at this stage) ENTITY or JCR, with default being ENTITY for backwards compatability. Also, Content entity doesn't currently have from/thruDate fields. I'll need to add those. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215450#comment-13215450 ] Jacopo Cappellato commented on OFBIZ-4709: -- Another option (but please consider that I am not looking at the details and I am simply providing some ideas) can be that of keeping the Content entity (and its data) as it is currently and then we define a new dataResourceTypeId (for JCR): Content (ANNOTATION, DECORATOR, etc...) -- DataResource (OFBIZ_FILE...) -- old content Content (ANNOTATION, DECORATOR, etc...) -- DataResource (JCR) -- JCR (new content) Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4715: - Attachment: OFBIZ-4715-initial-commit.patch Initial commit, I still receive errors that the parameter PostalAddress is empty. Any help on this one? Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch, OFBIZ-4715-initial-commit.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4715) Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code
[ https://issues.apache.org/jira/browse/OFBIZ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4715: - Attachment: OFBIZ-4715-initial-commit.patch Upload with all git related stuff removed. Invoice PDF and Contact Information show Region Code instead of Country Code before the Zip Code Key: OFBIZ-4715 URL: https://issues.apache.org/jira/browse/OFBIZ-4715 Project: OFBiz Issue Type: Bug Components: party, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4715-add-locale-for-country-and-remove-countryGeo-if-not-us.patch, OFBIZ-4715-initial-commit.patch, OFBIZ-4715-initial-commit.patch The Invoice PDF and the Contact Information in the Party application show the Region Code instead of the Country Code before the Zip Code. This will be fine for the US, here in Germany it is rather unusual. I propose to avoid this by removing the Region Code if the country is different then US. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
