[jira] [Commented] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840568#comment-16840568
]
Jacques Le Roux commented on OFBIZ-10187:
-
I reopened OFBIZ-5254 and will handle it there.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, 16.11.04, Release Branch 17.12, Release Branch
> 18.12
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Critical
> Labels: backport-needed
> Fix For: 17.12.01, 16.11.06, 18.12.01
>
> Attachments:
> OFBIZ-10187_Rewrite-CustomPermissivePolicy-matchesEithe.patch,
> OFBIZ-10187_Sanitizer.patch, OFBIZ-10187_Sanitizer_16.11.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-5254) Services allow arbitrary HTML for parameters with allow-html set to "safe"
[
https://issues.apache.org/jira/browse/OFBIZ-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840561#comment-16840561
]
Jacques Le Roux commented on OFBIZ-5254:
BTW I have not tested anything yet :) But I trust it should work, at least for
testing...
> Services allow arbitrary HTML for parameters with allow-html set to "safe"
> --
>
> Key: OFBIZ-5254
> URL: https://issues.apache.org/jira/browse/OFBIZ-5254
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Christoph Neuroth
>Assignee: Jacques Le Roux
>Priority: Major
> Labels: security
> Attachments: OFBIZ-5254.patch
>
>
> For any given service with allow-html=safe parameters, the parameter data is
> not properly validated. See Model.Service.java:588:
> {code}
>
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> {code}
> Looking at that method:
> {code}
> public static String checkStringForHtmlSafeOnly(String valueName, String
> value, List errorMessageList) {
> ValidationErrorList vel = new ValidationErrorList();
> value = defaultWebValidator.getValidSafeHTML(valueName, value,
> Integer.MAX_VALUE, true, vel);
> errorMessageList.addAll(UtilGenerics.checkList(vel.errors(),
> String.class));
> return value;
> }
> {code}
> you can see that it expects the defaultWebValidator.getValidSafeHTML would
> add all validation errors to the given ValidationErrorList, but if you look
> at the implementation of ESAPI that is not the case. First, consider the
> overloaded getValidSafeHTML that takes the ValidationErrorList:
> {code}public String getValidSafeHTML(String context, String input,
> int maxLength, boolean allowNull, ValidationErrorList errors) throws
> IntrusionException {
> try {
> return getValidSafeHTML(context, input, maxLength,
> allowNull);
> } catch (ValidationException e) {
> errors.addError(context, e);
> }
> return input;
> }
> {code}
> Then, step into that method to see that ValidationExceptions are only thrown
> for things like exceeding the maximum length - not for policy violations that
> can be "cleaned", such as tags that are not allowed by the policy:
> {code}
> AntiSamy as = new AntiSamy();
> CleanResults test = as.scan(input, antiSamyPolicy);
> List errors = test.getErrorMessages();
> if ( errors.size() > 0 ) {
> // just create new exception to get it logged
> and intrusion detected
> new ValidationException( "Invalid HTML input:
> context=" + context, "Invalid HTML input: context=" + context + ", errors=" +
> errors, context );
> }
> {code}
> I guess that is an expected, although maybe not clearly documented behavior
> of ESAPI: Non-cleanable violations throw the exception and therefore will
> fail the ofbiz service, while non-allowed tags are cleaned. However, if you
> consider ModelService:588 and following lines again:
> {code}
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> //(...)
> if (errorMessageList.size() > 0) {
> throw new ServiceValidationException(errorMessageList, this,
> mode);
> }
> {code}
> the cleaned return value is ignored. Therefore, you will see an
> "IntrusionDetection" in the logs, giving you a false sense of security but
> the unfiltered HTML will still go into the service. So, if you want the
> service to fail if non-allowed HTML is encountered, you should use
> isValidSafeHTML instead. If you want the incoming HTML to be filtered, you
> should use the return value of getValidSafeHTML.
> Some additional notes on this:
> * When changing this, it should be properly documented as users may well be
> relying on this behavior - for example, we send full HTML mails to our
> customers for their ecommerce purchases and require HTML to go through - so
> maybe for services like the communicationEvents allowing only safe HTML might
> not be desired.
> * The ESAPI code samples above are from version 1.4.4. I was really surprised
> to find a JAR that is not only outdated, but patched and built by a third
> party, without even indicating that in the filename in OfBiz trunk. This has
> been there for years (see OFBIZ-3135) and should really be replaced with an
> official, up to date version since that issue was fixed upstream years ago.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-5254) Services allow arbitrary HTML for parameters with allow-html set to "safe"
[
https://issues.apache.org/jira/browse/OFBIZ-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840554#comment-16840554
]
Jacques Le Roux commented on OFBIZ-5254:
With [^OFBIZ-5254.patch] I propose a solution to use allow-html=safe again.
It's a WIP so bear with me. I'd appreciate reviews and tests of course.
I have already noticed about
# in persistDataResourceAndData allow-html="none"
# I need to change "which will follow the rules in the antisamy-esapi.xml file"
in services.xsd
> Services allow arbitrary HTML for parameters with allow-html set to "safe"
> --
>
> Key: OFBIZ-5254
> URL: https://issues.apache.org/jira/browse/OFBIZ-5254
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Christoph Neuroth
>Assignee: Jacques Le Roux
>Priority: Major
> Labels: security
> Attachments: OFBIZ-5254.patch
>
>
> For any given service with allow-html=safe parameters, the parameter data is
> not properly validated. See Model.Service.java:588:
> {code}
>
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> {code}
> Looking at that method:
> {code}
> public static String checkStringForHtmlSafeOnly(String valueName, String
> value, List errorMessageList) {
> ValidationErrorList vel = new ValidationErrorList();
> value = defaultWebValidator.getValidSafeHTML(valueName, value,
> Integer.MAX_VALUE, true, vel);
> errorMessageList.addAll(UtilGenerics.checkList(vel.errors(),
> String.class));
> return value;
> }
> {code}
> you can see that it expects the defaultWebValidator.getValidSafeHTML would
> add all validation errors to the given ValidationErrorList, but if you look
> at the implementation of ESAPI that is not the case. First, consider the
> overloaded getValidSafeHTML that takes the ValidationErrorList:
> {code}public String getValidSafeHTML(String context, String input,
> int maxLength, boolean allowNull, ValidationErrorList errors) throws
> IntrusionException {
> try {
> return getValidSafeHTML(context, input, maxLength,
> allowNull);
> } catch (ValidationException e) {
> errors.addError(context, e);
> }
> return input;
> }
> {code}
> Then, step into that method to see that ValidationExceptions are only thrown
> for things like exceeding the maximum length - not for policy violations that
> can be "cleaned", such as tags that are not allowed by the policy:
> {code}
> AntiSamy as = new AntiSamy();
> CleanResults test = as.scan(input, antiSamyPolicy);
> List errors = test.getErrorMessages();
> if ( errors.size() > 0 ) {
> // just create new exception to get it logged
> and intrusion detected
> new ValidationException( "Invalid HTML input:
> context=" + context, "Invalid HTML input: context=" + context + ", errors=" +
> errors, context );
> }
> {code}
> I guess that is an expected, although maybe not clearly documented behavior
> of ESAPI: Non-cleanable violations throw the exception and therefore will
> fail the ofbiz service, while non-allowed tags are cleaned. However, if you
> consider ModelService:588 and following lines again:
> {code}
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> //(...)
> if (errorMessageList.size() > 0) {
> throw new ServiceValidationException(errorMessageList, this,
> mode);
> }
> {code}
> the cleaned return value is ignored. Therefore, you will see an
> "IntrusionDetection" in the logs, giving you a false sense of security but
> the unfiltered HTML will still go into the service. So, if you want the
> service to fail if non-allowed HTML is encountered, you should use
> isValidSafeHTML instead. If you want the incoming HTML to be filtered, you
> should use the return value of getValidSafeHTML.
> Some additional notes on this:
> * When changing this, it should be properly documented as users may well be
> relying on this behavior - for example, we send full HTML mails to our
> customers for their ecommerce purchases and require HTML to go through - so
> maybe for services like the communicationEvents allowing only safe HTML might
> not be desired.
> * The ESAPI code samples above are from version 1.4.4. I was really surprised
> to find a JAR that is not only outdated, but patched and built by a third
> party, without even indicating that in the filename in OfBiz
[jira] [Updated] (OFBIZ-5254) Services allow arbitrary HTML for parameters with allow-html set to "safe"
[
https://issues.apache.org/jira/browse/OFBIZ-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-5254:
---
Attachment: OFBIZ-5254.patch
> Services allow arbitrary HTML for parameters with allow-html set to "safe"
> --
>
> Key: OFBIZ-5254
> URL: https://issues.apache.org/jira/browse/OFBIZ-5254
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Christoph Neuroth
>Assignee: Jacques Le Roux
>Priority: Major
> Labels: security
> Attachments: OFBIZ-5254.patch
>
>
> For any given service with allow-html=safe parameters, the parameter data is
> not properly validated. See Model.Service.java:588:
> {code}
>
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> {code}
> Looking at that method:
> {code}
> public static String checkStringForHtmlSafeOnly(String valueName, String
> value, List errorMessageList) {
> ValidationErrorList vel = new ValidationErrorList();
> value = defaultWebValidator.getValidSafeHTML(valueName, value,
> Integer.MAX_VALUE, true, vel);
> errorMessageList.addAll(UtilGenerics.checkList(vel.errors(),
> String.class));
> return value;
> }
> {code}
> you can see that it expects the defaultWebValidator.getValidSafeHTML would
> add all validation errors to the given ValidationErrorList, but if you look
> at the implementation of ESAPI that is not the case. First, consider the
> overloaded getValidSafeHTML that takes the ValidationErrorList:
> {code}public String getValidSafeHTML(String context, String input,
> int maxLength, boolean allowNull, ValidationErrorList errors) throws
> IntrusionException {
> try {
> return getValidSafeHTML(context, input, maxLength,
> allowNull);
> } catch (ValidationException e) {
> errors.addError(context, e);
> }
> return input;
> }
> {code}
> Then, step into that method to see that ValidationExceptions are only thrown
> for things like exceeding the maximum length - not for policy violations that
> can be "cleaned", such as tags that are not allowed by the policy:
> {code}
> AntiSamy as = new AntiSamy();
> CleanResults test = as.scan(input, antiSamyPolicy);
> List errors = test.getErrorMessages();
> if ( errors.size() > 0 ) {
> // just create new exception to get it logged
> and intrusion detected
> new ValidationException( "Invalid HTML input:
> context=" + context, "Invalid HTML input: context=" + context + ", errors=" +
> errors, context );
> }
> {code}
> I guess that is an expected, although maybe not clearly documented behavior
> of ESAPI: Non-cleanable violations throw the exception and therefore will
> fail the ofbiz service, while non-allowed tags are cleaned. However, if you
> consider ModelService:588 and following lines again:
> {code}
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> //(...)
> if (errorMessageList.size() > 0) {
> throw new ServiceValidationException(errorMessageList, this,
> mode);
> }
> {code}
> the cleaned return value is ignored. Therefore, you will see an
> "IntrusionDetection" in the logs, giving you a false sense of security but
> the unfiltered HTML will still go into the service. So, if you want the
> service to fail if non-allowed HTML is encountered, you should use
> isValidSafeHTML instead. If you want the incoming HTML to be filtered, you
> should use the return value of getValidSafeHTML.
> Some additional notes on this:
> * When changing this, it should be properly documented as users may well be
> relying on this behavior - for example, we send full HTML mails to our
> customers for their ecommerce purchases and require HTML to go through - so
> maybe for services like the communicationEvents allowing only safe HTML might
> not be desired.
> * The ESAPI code samples above are from version 1.4.4. I was really surprised
> to find a JAR that is not only outdated, but patched and built by a third
> party, without even indicating that in the filename in OfBiz trunk. This has
> been there for years (see OFBIZ-3135) and should really be replaced with an
> official, up to date version since that issue was fixed upstream years ago.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (OFBIZ-5254) Services allow arbitrary HTML for parameters with allow-html set to "safe"
[
https://issues.apache.org/jira/browse/OFBIZ-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reopened OFBIZ-5254:
Reopen after discussion at https://markmail.org/message/jnaitmwahjcjmdn5
> Services allow arbitrary HTML for parameters with allow-html set to "safe"
> --
>
> Key: OFBIZ-5254
> URL: https://issues.apache.org/jira/browse/OFBIZ-5254
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Christoph Neuroth
>Assignee: Jacques Le Roux
>Priority: Major
> Labels: security
>
> For any given service with allow-html=safe parameters, the parameter data is
> not properly validated. See Model.Service.java:588:
> {code}
>
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> {code}
> Looking at that method:
> {code}
> public static String checkStringForHtmlSafeOnly(String valueName, String
> value, List errorMessageList) {
> ValidationErrorList vel = new ValidationErrorList();
> value = defaultWebValidator.getValidSafeHTML(valueName, value,
> Integer.MAX_VALUE, true, vel);
> errorMessageList.addAll(UtilGenerics.checkList(vel.errors(),
> String.class));
> return value;
> }
> {code}
> you can see that it expects the defaultWebValidator.getValidSafeHTML would
> add all validation errors to the given ValidationErrorList, but if you look
> at the implementation of ESAPI that is not the case. First, consider the
> overloaded getValidSafeHTML that takes the ValidationErrorList:
> {code}public String getValidSafeHTML(String context, String input,
> int maxLength, boolean allowNull, ValidationErrorList errors) throws
> IntrusionException {
> try {
> return getValidSafeHTML(context, input, maxLength,
> allowNull);
> } catch (ValidationException e) {
> errors.addError(context, e);
> }
> return input;
> }
> {code}
> Then, step into that method to see that ValidationExceptions are only thrown
> for things like exceeding the maximum length - not for policy violations that
> can be "cleaned", such as tags that are not allowed by the policy:
> {code}
> AntiSamy as = new AntiSamy();
> CleanResults test = as.scan(input, antiSamyPolicy);
> List errors = test.getErrorMessages();
> if ( errors.size() > 0 ) {
> // just create new exception to get it logged
> and intrusion detected
> new ValidationException( "Invalid HTML input:
> context=" + context, "Invalid HTML input: context=" + context + ", errors=" +
> errors, context );
> }
> {code}
> I guess that is an expected, although maybe not clearly documented behavior
> of ESAPI: Non-cleanable violations throw the exception and therefore will
> fail the ofbiz service, while non-allowed tags are cleaned. However, if you
> consider ModelService:588 and following lines again:
> {code}
> StringUtil.checkStringForHtmlSafeOnly(modelParam.name, value,
> errorMessageList);
> //(...)
> if (errorMessageList.size() > 0) {
> throw new ServiceValidationException(errorMessageList, this,
> mode);
> }
> {code}
> the cleaned return value is ignored. Therefore, you will see an
> "IntrusionDetection" in the logs, giving you a false sense of security but
> the unfiltered HTML will still go into the service. So, if you want the
> service to fail if non-allowed HTML is encountered, you should use
> isValidSafeHTML instead. If you want the incoming HTML to be filtered, you
> should use the return value of getValidSafeHTML.
> Some additional notes on this:
> * When changing this, it should be properly documented as users may well be
> relying on this behavior - for example, we send full HTML mails to our
> customers for their ecommerce purchases and require HTML to go through - so
> maybe for services like the communicationEvents allowing only safe HTML might
> not be desired.
> * The ESAPI code samples above are from version 1.4.4. I was really surprised
> to find a JAR that is not only outdated, but patched and built by a third
> party, without even indicating that in the filename in OfBiz trunk. This has
> been there for years (see OFBIZ-3135) and should really be replaced with an
> official, up to date version since that issue was fixed upstream years ago.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-11001) Applicable Promo Recommendations
[ https://issues.apache.org/jira/browse/OFBIZ-11001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840446#comment-16840446 ] Jacques Le Roux commented on OFBIZ-11001: - Hi Rishi, >From your description (did not look into code myself) this seems sound to me. > Applicable Promo Recommendations > > > Key: OFBIZ-11001 > URL: https://issues.apache.org/jira/browse/OFBIZ-11001 > Project: OFBiz > Issue Type: New Feature > Components: ecommerce, product >Affects Versions: Trunk >Reporter: Rishi Solanki >Priority: Major > > Proposal is to add user selection ability for promotion. That means user can > select her own choice of promotion from the list of promotion applicable to > current cart. Right now promotion engine based on algorithm implemented > decide which promotion will be apply to cart from the list of promotion. For > example, if promotion engine find 3 promotion applicable for the current cart > then based on algorithm implemented it apply the maximum amount value > promotion to the cart. > > Coming back to proposal with some use cases; > > Use Case 1: Promotion engine find three promotions applicable to cart or > item as P1, P2 and P3. And as per algorithm promo engine decide to apply P1. > Now if user want to go with P2 or P3 then she can do that. > > Use Case 2: In #1 user can also choose to not take any promotion, remove the > P1 and submit the order without promotion. > > Use Case 3: Item1 and item2 will have two promotions common as P1 and P2. > Now user can opt which promotion should applicable to which item. That means > user can apply P1 or P2 on item1 or item2 based on her preference. > > Use Case 4: In #3 if user wants then she can opt to select promotion for one > item and can remove promo from other. > [Reference > Thread|https://ofbiz.markmail.org/search/?q=Applicable%20Promo%20Recommendations#query:Applicable%20Promo%20Recommendations+page:1+mid:qvc5zimtu7txbiiy+state:results] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11021) The drop-ship process behaves incorrectly when a combination of drop-ship and non-drop-ship products are added into the cart
[ https://issues.apache.org/jira/browse/OFBIZ-11021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840423#comment-16840423 ] Jacques Le Roux commented on OFBIZ-11021: - +1 sounds good to me. Thanks Pawan, well spotted and fixed, but would be easier for reviewers if you explained in a sentence or two what you did in your patch in functional terms ;) > The drop-ship process behaves incorrectly when a combination of drop-ship and > non-drop-ship products are added into the cart > > > Key: OFBIZ-11021 > URL: https://issues.apache.org/jira/browse/OFBIZ-11021 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 18.12 >Reporter: Pawan Verma >Assignee: Suraj Khurana >Priority: Major > Attachments: OFBIZ-11021.patch > > > The drop-ship process behaves incorrectly when a combination of drop-ship and > non-drop-ship products are added into the cart. > > Suppose we have two items in the cart: > # The first item is drop-shippable. > # The second item is not drop-shippable. > For the first item, the implementation works fine. > For the second item, this is not working correctly. > > For drop shipment process, cart method 'createDropShipGroups' decides > RequirementMethodEnumId in the order of property set at ProductStore -> > ProductFacility -> Product which work fine in case of all drop-ship products > and if the drop-ship product(s) is added last in the cart. > > The issue I found is that if a combination of a dropship and non-drop ship > products are added into the cart and the non-drop shippable product(s) is > added after the drop shippable product(s) then the non-drop-shippable > products also considered as drop-shippable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11026) HR Doc drive by process
[ https://issues.apache.org/jira/browse/OFBIZ-11026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840368#comment-16840368 ] Jacques Le Roux commented on OFBIZ-11026: - Hi Olivier, I had a quick look trying to use a HTML page comparaison but was inneficient. I will have to apply the patches and compare locally the adoc files I guess. While comparing only the TOC on left pages between your 2 links it looks good to me with more information. I did not look into details yet but I spotted that you miss a number for "Core Business Applications" (should be 4). > HR Doc drive by process > --- > > Key: OFBIZ-11026 > URL: https://issues.apache.org/jira/browse/OFBIZ-11026 > Project: OFBiz > Issue Type: Sub-task > Components: humanres >Affects Versions: Trunk >Reporter: Olivier Heintz >Priority: Major > Labels: Documentation, humanres > Attachments: OFBIZ-11026_hr-intro.adoc.patch, > OFBIZ-11026_humanres.adoc.patch > > > Currently HR doc main chapters are on core HR object, I propose to group them > in a chapter and having a chapter by process in the same level bot group in > the HR Process. > Each process is described via a scenario explained like a tutorial, and each > time a core object is used, a link is done to its chapter. > To help review : doc with these modifications are available at > [https://ofbizadoc.ofbizextra.org/html5/user-manual.html#_human_resources] > and Apache OFBiz standard (without modifications) is available too at > https://ofbizadoc.ofbizextra.org/html5/user-manual-std.html#_human_resources > current HR TOC > -- > 3.2. Human Resources > 3.2.1. About Human Resources > 3.2.2. Human Resources Processes > 3.2.3. Employee Positions > 3.2.4. Employees > 3.2.5. Employments > 3.2.6. Performance Review > 3.2.7. Qualifications > 3.2.8. Recruitment > 3.2.9. Skills > 3.2.10. Resumes > 3.2.11. Training > 3.2.12. Leave > 3.2.13. Security > 3.2.14. Global HR Settings > 3.2.15. Glossary > Proposed HR TOC > > 4. Human Resources > 4.1. About this documentation > 4.2. About Human Resources > 4.3. HR Processes > 4.3.1. Organization, Job Position and Definition > 4.3.2. Recruitment, Candidate Selection and Hiring > 4.3.3. Employee Training and Development > 4.3.4. Performance Management and Employee Evaluation > 4.3.5. Employee Salary and Benefits Administration > 4.4. HR core object > 4.4.1. Employee Positions > 4.4.2. Employees > 4.4.3. Employments > 4.4.4. Performance Review > 4.4.5. Qualifications > 4.4.6. Recruitment > 4.4.7. Skills > 4.4.8. Resumes > 4.4.9. Training > 4.4.10. Leave > 4.4.11. Security > 4.5. Global HR Settings > 4.5.1. Skills Types > 4.6. HR Data model > 4.6.1. Employee Position > 4.6.2. Employment > 4.6.3. Qualification, Skill, Review > 4.6.4. HR App intra-application integration > 4.7. Glossary -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11032) ServiceDispatcher implementation details should be private
[
https://issues.apache.org/jira/browse/OFBIZ-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840318#comment-16840318
]
Suraj Khurana commented on OFBIZ-11032:
---
+1.
Looks good to me.
> ServiceDispatcher implementation details should be private
> --
>
> Key: OFBIZ-11032
> URL: https://issues.apache.org/jira/browse/OFBIZ-11032
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
>
>
> The {{protected}} modifier is used for the ServiceDispatcher in place of
> {{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
> plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-11033) service 'loadSalesOrderItemFact' has hard coded currencyUomId
Pierre Smits created OFBIZ-11033: Summary: service 'loadSalesOrderItemFact' has hard coded currencyUomId Key: OFBIZ-11033 URL: https://issues.apache.org/jira/browse/OFBIZ-11033 Project: OFBiz Issue Type: Bug Components: bi Affects Versions: Release Branch 16.11, Release Branch 15.12, Trunk, Release Branch 14.12, Release Branch 13.07, Release Branch 17.12, Release Branch 18.12 Reporter: Pierre Smits Assignee: Pierre Smits Currency conversion in the loadSalesOrderItemFact does not work with the currency of the internal organisation but has a hardcoded USD. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10969) Unable to create Employments
[
https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840277#comment-16840277
]
Jacques Le Roux commented on OFBIZ-10969:
-
Oivier,
I tried to create an employment for DemoCustAgent, AUTHOR_BIGAL, AcctBuyer (all
persons) and got these errors
{noformat}
2019-05-15 12:01:33,657 |jsse-nio-8443-exec-8 |GenericDelegator
|E| Failure in create operation for entity [Employment]:
org.apache.ofbiz.entity.GenericEntityException: Error while inserting:
[GenericEntity:Employment][creat
edStamp,2019-05-15 12:01:33.596(java.sql.Timestamp)][createdTxStamp,2019-05-15
12:01:33.472(java.sql.Timestamp)][fromDate,2019-05-15
12:01:05.0(java.sql.Timestamp)][lastUpdatedStamp,2019-05-15
12:01:33.596(java.sql.Timestamp)][lastUpdate
dTxStamp,2019-05-15
12:01:33.472(java.sql.Timestamp)][partyIdFrom,Enterprise(java.lang.String)][partyIdTo,DemoCustAgent(java.lang.String)][roleTypeIdFrom,INTERNAL_ORGANIZATIO(java.lang.String)][roleTypeIdTo,EMPLOYEE(java.lang.String)]
(S
QL Exception while executing the following:INSERT INTO OFBIZ.EMPLOYMENT
(ROLE_TYPE_ID_FROM, ROLE_TYPE_ID_TO, PARTY_ID_FROM, PARTY_ID_TO, FROM_DATE,
THRU_DATE, TERMINATION_REASON_ID, TERMINATION_TYPE_ID, LAST_UPDATED_STAMP,
LAST_UPDATED_T
X_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?) (INSERT on table 'EMPLOYMENT' caused a violation of foreign key
constraint 'EMPLMNT_TPTRL' for key (DemoCustAgent,EMPLOYEE). The statement has
been ro
2019-05-15 12:02:33,011 |jsse-nio-8443-exec-6 |GenericDelegator
|E| Failure in create operation for entity [Employment]:
org.apache.ofbiz.entity.GenericEntityException: Error while inserting:
[GenericEntity:Employment][creat
edStamp,2019-05-15 12:02:33.009(java.sql.Timestamp)][createdTxStamp,2019-05-15
12:02:32.932(java.sql.Timestamp)][fromDate,2019-05-15
12:01:05.0(java.sql.Timestamp)][lastUpdatedStamp,2019-05-15
12:02:33.009(java.sql.Timestamp)][lastUpdate
dTxStamp,2019-05-15
12:02:32.932(java.sql.Timestamp)][partyIdFrom,Enterprise(java.lang.String)][partyIdTo,AUTHOR_BIGAL(java.lang.String)][roleTypeIdFrom,INTERNAL_ORGANIZATIO(java.lang.String)][roleTypeIdTo,EMPLOYEE(java.lang.String)]
(SQ
L Exception while executing the following:INSERT INTO OFBIZ.EMPLOYMENT
(ROLE_TYPE_ID_FROM, ROLE_TYPE_ID_TO, PARTY_ID_FROM, PARTY_ID_TO, FROM_DATE,
THRU_DATE, TERMINATION_REASON_ID, TERMINATION_TYPE_ID, LAST_UPDATED_STAMP,
LAST_UPDATED_TX
_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?) (INSERT on table 'EMPLOYMENT' caused a violation of foreign key
constraint 'EMPLMNT_TPTRL' for key (AUTHOR_BIGAL,EMPLOYEE). The statement has
been roll
ed back.)). Rolling back transaction.
2019-05-15 12:03:01,726 |jsse-nio-8443-exec-4 |GenericDelegator
|E| Failure in create operation for entity [Employment]:
org.apache.ofbiz.entity.GenericEntityException: Error while inserting:
[GenericEntity:Employment][creat
edStamp,2019-05-15 12:03:01.724(java.sql.Timestamp)][createdTxStamp,2019-05-15
12:03:01.704(java.sql.Timestamp)][fromDate,2019-05-15
12:01:05.0(java.sql.Timestamp)][lastUpdatedStamp,2019-05-15
12:03:01.724(java.sql.Timestamp)][lastUpdate
dTxStamp,2019-05-15
12:03:01.704(java.sql.Timestamp)][partyIdFrom,Enterprise(java.lang.String)][partyIdTo,AcctBuyer(java.lang.String)][roleTypeIdFrom,INTERNAL_ORGANIZATIO(java.lang.String)][roleTypeIdTo,EMPLOYEE(java.lang.String)]
(SQL E
xception while executing the following:INSERT INTO OFBIZ.EMPLOYMENT
(ROLE_TYPE_ID_FROM, ROLE_TYPE_ID_TO, PARTY_ID_FROM, PARTY_ID_TO, FROM_DATE,
THRU_DATE, TERMINATION_REASON_ID, TERMINATION_TYPE_ID, LAST_UPDATED_STAMP,
LAST_UPDATED_TX_ST
AMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?) (INSERT on table 'EMPLOYMENT' caused a violation of foreign key constraint
'EMPLMNT_TPTRL' for key (AcctBuyer,EMPLOYEE). The statement has been rolled bac
{noformat}
It works for DemoEmployee because s/he is already an employee and the
payHistory is then updated. So it needs to work also for new employees...
> Unable to create Employments
>
>
> Key: OFBIZ-10969
> URL: https://issues.apache.org/jira/browse/OFBIZ-10969
> Project: OFBiz
> Issue Type: Bug
> Components: humanres
>Affects Versions: Trunk
>Reporter: Arpit Mor
>Assignee: Jacques Le Roux
>Priority: Major
> Attachments: Image1.png
>
>
> Steps to regenerate:
> # Login to the URL:
> [https://demo-trunk.ofbiz.apache.org/humanres/control/main]
> # Click on Employments
> # Click on New Employments
> # Click on Create
> Actual: Error message is displayed. Please refer attachment: Image1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10969) Unable to create Employments
[ https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840258#comment-16840258 ] Jacques Le Roux commented on OFBIZ-10969: - No worries, to clarifiy I removed them and make this issue dependent-on/blocked-by OFBIZ-11028 > Unable to create Employments > > > Key: OFBIZ-10969 > URL: https://issues.apache.org/jira/browse/OFBIZ-10969 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: Image1.png > > > Steps to regenerate: > # Login to the URL: > [https://demo-trunk.ofbiz.apache.org/humanres/control/main] > # Click on Employments > # Click on New Employments > # Click on Create > Actual: Error message is displayed. Please refer attachment: Image1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-11028) field emplFromDate is forgot in PayHistory entity
[ https://issues.apache.org/jira/browse/OFBIZ-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11028: Issue Type: Bug (was: Sub-task) Parent: (was: OFBIZ-10969) > field emplFromDate is forgot in PayHistory entity > - > > Key: OFBIZ-11028 > URL: https://issues.apache.org/jira/browse/OFBIZ-11028 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk, 17.12.01, 18.12.01 >Reporter: Olivier Heintz >Assignee: Jacques Le Roux >Priority: Major > Labels: humanres > Fix For: Trunk > > Attachments: OFBIZ-11028.patch > > > A Employment can have multiple PayHistory and should have multiple > because PayHistory should show history of Pay for a employment ! > Currently, in PayHistory the field fromDate from Employment is confused with > fromDate about the current record, it's necessary to have a field > emplFromDate (to have the complete employment primaryKey). > Currently user interface for PayHistory is not working, when modifying a > PayRecord the current should be expire and a new one should be created. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10969) Unable to create Employments
[ https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10969: Attachment: (was: OFBIZ-10969.services.xml.patch) > Unable to create Employments > > > Key: OFBIZ-10969 > URL: https://issues.apache.org/jira/browse/OFBIZ-10969 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: Image1.png > > > Steps to regenerate: > # Login to the URL: > [https://demo-trunk.ofbiz.apache.org/humanres/control/main] > # Click on Employments > # Click on New Employments > # Click on Create > Actual: Error message is displayed. Please refer attachment: Image1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10969) Unable to create Employments
[ https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10969: Attachment: (was: OFBIZ-10969.HumanResServices.xml.patch) > Unable to create Employments > > > Key: OFBIZ-10969 > URL: https://issues.apache.org/jira/browse/OFBIZ-10969 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: Image1.png > > > Steps to regenerate: > # Login to the URL: > [https://demo-trunk.ofbiz.apache.org/humanres/control/main] > # Click on Employments > # Click on New Employments > # Click on Create > Actual: Error message is displayed. Please refer attachment: Image1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11019) Cleaning the bloated ‘Security’ interface
[ https://issues.apache.org/jira/browse/OFBIZ-11019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840246#comment-16840246 ] Jacques Le Roux commented on OFBIZ-11019: - Hi Mathieu, I don't see a urgent need for that but indeed why not cleaning stuff. The patch applies on trunk HEAD and looks good to me (I did not test). BTW, I agree with Michael about deprecation rules and "notations": https://markmail.org/message/c3pukn7dg4q5nzqz > Cleaning the bloated ‘Security’ interface > - > > Key: OFBIZ-11019 > URL: https://issues.apache.org/jira/browse/OFBIZ-11019 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: > OFBIZ-11019_Relax-the-contract-of-the-Security-interfac.patch > > > The ‘hasPermission(String, HttpSession)’ method declaration from the > ‘Security’ interface is breaking the minimality principle of interfaces > because it is easily expressible in term of ‘hasPermission(String, > GenericEntity)’. As a consequence a static helper method should be > implemented to achieve same convenience without polluting the ‘Security’ > interface. > Other methods in that interface are suffering from the same issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10969) Unable to create Employments
[ https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840227#comment-16840227 ] Olivier Heintz commented on OFBIZ-10969: Yes, and the two patch are included in OFBIZ-11028 so it's not needed to install them. Apologize for added patch in this task > Unable to create Employments > > > Key: OFBIZ-10969 > URL: https://issues.apache.org/jira/browse/OFBIZ-10969 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: Image1.png, OFBIZ-10969.HumanResServices.xml.patch, > OFBIZ-10969.services.xml.patch > > > Steps to regenerate: > # Login to the URL: > [https://demo-trunk.ofbiz.apache.org/humanres/control/main] > # Click on Employments > # Click on New Employments > # Click on Create > Actual: Error message is displayed. Please refer attachment: Image1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11032) ServiceDispatcher implementation details should be private
[
https://issues.apache.org/jira/browse/OFBIZ-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840221#comment-16840221
]
Jacques Le Roux commented on OFBIZ-11032:
-
Hi Mathieu, Girish,
The patch looks good to me, +1 to all here
> ServiceDispatcher implementation details should be private
> --
>
> Key: OFBIZ-11032
> URL: https://issues.apache.org/jira/browse/OFBIZ-11032
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
>
>
> The {{protected}} modifier is used for the ServiceDispatcher in place of
> {{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
> plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-11032) ServiceDispatcher implementation details should be private
[
https://issues.apache.org/jira/browse/OFBIZ-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840203#comment-16840203
]
Mathieu Lirzin commented on OFBIZ-11032:
I agree :)
> ServiceDispatcher implementation details should be private
> --
>
> Key: OFBIZ-11032
> URL: https://issues.apache.org/jira/browse/OFBIZ-11032
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
>
>
> The {{protected}} modifier is used for the ServiceDispatcher in place of
> {{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
> plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (OFBIZ-7963) Create a Gradle Sonar task
[ https://issues.apache.org/jira/browse/OFBIZ-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reopened OFBIZ-7963: - Re-opening as it is related to OFBIZ-10917 > Create a Gradle Sonar task > -- > > Key: OFBIZ-7963 > URL: https://issues.apache.org/jira/browse/OFBIZ-7963 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Pierre Smits >Priority: Minor > > As ever the devil is in details. There is no longer a Sonar plugin available > https://docs.gradle.org/current/userguide/sonar_plugin.htmland we should > rather refer to > http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Gradle > Anyway the most important part is to revivify INFRA-3590 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-7963) Create a Gradle Sonar task
[ https://issues.apache.org/jira/browse/OFBIZ-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reassigned OFBIZ-7963: --- Assignee: Pierre Smits (was: Jacques Le Roux) > Create a Gradle Sonar task > -- > > Key: OFBIZ-7963 > URL: https://issues.apache.org/jira/browse/OFBIZ-7963 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Pierre Smits >Priority: Minor > > As ever the devil is in details. There is no longer a Sonar plugin available > https://docs.gradle.org/current/userguide/sonar_plugin.htmland we should > rather refer to > http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Gradle > Anyway the most important part is to revivify INFRA-3590 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-11032) ServiceDispatcher implementation details should be private
[
https://issues.apache.org/jira/browse/OFBIZ-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840173#comment-16840173
]
Girish Vasmatkar commented on OFBIZ-11032:
--
Hi Mathieu,
With these changes we might as well mark the class final. Would you agree?
Best,
Girish
> ServiceDispatcher implementation details should be private
> --
>
> Key: OFBIZ-11032
> URL: https://issues.apache.org/jira/browse/OFBIZ-11032
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
>
>
> The {{protected}} modifier is used for the ServiceDispatcher in place of
> {{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
> plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-11032) ServiceDispatcher implementation details should be private
[
https://issues.apache.org/jira/browse/OFBIZ-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840128#comment-16840128
]
Mathieu Lirzin commented on OFBIZ-11032:
I will wait a couple of days for comments before committing
[^OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch].
> ServiceDispatcher implementation details should be private
> --
>
> Key: OFBIZ-11032
> URL: https://issues.apache.org/jira/browse/OFBIZ-11032
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
>
>
> The {{protected}} modifier is used for the ServiceDispatcher in place of
> {{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
> plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-11032) ServiceDispatcher implementation details should be private
[
https://issues.apache.org/jira/browse/OFBIZ-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11032:
---
Attachment: OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
> ServiceDispatcher implementation details should be private
> --
>
> Key: OFBIZ-11032
> URL: https://issues.apache.org/jira/browse/OFBIZ-11032
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11032_ServiceDispatcher-is-not-meant-to-be-extend.patch
>
>
> The {{protected}} modifier is used for the ServiceDispatcher in place of
> {{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
> plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-11032) ServiceDispatcher implementation details should be private
Mathieu Lirzin created OFBIZ-11032:
--
Summary: ServiceDispatcher implementation details should be private
Key: OFBIZ-11032
URL: https://issues.apache.org/jira/browse/OFBIZ-11032
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: Trunk
Reporter: Mathieu Lirzin
Assignee: Mathieu Lirzin
The {{protected}} modifier is used for the ServiceDispatcher in place of
{{private}}. Since the {{ServiceDispatcher}} is not meant to be extended by
plugins it is not desirable to use the {{protected}} modifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10969) Unable to create Employments
[ https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840113#comment-16840113 ] Jacques Le Roux commented on OFBIZ-10969: - I guess OFBIZ-11028 patch should be applied before, right? (It applies) > Unable to create Employments > > > Key: OFBIZ-10969 > URL: https://issues.apache.org/jira/browse/OFBIZ-10969 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: Image1.png, OFBIZ-10969.HumanResServices.xml.patch, > OFBIZ-10969.services.xml.patch > > > Steps to regenerate: > # Login to the URL: > [https://demo-trunk.ofbiz.apache.org/humanres/control/main] > # Click on Employments > # Click on New Employments > # Click on Create > Actual: Error message is displayed. Please refer attachment: Image1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10969) Unable to create Employments
[ https://issues.apache.org/jira/browse/OFBIZ-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840109#comment-16840109 ] Jacques Le Roux commented on OFBIZ-10969: - Sorry Olivier, Your patches don't apply on trunk HEAD. I guess you need to upgrade before creating the patches... > Unable to create Employments > > > Key: OFBIZ-10969 > URL: https://issues.apache.org/jira/browse/OFBIZ-10969 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Arpit Mor >Assignee: Jacques Le Roux >Priority: Major > Attachments: Image1.png, OFBIZ-10969.HumanResServices.xml.patch, > OFBIZ-10969.services.xml.patch > > > Steps to regenerate: > # Login to the URL: > [https://demo-trunk.ofbiz.apache.org/humanres/control/main] > # Click on Employments > # Click on New Employments > # Click on Create > Actual: Error message is displayed. Please refer attachment: Image1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-11031) Improve SalesOrderItemFact table
Pierre Smits created OFBIZ-11031: Summary: Improve SalesOrderItemFact table Key: OFBIZ-11031 URL: https://issues.apache.org/jira/browse/OFBIZ-11031 Project: OFBiz Issue Type: Improvement Components: bi Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 Reporter: Pierre Smits Improve the SalesOrderFactTable to include additional dimensions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10895) Unknown request [images]; this request does not exist or cannot be called directly.
[
https://issues.apache.org/jira/browse/OFBIZ-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840070#comment-16840070
]
Jacques Le Roux edited comment on OFBIZ-10895 at 5/15/19 6:17 AM:
--
Fixed in HR:
trunk r1859263+r1859268
R18 r1859264+1859269
Not a problem in older branches
was (Author: jacques.le.roux):
Fixed in HR:
trunk r1859263
R18 r1859264
Not a problem in older branches
> Unknown request [images]; this request does not exist or cannot be called
> directly.
> ---
>
> Key: OFBIZ-10895
> URL: https://issues.apache.org/jira/browse/OFBIZ-10895
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce, themes
>Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12,
> Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> This error happens in many occasions:
> Inside another request (here LookupProduct)
> {noformat}
> 2019-03-31 12:32:26,215 |jsse-nio-8443-exec-2 |ControlServlet
> |T| [[[LookupProduct(Domain:https://localhost)] Request Begun,
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2019-03-31 12:32:26,222 |jsse-nio-8443-exec-7 |ControlServlet
> |T| [[[images(Domain:https://localhost)] Request Begun, encoding=[UTF-8]-
> total:0.0,since last(Begin):0.0]]
> 2019-03-31 12:32:26,222 |jsse-nio-8443-exec-7 |ControlServlet
> |E| Error in request handler:
> org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown request
> [images]; this request does not exist or cannot be called directly.
> at
> org.apache.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:277)
> ~[ofbiz.jar:?]
> at
> org.apache.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:212)
> [ofbiz.jar:?]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> [tomcat-embed-websocket-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:191)
> [ofbiz.jar:?]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
> [ofbiz.jar:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:127)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
>
[jira] [Commented] (OFBIZ-10518) Inventory (Supply) Allocation Planning
[ https://issues.apache.org/jira/browse/OFBIZ-10518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840078#comment-16840078 ] Suraj Khurana commented on OFBIZ-10518: --- Improved condition in which reservation block was not being executed in case of auto-reserve not found in attribute. Done at rev #1859267 > Inventory (Supply) Allocation Planning > -- > > Key: OFBIZ-10518 > URL: https://issues.apache.org/jira/browse/OFBIZ-10518 > Project: OFBiz > Issue Type: New Feature > Components: order, product >Reporter: Deepak Nigam >Assignee: Suraj Khurana >Priority: Major > Fix For: Upcoming Branch > > Attachments: CreateAllocationPlan-Step1.png, > CreateAllocationPlan-Step2.png, CreateAllocationPlanEditMode-Step2.png, > EditAllocationPlan.png, FindAllocationPlan.png, OFBiz-10518-UI.patch, > OFBiz-10518-data.patch, OFBiz-10518-entity-model.patch, > OFBiz-10518-secas.patch, OFBiz-10518-services.patch, > OFBiz-10518-ui-labels.patch, OFBiz-10518.patch, OFBiz-10518.patch, > OFBiz-10518.patch, OFBiz-10518.patch, OFBiz-10518.patch, OFBiz-10518.patch, > ViewAllocationPlan.png > > > In the current implementation of inventory reservation flow, inventory gets > reserved for the order based on the reservation algorithm (FIFO, LIFO etc). > Many times, the fulfilment cycle of the order is too long or due to some > unexpected circumstances, the order holds the inventory for a long time. In > such scenarios, inventory availability becomes one of the major bottlenecks > in fulfilling the other sales order and businesses often remains short > supplied against the demand. > > We can provide a feature (Create, Find and Edit supply allocation screen) to > allocate the available and any future supply judiciously amongst existing > customers orders by considering different factors like estimated delivery > dates, order priority, customer preference etc. > > Following are the details design notes for the same: > > An order in the approved status will be considered as ‘Eligible for > Allocation’. The proposed supply allocation planning will have the following > set of features: > > *Create Allocation Plan:* > The authorized user will be able to initiate the process by setting the > desired product. > > *View/Edit Allocation Plan:* > 1) The system would search and list all the order lines which are eligible > for allocation for that particular product. > 2) The user can filter and sort the orders by various parameters like Sale > Channel, Customer, Order Id, Estimated Ship Date etc. > 3) The user can then prioritize the order by moving up or down the given > order in the priority ranking. Higher is the order in display result list, > higher will be the priority it would get during reservations. > 4) The user can set the ‘Allocated Quantity’ against ordered quantity at > order item line level. > 5) Once the Allocation Plan is submitted, the system would auto-assign the > priority and set the allocated quantity for each of the submitted orders to > be honoured during order reservations at any point in time. > 7) Incoming shipments would be reserved by honouring the same allocation plan > during order promising cycle. > 8) After allocating supply as per the allocation plan, any excess stock > should be reserved based on the standard FIFO method. > 9) If any of the items of an order is not planned via the Allocation Plan, > then also it should be reserved based on default FIFO criteria. > 10) The allocation for all the sales orders should be allowed for revision > unless the Shipment Plan is created against them. > > *Find Allocation Plan:* > The authorized user can search allocation plan(s) with filters like Plan Id, > Order Id, Product Id, Plan Method, Status etc. > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10895) Unknown request [images]; this request does not exist or cannot be called directly.
[
https://issues.apache.org/jira/browse/OFBIZ-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840071#comment-16840071
]
Jacques Le Roux commented on OFBIZ-10895:
-
BTW [we have a problem with "images" at
large|https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20text%20~%20%22images%22]
> Unknown request [images]; this request does not exist or cannot be called
> directly.
> ---
>
> Key: OFBIZ-10895
> URL: https://issues.apache.org/jira/browse/OFBIZ-10895
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce, themes
>Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12,
> Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> This error happens in many occasions:
> Inside another request (here LookupProduct)
> {noformat}
> 2019-03-31 12:32:26,215 |jsse-nio-8443-exec-2 |ControlServlet
> |T| [[[LookupProduct(Domain:https://localhost)] Request Begun,
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2019-03-31 12:32:26,222 |jsse-nio-8443-exec-7 |ControlServlet
> |T| [[[images(Domain:https://localhost)] Request Begun, encoding=[UTF-8]-
> total:0.0,since last(Begin):0.0]]
> 2019-03-31 12:32:26,222 |jsse-nio-8443-exec-7 |ControlServlet
> |E| Error in request handler:
> org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown request
> [images]; this request does not exist or cannot be called directly.
> at
> org.apache.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:277)
> ~[ofbiz.jar:?]
> at
> org.apache.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:212)
> [ofbiz.jar:?]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> [tomcat-embed-websocket-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:191)
> [ofbiz.jar:?]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
> [ofbiz.jar:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:127)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
>
[jira] [Commented] (OFBIZ-10895) Unknown request [images]; this request does not exist or cannot be called directly.
[
https://issues.apache.org/jira/browse/OFBIZ-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840070#comment-16840070
]
Jacques Le Roux commented on OFBIZ-10895:
-
Fixed in HR:
trunk r1859263
R18 r1859264
Not a problem in older branches
> Unknown request [images]; this request does not exist or cannot be called
> directly.
> ---
>
> Key: OFBIZ-10895
> URL: https://issues.apache.org/jira/browse/OFBIZ-10895
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce, themes
>Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12,
> Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> This error happens in many occasions:
> Inside another request (here LookupProduct)
> {noformat}
> 2019-03-31 12:32:26,215 |jsse-nio-8443-exec-2 |ControlServlet
> |T| [[[LookupProduct(Domain:https://localhost)] Request Begun,
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> 2019-03-31 12:32:26,222 |jsse-nio-8443-exec-7 |ControlServlet
> |T| [[[images(Domain:https://localhost)] Request Begun, encoding=[UTF-8]-
> total:0.0,since last(Begin):0.0]]
> 2019-03-31 12:32:26,222 |jsse-nio-8443-exec-7 |ControlServlet
> |E| Error in request handler:
> org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown request
> [images]; this request does not exist or cannot be called directly.
> at
> org.apache.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:277)
> ~[ofbiz.jar:?]
> at
> org.apache.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:212)
> [ofbiz.jar:?]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> [tomcat-embed-websocket-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:191)
> [ofbiz.jar:?]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
> [ofbiz.jar:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:127)
> [javax.servlet-api-4.0.1.jar:4.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> [tomcat-catalina-9.0.16.jar:9.0.16]
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
> [tomcat-coyote-9.0.16.jar:9.0.16]
[jira] [Commented] (OFBIZ-5776) Move static resources from framework/images to framework/resources webapp
[ https://issues.apache.org/jira/browse/OFBIZ-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840068#comment-16840068 ] Jacques Le Roux commented on OFBIZ-5776: HI Deepak, All, What is the situation here? > Move static resources from framework/images to framework/resources webapp > - > > Key: OFBIZ-5776 > URL: https://issues.apache.org/jira/browse/OFBIZ-5776 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Deepak Dixit >Assignee: Deepak Dixit >Priority: Minor > Attachments: OFBIZ-5776.patch > > > Move all the static resources form images webapp to resources webapp, as they > all are more related to resources rather then images. > Also we need to rearrange these resources based on their purpose, like > - Move all js related files and plugins under resources/js > - Move all the css related files and plugins under resources/css > - Move all the images related to js and css under resources/images or > resources/img -- This message was sent by Atlassian JIRA (v7.6.3#76005)
