[jira] [Commented] (OFBIZ-3829) MySQL 5.5 obsoleted Table TYPE, now ENGINE; causes Create Table statements to fail -- Old issue
[ https://issues.apache.org/jira/browse/OFBIZ-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13018740#comment-13018740 ] Paul Foxworthy commented on OFBIZ-3829: --- Did revision 1053722 fix this? See http://svn.apache.org/viewvc?rev=1053722view=rev MySQL 5.5 obsoleted Table TYPE, now ENGINE; causes Create Table statements to fail -- Old issue --- Key: OFBIZ-3829 URL: https://issues.apache.org/jira/browse/OFBIZ-3829 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: Release 4.0, Release Branch 09.04, Release 09.04, Release Branch 10.04, SVN trunk Environment: Testing verified on 10.0.4, but probably affected on all releases. Vista x64; MySQL 5.5.3-M3 Reporter: Brad Lanier Labels: MySQL, engine, entityengine, table-type, table_type, tabletype This is apparently an old issue (see OFBIZ-873 http://markmail.org/message/xggd7nsnorbbhvrv ) that has reared its ugly head again. In MySQL 5.5, TYPE is no longer supported in the table syntax. Here is the excerpt from What's new in MySQL 5.5: The following constructs are obsolete and have been removed in MySQL 5.5. Where alternatives are shown, applications should be updated to use them. * The table_type system variable (use storage_engine). *The TYPE table option to specify the storage engine for CREATE TABLE or ALTER TABLE (use ENGINE). The rest of the original issue is still applicable, so I won't repeat it here. Recommendation: Add a variable tableEngine (table-engine= in the entityengine.xml file datasource section) and appropriate code in DatabaseUtil.java, searching for and using the string ENGINE where TYPE is currently used, but keep the tableType constructs so as not to break other databases. Temporary workaround: Ensure MySQL 5.5 storage_engine server variable is set to InnoDB, and remove the table-type=InnoDB line from the datasource sections of the entityengine.xml file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Adding a non existent SecurityPermission to a SecurityPermissionGroup
Hi, in the https://localhost:8443/webtools/control/EditSecurityGroupPermissionsscreen, using the Add Permission (manually) to Security Group form, it is possible to add a non existent SecurityPermission to a SecurityPermissionGroup. Is this correct? Shouldn't any permission always be defined properly in the SecurityPermission entity before being referenced in a SecurityPermissionGroup? Thank you, Bruno
Plan for OFBiz stable Release_11.04?
Its mid of April month so I thought to start a thread in which we all can discuss about the stable release 11.04 of OFBiz trunk like we did last year. Thoughts? Thanks! -- Ashish
Re: Plan for OFBiz stable Release_11.04?
+1 -Adrian On 4/12/2011 3:52 AM, Ashish Vijaywargiya wrote: Its mid of April month so I thought to start a thread in which we all can discuss about the stable release 11.04 of OFBiz trunk like we did last year. Thoughts? Thanks! -- Ashish
[jira] [Created] (OFBIZ-4249) error in pagination target with on-event-update-area parameters
error in pagination target with on-event-update-area parameters --- Key: OFBIZ-4249 URL: https://issues.apache.org/jira/browse/OFBIZ-4249 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Gaudin Pierre In forms, when we use the tag on-event-update-area with parameters, in certain case the parameters of the tag are not taken back in the links of pagination. This is due to the fact that in certain case the url of pagination contains an anchor at the end of the link and parameters of the tag on-event-update-area are added after this anchor. This patch corrects this problem by adding the parameters of the tag on-event-update-area before parameter of the form and thus before those of the anchor. This is the old url : portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#portalPortletId=ListProduct') This is the url patched :portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPortletId=ListProductportalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#') -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4249) error in pagination target with on-event-update-area parameters
[ https://issues.apache.org/jira/browse/OFBIZ-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaudin Pierre updated OFBIZ-4249: - Attachment: MacroFormRenderer.java.patch error in pagination target with on-event-update-area parameters --- Key: OFBIZ-4249 URL: https://issues.apache.org/jira/browse/OFBIZ-4249 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Gaudin Pierre Attachments: MacroFormRenderer.java.patch In forms, when we use the tag on-event-update-area with parameters, in certain case the parameters of the tag are not taken back in the links of pagination. This is due to the fact that in certain case the url of pagination contains an anchor at the end of the link and parameters of the tag on-event-update-area are added after this anchor. This patch corrects this problem by adding the parameters of the tag on-event-update-area before parameter of the form and thus before those of the anchor. This is the old url : portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#portalPortletId=ListProduct') This is the url patched :portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPortletId=ListProductportalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#') -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4249) error in pagination target with on-event-update-area parameters
[ https://issues.apache.org/jira/browse/OFBIZ-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaudin Pierre updated OFBIZ-4249: - Attachment: MacroFormRenderer.java.patch error in pagination target with on-event-update-area parameters --- Key: OFBIZ-4249 URL: https://issues.apache.org/jira/browse/OFBIZ-4249 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Gaudin Pierre Attachments: MacroFormRenderer.java.patch In forms, when we use the tag on-event-update-area with parameters, in certain case the parameters of the tag are not taken back in the links of pagination. This is due to the fact that in certain case the url of pagination contains an anchor at the end of the link and parameters of the tag on-event-update-area are added after this anchor. This patch corrects this problem by adding the parameters of the tag on-event-update-area before parameter of the form and thus before those of the anchor. This is the old url : portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#portalPortletId=ListProduct') This is the url patched :portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPortletId=ListProductportalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#') -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4249) error in pagination target with on-event-update-area parameters
[ https://issues.apache.org/jira/browse/OFBIZ-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaudin Pierre updated OFBIZ-4249: - Attachment: (was: MacroFormRenderer.java.patch) error in pagination target with on-event-update-area parameters --- Key: OFBIZ-4249 URL: https://issues.apache.org/jira/browse/OFBIZ-4249 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Gaudin Pierre Attachments: MacroFormRenderer.java.patch In forms, when we use the tag on-event-update-area with parameters, in certain case the parameters of the tag are not taken back in the links of pagination. This is due to the fact that in certain case the url of pagination contains an anchor at the end of the link and parameters of the tag on-event-update-area are added after this anchor. This patch corrects this problem by adding the parameters of the tag on-event-update-area before parameter of the form and thus before those of the anchor. This is the old url : portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#portalPortletId=ListProduct') This is the url patched :portalPortletId is a parameter of tag on-event-update-area javascript:ajaxUpdateAreas('hhh,/myportal/control/ggg,portalPortletId=ListProductportalPageId=MYPORTAL_EMPLOYEE1parentPortalPageId=MYPORTAL_EMPLOYEEpartyId=adminnoConditionFind=NVIEW_SIZE_2=3VIEW_INDEX_2=1#') -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Plan for OFBiz stable Release_11.04?
+1 Jacques From: Adrian Crum adrian.c...@sandglass-software.com +1 -Adrian On 4/12/2011 3:52 AM, Ashish Vijaywargiya wrote: Its mid of April month so I thought to start a thread in which we all can discuss about the stable release 11.04 of OFBiz trunk like we did last year. Thoughts? Thanks! -- Ashish
Re: Adding a non existent SecurityPermission to a SecurityPermissionGroup
http://ofbiz.135035.n4.nabble.com/security-permission-td154203.html#a154208 Regards Scott HotWax Media http://www.hotwaxmedia.com On 12/04/2011, at 10:38 PM, Bruno Busco wrote: Hi, in the https://localhost:8443/webtools/control/EditSecurityGroupPermissionsscreen, using the Add Permission (manually) to Security Group form, it is possible to add a non existent SecurityPermission to a SecurityPermissionGroup. Is this correct? Shouldn't any permission always be defined properly in the SecurityPermission entity before being referenced in a SecurityPermissionGroup? Thank you, Bruno smime.p7s Description: S/MIME cryptographic signature
Re: Adding a non existent SecurityPermission to a SecurityPermissionGroup
Hi Scott, many thanks for the pointer. This was definitively a well discussed topic. Personally I do not agree with how it it designed right now (with the no-fk) for this two reasons: 1) If a SecurityPermission has not its own entity record there will never be a description field where the user can understand (or remember) what that permission is supposed to be used for. 2) There is no check that an already defined PermissionId is not used again for a different purpose in a different part of the code. Thank you, Bruno 2011/4/13 Scott Gray scott.g...@hotwaxmedia.com http://ofbiz.135035.n4.nabble.com/security-permission-td154203.html#a154208 Regards Scott HotWax Media http://www.hotwaxmedia.com On 12/04/2011, at 10:38 PM, Bruno Busco wrote: Hi, in the https://localhost:8443/webtools/control/EditSecurityGroupPermissionsscreen , using the Add Permission (manually) to Security Group form, it is possible to add a non existent SecurityPermission to a SecurityPermissionGroup. Is this correct? Shouldn't any permission always be defined properly in the SecurityPermission entity before being referenced in a SecurityPermissionGroup? Thank you, Bruno