[jira] [Created] (OFBIZ-10176) Add an option "All" to show entities of all groups
Vaibhav Jain created OFBIZ-10176: Summary: Add an option "All" to show entities of all groups Key: OFBIZ-10176 URL: https://issues.apache.org/jira/browse/OFBIZ-10176 Project: OFBiz Issue Type: Bug Reporter: Vaibhav Jain Steps to regenerate: # Click on Entity Engine tab of Webtools. # By default entities of all the groups are listed down. # If we apply a filter then entities are listed according to the group. # We don't have an option "All" to list entities of all groups. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-1948) The ecommerce.css file should be moved to /applications/ecommerce
[ https://issues.apache.org/jira/browse/OFBIZ-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333868#comment-16333868 ] Deepak Dixit commented on OFBIZ-1948: - Thanks Jacques. > The ecommerce.css file should be moved to /applications/ecommerce > - > > Key: OFBIZ-1948 > URL: https://issues.apache.org/jira/browse/OFBIZ-1948 > Project: OFBiz > Issue Type: Improvement > Components: ecommerce >Reporter: Bruno Busco >Assignee: Jacques Le Roux >Priority: Minor > > In order to have the framework not dependent from applications -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10164) Splitter Widget
[ https://issues.apache.org/jira/browse/OFBIZ-10164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333568#comment-16333568 ] James Yong edited comment on OFBIZ-10164 at 1/21/18 4:10 PM: - Uploaded a 2nd version of the patch with the following improvements. 1) Improved documentation 2) No need for define Id of the parent container 3) Core CSS remains in split.css while custom CSS for the Commons Widget is defined in the style.css file of each theme. P.S. 4) Also removed the need of square brackets for the 'sizes' attribute value. was (Author: jamesyong): Uploaded a 2nd version of the patch with the following improvements. 1) Improved documentation 2) No need for define Id of the parent container 3) Core CSS remains in split.css while custom CSS for the Commons Widget is defined in the style.css file of each theme. > Splitter Widget > --- > > Key: OFBIZ-10164 > URL: https://issues.apache.org/jira/browse/OFBIZ-10164 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: James Yong >Assignee: James Yong >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10164.patch, OFBIZ-10164.patch, horizontal.png, > vertical.png > > > A new splitter widget that will use a tag named 'splitter'. > This splitter tag has the following attributes: > a. sizes = [25, 75] where the containers within will be splitted with a ratio > of 25% and 75% > b. parentId which is the ID of the parent container > c. direction = vertical or horizonal (default) > The splitter tag can only contains container(s) as immediate child. > Using the library from http://nathancahill.github.io/Split.js/ which is > licensed under MIT license. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10164) Splitter Widget
[ https://issues.apache.org/jira/browse/OFBIZ-10164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333568#comment-16333568 ] James Yong commented on OFBIZ-10164: Uploaded a 2nd version of the patch with the following improvements. 1) Improved documentation 2) No need for define Id of the parent container 3) Core CSS remains in split.css while custom CSS for the Commons Widget is defined in the style.css file of each theme. > Splitter Widget > --- > > Key: OFBIZ-10164 > URL: https://issues.apache.org/jira/browse/OFBIZ-10164 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: James Yong >Assignee: James Yong >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10164.patch, OFBIZ-10164.patch, horizontal.png, > vertical.png > > > A new splitter widget that will use a tag named 'splitter'. > This splitter tag has the following attributes: > a. sizes = [25, 75] where the containers within will be splitted with a ratio > of 25% and 75% > b. parentId which is the ID of the parent container > c. direction = vertical or horizonal (default) > The splitter tag can only contains container(s) as immediate child. > Using the library from http://nathancahill.github.io/Split.js/ which is > licensed under MIT license. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10164) Splitter Widget
[ https://issues.apache.org/jira/browse/OFBIZ-10164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Yong updated OFBIZ-10164: --- Attachment: OFBIZ-10164.patch > Splitter Widget > --- > > Key: OFBIZ-10164 > URL: https://issues.apache.org/jira/browse/OFBIZ-10164 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: James Yong >Assignee: James Yong >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10164.patch, OFBIZ-10164.patch, horizontal.png, > vertical.png > > > A new splitter widget that will use a tag named 'splitter'. > This splitter tag has the following attributes: > a. sizes = [25, 75] where the containers within will be splitted with a ratio > of 25% and 75% > b. parentId which is the ID of the parent container > c. direction = vertical or horizonal (default) > The splitter tag can only contains container(s) as immediate child. > Using the library from http://nathancahill.github.io/Split.js/ which is > licensed under MIT license. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OFBIZ-10175) rename the common-theme component directory
[ https://issues.apache.org/jira/browse/OFBIZ-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb resolved OFBIZ-10175. - Resolution: Fixed Fix Version/s: Upcoming Branch Committed the rename in r1821789. All tests are passing from my side. Will wait a few days before closing after ensuring proper operation. > rename the common-theme component directory > --- > > Key: OFBIZ-10175 > URL: https://issues.apache.org/jira/browse/OFBIZ-10175 > Project: OFBiz > Issue Type: Improvement >Reporter: Taher Alkhateeb >Assignee: Taher Alkhateeb >Priority: Minor > Fix For: Upcoming Branch > > > as per the [discussion > thread|https://lists.apache.org/thread.html/3309a81eb5f8cce1e5e139bd1d86bfc40cc7ae298fa57dc6caf1e0be@%3Cdev.ofbiz.apache.org%3E] > this Jira is created for renaming the common-theme component directory from > "common" to "common-theme". The reason for this change is to ensure that not > only are component names unique, but also the directories are unique, and > preferably, match the component names defined in ofbiz-component.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[ https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333495#comment-16333495 ] Jacques Le Roux commented on OFBIZ-10141: - Hi Michael, Any chances? > Add a VERSION file in root dir > -- > > Key: OFBIZ-10141 > URL: https://issues.apache.org/jira/browse/OFBIZ-10141 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 17.12.01 > > Attachments: OFBIZ-10141.patch > > > Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have > decided to > # have VERSION file at project root to store released version. > # Render the version in the applications footer template as a HTML comment. > Also [~mbrohl] suggested that > # it can be automatically set by (custom) builds to be generated. > # It should be made configurable in general.properties to prevent to show it > if the user does not want this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10146) Removing of loadBestSellingCategory and all related methods in CategoryServices.xml
[
https://issues.apache.org/jira/browse/OFBIZ-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333493#comment-16333493
]
Jacques Le Roux commented on OFBIZ-10146:
-
This was put in with
http://svn.apache.org/viewvc?view=revision=1055774 So if [~hansbak]
has nothing more to say about it I think we can indeed remove the whole
> Removing of loadBestSellingCategory and all related methods in
> CategoryServices.xml
> ---
>
> Key: OFBIZ-10146
> URL: https://issues.apache.org/jira/browse/OFBIZ-10146
> Project: OFBiz
> Issue Type: Improvement
> Components: product
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10146.patch
>
>
> While doing some conversions from MiniLang to Groovy, I stumbled across these
> methods:
> {{loadBestSellingCategory}}
> {{RemoveProductFromBestSellCategory}}
> {{AddProductToBestSellCategory}}
> {{FindCategoryChild}}
> {{FindBestSellingProduct}}
> These are all in {{CategoryServices.xml}}.
> I started realizing, that the simple-method {{loadBestSellingCategory}}
> doesn't work right (there are some logical failures in it) and while fixing
> it,
> I searched for places where this is used, but couldn't find any.
> I started looking deeper into it and found that all of these methods are
> never used anywhere in OFBiz, neither are the services which are declared for
> this methods.
> This is why I propose to remove them; they have no real use, since they don't
> work properly, and also are never used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10175) rename the common-theme component directory
Taher Alkhateeb created OFBIZ-10175: --- Summary: rename the common-theme component directory Key: OFBIZ-10175 URL: https://issues.apache.org/jira/browse/OFBIZ-10175 Project: OFBiz Issue Type: Improvement Reporter: Taher Alkhateeb Assignee: Taher Alkhateeb as per the [discussion thread|https://lists.apache.org/thread.html/3309a81eb5f8cce1e5e139bd1d86bfc40cc7ae298fa57dc6caf1e0be@%3Cdev.ofbiz.apache.org%3E] this Jira is created for renaming the common-theme component directory from "common" to "common-theme". The reason for this change is to ensure that not only are component names unique, but also the directories are unique, and preferably, match the component names defined in ofbiz-component.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333457#comment-16333457 ] Jacques Le Roux commented on OFBIZ-3373: About my question on test above: Bruno Busco tested it the 16/Aug/10, that's explained at bottom of OFBIZ-3807 > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, > injections.patch, links.jpg, partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9557) Add the ability to schedule a job to run as a system/service user
[ https://issues.apache.org/jira/browse/OFBIZ-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333455#comment-16333455 ] Jacques Le Roux commented on OFBIZ-9557: A checkbox would be OK, but, for security reason, not OOTB. Because once you have access to this screen you could do what you want with jobs. OFBiz users must take the responsability for that. So I'd recommend introducting a security (seems most fitting) property, like bq. runJobAsSystemUser=false This would be used for showing the checkbox and bypassing the LDAP authentication in code > Add the ability to schedule a job to run as a system/service user > - > > Key: OFBIZ-9557 > URL: https://issues.apache.org/jira/browse/OFBIZ-9557 > Project: OFBiz > Issue Type: Improvement > Components: tools >Reporter: Matthew Mulligan >Priority: Major > > When scheduling a job it automatically schedules it to run as the user that > created the schedule. The issue comes up when that users password changes. > We use LDAP authentication and our passwords change every 90 days. Right now > every 90 days when my password changes I have to delete all previously > scheduled jobs and recreate them. > What would be nice is an option when scheduling the job to Run as System > account or Run as User and be able to put the users name in. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-1803) Product/Category pages link in Product/Category edit screens should link to the associated store
[ https://issues.apache.org/jira/browse/OFBIZ-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-1803. -- Resolution: Duplicate Assignee: Jacques Le Roux This is interesting but is superseded by OFBIZ-9241. Now that ecommerce is a plugin we should not have any reference from core to ecommerce > Product/Category pages link in Product/Category edit screens should link to > the associated store > > > Key: OFBIZ-1803 > URL: https://issues.apache.org/jira/browse/OFBIZ-1803 > Project: OFBiz > Issue Type: Improvement > Components: ecommerce, product >Affects Versions: Trunk >Reporter: Bruno Busco >Assignee: Jacques Le Roux >Priority: Minor > > The EditCategory and EditProduct pages are provided of a "Category Page" and > "Product Page" link that allow the user to easily open the page of the Web > site that shows the category or the product being edited. > The link at the moment is static and points to a URL like > /ecommerce/control/category. > This should rather be dynamic so to link to the WebStore that is linked to > the Catalog that could have a different URL. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-1803) Product/Category pages link in Product/Category edit screens should link to the associated store
[ https://issues.apache.org/jira/browse/OFBIZ-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=12833451#comment-12833451 ] Jacques Le Roux edited comment on OFBIZ-1803 at 1/21/18 10:13 AM: -- We should also consider that this button actually introduces a dependance of the product component on the ecommerce one that should not be. This is a good example of where the menu merge feature we discussed in OFBIZ-3373 would be usefull. The product component should define the menu without these buttons. The ecommerce application (or any other application implementing the web store) could merge into the product defined menu a new button with the proper URL. was (Author: bruno.busco): We should also consider that this button actually introduces a dependance of the product component on the ecommerce one that should not be. This is a good example of where the menu merge feature we discussed in https://issues.apache.org/jira/browse/OFBIZ-3373 would be usefull. The product component should define the menu without these buttons. The ecommerce application (or any other application implementing the web store) could merge into the product defined menu a new button with the proper URL. > Product/Category pages link in Product/Category edit screens should link to > the associated store > > > Key: OFBIZ-1803 > URL: https://issues.apache.org/jira/browse/OFBIZ-1803 > Project: OFBiz > Issue Type: Improvement > Components: ecommerce, product >Affects Versions: Trunk >Reporter: Bruno Busco >Priority: Minor > > The EditCategory and EditProduct pages are provided of a "Category Page" and > "Product Page" link that allow the user to easily open the page of the Web > site that shows the category or the product being edited. > The link at the moment is static and points to a URL like > /ecommerce/control/category. > This should rather be dynamic so to link to the WebStore that is linked to > the Catalog that could have a different URL. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333449#comment-16333449 ] Jacques Le Roux commented on OFBIZ-3373: Hi Scott, is this still relevant? > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, > injections.patch, links.jpg, partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4931) Proposal to remove catalog's "Template Path Prefix" and "Content Path Prefix"
[ https://issues.apache.org/jira/browse/OFBIZ-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333441#comment-16333441 ] Jacques Le Roux commented on OFBIZ-4931: What is the situation here? We know it's useful in the standard context but throw a bug in multi-tenant context, so what next? > Proposal to remove catalog's "Template Path Prefix" and "Content Path Prefix" > - > > Key: OFBIZ-4931 > URL: https://issues.apache.org/jira/browse/OFBIZ-4931 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Wai >Priority: Major > Attachments: OFBIZ-4931.patch > > > In reference to the posting, > http://ofbiz.135035.n4.nabble.com/Proposal-to-remove-catalog-s-quot-Template-Path-Prefix-quot-field-from-user-interface-td4633296.html > http://demo-trunk.ofbiz.apache.org/catalog/control/EditProdCatalog?prodCatalogId=DemoCatalog > It seems that the code blindly prepends the "Template Path Prefix" value to > the category's "Detail Screen" field resulting in a file path format that > would cause an exception. > Hence, if a catalog's "Template Path Prefix" is "zzz" and a category's > "Detail Screen" is "somedetailscreen", the resulting screen that ofbiz looks > for is "/zzzsomedetailscreen". Which ofbiz would not be able to locate based > on the format of the screen location. Hence, cause an exception. > If a catalog's "Template Path Prefix" is "zzz" and a category's "Detail > Screen" is > "component://ecommerce/widget/CatalogScreens.xml#somedetailscreen", the > resulting screen that ofbiz looks for is > "/zzzcomponent://ecommerce/widget/CatalogScreens.xml#somedetailscreen". > Which ofbiz would not be able to located due to the improper format. Hence > cause an exception. > Since this code never worked since 2006 when it was first placed into the svn > repository. I don't think anyone has made use of it since. > Regarding a catalog's "Content Path Prefix" field, it also exhibits the same > flaw. That of blindly prepending this field. This field is generally used to > specify the product images to be shown in the ecommerce component. > When this field is empty, the generated image url in ecommerce is shown below > (note that it is using "image" webapp context): > /images/products/ENCHILADAS/small.png > If you were to specify "/zzz" for "Content Path Prefix", the resulting url > for the generated image tag is shown below (note that it is using "zzz" > webapp context): > /zzz/images/products/ENCHILADAS/small.png > As you can see. "Content Path Prefix" specifies a "zzz" webapp context with > a subdirectory "image". I doubt this was the intent of the field. The > question is, where exactly are you supposed to place this field value? > I propose to remove the catalog's "Template Path Prefix" field from the > catalog's user interface and assoc code to reduce the confusion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-1948) The ecommerce.css file should be moved to /applications/ecommerce
[ https://issues.apache.org/jira/browse/OFBIZ-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-1948. -- Resolution: Not A Problem Assignee: Jacques Le Roux I close, we no longer have an ecommerce.css file > The ecommerce.css file should be moved to /applications/ecommerce > - > > Key: OFBIZ-1948 > URL: https://issues.apache.org/jira/browse/OFBIZ-1948 > Project: OFBiz > Issue Type: Improvement > Components: ecommerce >Reporter: Bruno Busco >Assignee: Jacques Le Roux >Priority: Minor > > In order to have the framework not dependent from applications -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-3505) Data model to have Content and Party applications not dependant on other applications
[ https://issues.apache.org/jira/browse/OFBIZ-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3505. -- Resolution: Won't Do Assignee: Jacques Le Roux Actually I completely reviewed the issue and it's clear it can be closed right now > Data model to have Content and Party applications not dependant on other > applications > - > > Key: OFBIZ-3505 > URL: https://issues.apache.org/jira/browse/OFBIZ-3505 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Reporter: Bruno Busco >Assignee: Jacques Le Roux >Priority: Minor > Attachments: ofbiz_core.patch, party_to_agreement_entity_move.patch > > > The patch attached is the work I did to try to have the Content and Party > applications not dependent on the other applications. > The patch only changes the data model and not the application code also so > applying the patch results in a not working OFBiz. > The purpose of the patch is to describe the solution I found to remove the > mentioned dependencies and, if agreed, could be the base to change the code > accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
