[jira] [Created] (OFBIZ-4594) Broken JS file: jquery.hotkeys.js
Broken JS file: jquery.hotkeys.js - Key: OFBIZ-4594 URL: https://issues.apache.org/jira/browse/OFBIZ-4594 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Christoph Neuroth Priority: Trivial [This file|http://svn.apache.org/repos/asf/ofbiz/trunk/framework/images/webapp/images/jquery/plugins/hotkeys/jquery.hotkeys.js] is a downloaded github html page instead of the actual file. Has been since December 2010. Probably noone ever used this? -- 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] [Created] (OFBIZ-4595) renderDateTimeField does not allow to clear input field
renderDateTimeField does not allow to clear input field --- Key: OFBIZ-4595 URL: https://issues.apache.org/jira/browse/OFBIZ-4595 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Manuela Gruendlinger Priority: Minor Attachments: renderDateTime.patch Input fields rendered with renderDateTimeField cannot be cleared, the old value is always restored. -- 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-4595) renderDateTimeField does not allow to clear input field
[ https://issues.apache.org/jira/browse/OFBIZ-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manuela Gruendlinger updated OFBIZ-4595: Attachment: renderDateTime.patch renderDateTimeField does not allow to clear input field --- Key: OFBIZ-4595 URL: https://issues.apache.org/jira/browse/OFBIZ-4595 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Manuela Gruendlinger Priority: Minor Attachments: renderDateTime.patch Input fields rendered with renderDateTimeField cannot be cleared, the old value is always restored. -- 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] [Created] (OFBIZ-4596) URL parameter passed to secure (https) request-map is not allowed for security reasons
URL parameter passed to secure (https) request-map is not allowed for security reasons -- Key: OFBIZ-4596 URL: https://issues.apache.org/jira/browse/OFBIZ-4596 Project: OFBiz Issue Type: Test Components: product Environment: windows 7 Reporter: juning lee Hi,everyone~ I wrote a screen,which is made up of two forms,first one is a search form looking up a certain supplier,the second one is a list form, it shows all the products whose supplier is the choosen one,and you can modify the lastPrice by fill in the text and click the submit button next to it. It all goes well until I done a modification and tries to page down,an error occurs and says: Found URL parameter [partyId] passed to secure (https) request-map with uri [updateSupplierProductBySupplier] with an event that calls service [updateSupplierProduct]; this is not allowed for security reasons! The data should be encrypted by making it part of the request body (a form field) instead of the request URL. in the controller.xml I wrote this: request-map uri=updateSupplierProductBySupplier security https=true auth=true/ event type=service path= invoke=updateSupplierProduct/ response name=success type=request-redirect value=ListSupplierPriceBySupplierredirect-parameter name=partyId//response !-- goes back to the last page and passes partyId to the screen -- /request-map I don't quite understand what to do,so would anyone be so kind to tell me what should I do to solve this? Thx in advance~ lee 2011-11-29 -- 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: discussion: be able to add tags
Hi Hans, On Nov 26, 2011, at 12:32 AM, Hans Bakker wrote: Hi All, We have the need to be able to add pre-approved tags to products, content and workeffort. My guess is that you are implementing a backend workflow to approve products/contents/workefforts before they are allowed to be sold/published/used in production. in my opinion the three entities should be treated separately: * products: my preference is to use ProductCategory (with a new special productCategoryTypeId), the products in the category are the pre-approved ones; the advantages of this approach are: you can configure the system to have a different pre-approval for each catalog, or each product store, or simply one per product; the ProductCategoryMember.comments field could be used to store comments from the approver etc... * content: use the existing data model (ContentApproval etc...) * workeffort: use workeffort statuses (or WorkEffortReview etc...) Kind regards, Jacopo We have a similar function already in the system with keywords. However this is not pre-approved and less formal. I think we still can use this function as long as we can distinguish the tags and the keywords. There fore I would like to propose to add a field to the keyword entities: 'keywordType' with initially the type 'Tag' and empty or 'keyword' for the current function. The keywordType itself and the tags can be defined in the entity Enumeration. Your opinions please? Regards, Hans
Re: discussion: be able to add tags
Hi Jacopo, thanks for your reply... see my answers inline... On 11/29/2011 01:30 PM, Jacopo Cappellato wrote: Hi Hans, On Nov 26, 2011, at 12:32 AM, Hans Bakker wrote: Hi All, We have the need to be able to add pre-approved tags to products, content and workeffort. My guess is that you are implementing a backend workflow to approve products/contents/workefforts before they are allowed to be sold/published/used in production. Then i explained myself badly. The approval of the tags is important, not the approval of the products content or workeffort. Tags are intended to be used for grouping and selection only, like keywords but more organized and be able to improve searching combining the 2 possibilities. in my opinion the three entities should be treated separately: * products: my preference is to use ProductCategory (with a new special productCategoryTypeId), the products in the category are the pre-approved ones; the advantages of this approach are: you can configure the system to have a different pre-approval for each catalog, or each product store, or simply one per product; the ProductCategoryMember.comments field could be used to store comments from the approver etc... * content: use the existing data model (ContentApproval etc...) * workeffort: use workeffort statuses (or WorkEffortReview etc...) Kind regards, Jacopo We have a similar function already in the system with keywords. However this is not pre-approved and less formal. I think we still can use this function as long as we can distinguish the tags and the keywords. There fore I would like to propose to add a field to the keyword entities: 'keywordType' with initially the type 'Tag' and empty or 'keyword' for the current function. The keywordType itself and the tags can be defined in the entity Enumeration. Your opinions please? Regards, Hans
