Re: Sharing Shopping Cart across multiple Stores in OFbiz
Hello Freeman, Thanks for your reply. Yes it is the first case. The same company holds multiple stores in the website, and the shopping cart has to be shared across multiple stores. Its like a customer can log into any one of the store and start adding products to the cart. And when he switches among the stores, the products added in any of the stores should be visible in any of the available stores, so that he can check out from any store, at the point he stops shopping. How can this be achieved? Does the current OFBiz implementation provide this functionality. Or if we have to do any customizations, can you please throw some light in this aspect, and help me in understanding where to start how to go about doing it? Regards, Naveen Kumar B.V On Thu, Dec 2, 2010 at 12:46 AM, BJ Freeman bjf...@free-man.net wrote: if you have the same company that owns the websites then you can look at the clone of eccomerce. this uses the same code but the cart, for a customer will not move between websites, without customization. IF they are different Companies that own the Websites then look at the multitenant. This has same code but different DB. this would take different customization to move the cart between sites. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Naveen Kumar B V sent the following on 12/1/2010 10:53 AM: Hi, In our business scenario, we have configured two Stores in the front end, i.e., we have two different applications configured as Stores in the front end. We know that each store can have its own shopping cart where products can be added into it and checked it. Can we configure the app in such a way that the Shopping Cart should be shared across multiple stores? When a customer visits the application he should be able to shop in multiple stores and the products added in one store should be available (i.e, should be seen) in other stores also. How can this be achieved? Regards, Naveen Kumar B.V
Re: svn propchange: r1036154 - svn:log
Hi, Yesterday I worked on the jQuery 1.4.3, 1.4.4 issue. It appears now that with 1.4.4 only Firefox has an issue with lookups. I tested (on Windows), with last versions of Chrome, Opera, IE8 and Safari and all worked like a charm. I thought it could be related to this issue http://bugs.jquery.com/ticket/7340. It seems it's even less a problem since, apart Firefox (3.6.13), all browsers work. So I will stay with 1.4.2 waiting for 1.4.5 or even 1.5. Jacques From: jler...@apache.org Author: jleroux Revision: 1036154 Modified property: svn:log Modified: svn:log at Wed Nov 17 18:26:42 2010 -- --- svn:log (original) +++ svn:log Wed Nov 17 18:26:42 2010 @@ -7,4 +7,4 @@ This commit introduces * revert calls to the jQuery lib from 1.4.4 version to 1.4.2 * in order to help investigations put back jQuery libs 1.4.2 and 1.4.3 -Something to note though: the problem was detected on Windows (both XP and Win7) but it was working fine on Mac with 1.4.4. I checked and it works also well on Windows (XP) when using Safari with jQuery 1.4.4! +Something to note though: the problem was detected on Windows with Firefox and Chrome (on both XP and Win7) but it was working fine on Mac with 1.4.4. I checked and it works also well on Windows (XP) when using Safari with jQuery 1.4.4!
Functionality differences in OFBiz9.x and 10.x versions
Hi, How can i know the differences in functionalities between OFBiz 9.x and 10.x versions. OFBiz 10.x implementation might have some new implementations, fixes enhancements when compared to 9.x. Do we have a document which gives me this information. Regards, Naveen Kumar B.V
Re: Functionality differences in OFBiz9.x and 10.x versions
Oops, I replied to dev ML when it should be only user Please Naveen in the furure use only user ML for such questions, see why here : http://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists#MailingLists-DesignanddevelopmentList:dev@ofbiz.apache.org Thanks Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Maybe not complete and uneasy but at least you could look between April 2009 and April 2010 in https://cwiki.apache.org/confluence/display/OFBIZ/Main+New+Features Jacques From: Naveen Kumar B V naveen.whishwo...@gmail.com Hi, How can i know the differences in functionalities between OFBiz 9.x and 10.x versions. OFBiz 10.x implementation might have some new implementations, fixes enhancements when compared to 9.x. Do we have a document which gives me this information. Regards, Naveen Kumar B.V
Re: fail-message
Thanks to Marco's courageous effort, I can remove soon this from my todo list. BTW, Marco I can help on the framework part, if you have nothing pending there yet... Thanks! Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com From: David E Jones jone...@hotwaxmedia.com Are we feeling a little domineering today? No actually I'm not domineering, simply exhausted. These 500+ changes certainly discouraged me, hence my reaction. I should keep cool, and I will... Just because internationalizing code is a best practice doesn't mean it's the ONLY practice, and I don't think we want to force it for any and all users of OFBiz (ie those writing their own applications, etc). That's the thing with best practices: we want them and we want to recommend them and for the main code base even ask people to follow them. We also want primary and secondary/other best practices. Still, not being omniscient we don't want to think we know everything and not have any flexibility in the framework. Yes I was re-thinking about it, and it occured to me that of course we should keep it and simply discourage its usage in OFBiz stock (yes, you contributors, commiters, ... :o) Jacques -David On Jul 12, 2008, at 2:10 PM, Jacques Le Roux wrote: Hi, I think we should deprecate, and at term remove the fail-message tag. There are 500+ ot them in current code. They are not localisable. So for me it's a bad practice, and we should prevent people to use this tag anymore. I can't see from the top of my head if there are some other aspects in OFBiz which encourage such bad practices (not localisable). What do you think ? Jacques
R: Re: fail-message
Yes, Jacques I'm still working to remove fail-message tag from applications and specialpurpose components. If you want to help me to remove it from framework components I will appreciate it. Thanks Marco Messaggio originale Da: jacques.ler...@9business.fr Data: 22/12/2010 11.43 A: dev@ofbiz.apache.org Ogg: Re: lt;fail-messagegt; Thanks to Marco's courageous effort, I can remove soon this from my todo list. BTW, Marco I can help on the framework part, if you have nothing pending there yet... Thanks! Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com From: David E Jones jone...@hotwaxmedia.com Are we feeling a little domineering today? No actually I'm not domineering, simply exhausted. These 500+ changes certainly discouraged me, hence my reaction. I should keep cool, and I will... Just because internationalizing code is a best practice doesn't mean it's the ONLY practice, and I don't think we want to force it for any and all users of OFBiz (ie those writing their own applications, etc). That's the thing with best practices: we want them and we want to recommend them and for the main code base even ask people to follow them. We also want primary and secondary/other best practices. Still, not being omniscient we don't want to think we know everything and not have any flexibility in the framework. Yes I was re-thinking about it, and it occured to me that of course we should keep it and simply discourage its usage in OFBiz stock (yes, you contributors, commiters, ... :o) Jacques -David On Jul 12, 2008, at 2:10 PM, Jacques Le Roux wrote: Hi, I think we should deprecate, and at term remove the fail-message tag. There are 500+ ot them in current code. They are not localisable. So for me it's a bad practice, and we should prevent people to use this tag anymore. I can't see from the top of my head if there are some other aspects in OFBiz which encourage such bad practices (not localisable). What do you think ? Jacques
Re: Re: fail-message
OK, count me in Jacques From: mrisal...@libero.it Yes, Jacques I'm still working to remove fail-message tag from applications and specialpurpose components. If you want to help me to remove it from framework components I will appreciate it. Thanks Marco Messaggio originale Da: jacques.ler...@9business.fr Data: 22/12/2010 11.43 A: dev@ofbiz.apache.org Ogg: Re: lt;fail-messagegt; Thanks to Marco's courageous effort, I can remove soon this from my todo list. BTW, Marco I can help on the framework part, if you have nothing pending there yet... Thanks! Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com From: David E Jones jone...@hotwaxmedia.com Are we feeling a little domineering today? No actually I'm not domineering, simply exhausted. These 500+ changes certainly discouraged me, hence my reaction. I should keep cool, and I will... Just because internationalizing code is a best practice doesn't mean it's the ONLY practice, and I don't think we want to force it for any and all users of OFBiz (ie those writing their own applications, etc). That's the thing with best practices: we want them and we want to recommend them and for the main code base even ask people to follow them. We also want primary and secondary/other best practices. Still, not being omniscient we don't want to think we know everything and not have any flexibility in the framework. Yes I was re-thinking about it, and it occured to me that of course we should keep it and simply discourage its usage in OFBiz stock (yes, you contributors, commiters, ... :o) Jacques -David On Jul 12, 2008, at 2:10 PM, Jacques Le Roux wrote: Hi, I think we should deprecate, and at term remove the fail-message tag. There are 500+ ot them in current code. They are not localisable. So for me it's a bad practice, and we should prevent people to use this tag anymore. I can't see from the top of my head if there are some other aspects in OFBiz which encourage such bad practices (not localisable). What do you think ? Jacques
[jira] Commented: (OFBIZ-4067) jQuery ecommerce onepagecheckout issue
[
https://issues.apache.org/jira/browse/OFBIZ-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12974209#action_12974209
]
Rohit Sureka commented on OFBIZ-4067:
-
HI Sascha,
i tried your latest patch and it works really fine. The issues reported in this
Jira, have now been addressed.
There however needs some more work to be done in onePageCheckout, like showing
multiple addresses as options to a returning customer and also supporting
multiple payment options supported by ofbiz and not just credit card. I am not
sure, if these features requests should be enlisted in this Jira, as they were
never part of the original onepagecheckout, in the first place.
Thanks for the great work.
Rohit
jQuery ecommerce onepagecheckout issue
--
Key: OFBIZ-4067
URL: https://issues.apache.org/jira/browse/OFBIZ-4067
Project: OFBiz
Issue Type: Sub-task
Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Sascha Rodekamp
Fix For: SVN trunk
Attachments: OFBIZ-4067_FixOnePageCheckout.patch,
OFBIZ-4067_FixOnePageCheckout.patch
Rohit reported a bug in the jQuery implementation (ecommerce)
{quote}
hi..
with the jQuery branch being merged into the trunk, 2 new issues have been
identified in the onepagecheckout, and they are:
1) the remove item link does not work in the shoppingcart panel, and
2) the cart is not updated if cart quantity is changed or promo codes are
entered.
Rohit
{quote}
Thanks Rhoit, i fix this next week.
Cheers
Sascha
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4067) jQuery ecommerce onepagecheckout issue
[
https://issues.apache.org/jira/browse/OFBIZ-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12974276#action_12974276
]
Sascha Rodekamp commented on OFBIZ-4067:
Hi Rohit,
thanks for your testing. I think this patch can be commited and the task can be
closed.
For the other things we can open a new task, because the describes function are
not related to this bug .. that keeps things clear.
Have a good day
Sascha
jQuery ecommerce onepagecheckout issue
--
Key: OFBIZ-4067
URL: https://issues.apache.org/jira/browse/OFBIZ-4067
Project: OFBiz
Issue Type: Sub-task
Components: specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Sascha Rodekamp
Fix For: SVN trunk
Attachments: OFBIZ-4067_FixOnePageCheckout.patch,
OFBIZ-4067_FixOnePageCheckout.patch
Rohit reported a bug in the jQuery implementation (ecommerce)
{quote}
hi..
with the jQuery branch being merged into the trunk, 2 new issues have been
identified in the onepagecheckout, and they are:
1) the remove item link does not work in the shoppingcart panel, and
2) the cart is not updated if cart quantity is changed or promo codes are
entered.
Rohit
{quote}
Thanks Rhoit, i fix this next week.
Cheers
Sascha
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Create/New Terminology Best Practice
The OFBiz UI is very inconsistent in the terminology for creating something new - for example creating a new order, a new fixed asset, a new party, etc. Some screens are titled New [Artifact], others are titled Create [Artifact], and lately Edit [Artifact]. Can we agree on one term and add it to the UI Best Practices? -Adrian
Re: fail-message
Hi Jacques, I saw that there are a few fail-message tag in use into the framework components so I have removed by myself. I have also closed jira issue OFBIZ-1874. Thank a lot for you availability. Marco Il giorno 22/dic/2010, alle ore 14.06, Jacques Le Roux ha scritto: OK, count me in Jacques From: mrisal...@libero.it Yes, Jacques I'm still working to remove fail-message tag from applications and specialpurpose components. If you want to help me to remove it from framework components I will appreciate it. Thanks Marco Messaggio originale Da: jacques.ler...@9business.fr Data: 22/12/2010 11.43 A: dev@ofbiz.apache.org Ogg: Re: lt;fail-messagegt; Thanks to Marco's courageous effort, I can remove soon this from my todo list. BTW, Marco I can help on the framework part, if you have nothing pending there yet... Thanks! Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com From: David E Jones jone...@hotwaxmedia.com Are we feeling a little domineering today? No actually I'm not domineering, simply exhausted. These 500+ changes certainly discouraged me, hence my reaction. I should keep cool, and I will... Just because internationalizing code is a best practice doesn't mean it's the ONLY practice, and I don't think we want to force it for any and all users of OFBiz (ie those writing their own applications, etc). That's the thing with best practices: we want them and we want to recommend them and for the main code base even ask people to follow them. We also want primary and secondary/other best practices. Still, not being omniscient we don't want to think we know everything and not have any flexibility in the framework. Yes I was re-thinking about it, and it occured to me that of course we should keep it and simply discourage its usage in OFBiz stock (yes, you contributors, commiters, ... :o) Jacques -David On Jul 12, 2008, at 2:10 PM, Jacques Le Roux wrote: Hi, I think we should deprecate, and at term remove the fail-message tag. There are 500+ ot them in current code. They are not localisable. So for me it's a bad practice, and we should prevent people to use this tag anymore. I can't see from the top of my head if there are some other aspects in OFBiz which encourage such bad practices (not localisable). What do you think ? Jacques
[jira] Closed: (OFBIZ-1874) Usage of the fail-message tag in OFBiz code base
[ https://issues.apache.org/jira/browse/OFBIZ-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti closed OFBIZ-1874. - Resolution: Fixed Fix Version/s: SVN trunk I have removed the use of fail-message tag from all the components so I close this issue. Marco Usage of the fail-message tag in OFBiz code base -- Key: OFBIZ-1874 URL: https://issues.apache.org/jira/browse/OFBIZ-1874 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Trivial Fix For: SVN trunk Currently there are 500+ ot them in current code. They are not localisable. So we should consider usage of *fail-message* tag a bad practice for OFBiz code base Commiters should not commit code with this tag but should use or ask for using *fail-property* instead -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Create/New Terminology Best Practice
...and even Create New [Artifact] !!! :-) My proposal is to use New [Artifact] everywhere. I faced the same issue with the create buttons. I changed many of them using the New [Artifact] pattern. This is why now I suggest to use the same for the title. Thank you, Bruno 2010/12/22 Adrian Crum adri...@hlmksw.com The OFBiz UI is very inconsistent in the terminology for creating something new - for example creating a new order, a new fixed asset, a new party, etc. Some screens are titled New [Artifact], others are titled Create [Artifact], and lately Edit [Artifact]. Can we agree on one term and add it to the UI Best Practices? -Adrian
[jira] Assigned: (OFBIZ-1874) Usage of the fail-message tag in OFBiz code base
[ https://issues.apache.org/jira/browse/OFBIZ-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-1874: -- Assignee: Marco Risaliti (was: Jacques Le Roux) Usage of the fail-message tag in OFBiz code base -- Key: OFBIZ-1874 URL: https://issues.apache.org/jira/browse/OFBIZ-1874 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Marco Risaliti Priority: Trivial Fix For: SVN trunk Currently there are 500+ ot them in current code. They are not localisable. So we should consider usage of *fail-message* tag a bad practice for OFBiz code base Commiters should not commit code with this tag but should use or ask for using *fail-property* instead -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: fail-message
Thanks Marco, You beat me on it Jacques From: Marco Risaliti risali...@gmail.com Hi Jacques, I saw that there are a few fail-message tag in use into the framework components so I have removed by myself. I have also closed jira issue OFBIZ-1874. Thank a lot for you availability. Marco Il giorno 22/dic/2010, alle ore 14.06, Jacques Le Roux ha scritto: OK, count me in Jacques From: mrisal...@libero.it Yes, Jacques I'm still working to remove fail-message tag from applications and specialpurpose components. If you want to help me to remove it from framework components I will appreciate it. Thanks Marco Messaggio originale Da: jacques.ler...@9business.fr Data: 22/12/2010 11.43 A: dev@ofbiz.apache.org Ogg: Re: lt;fail-messagegt; Thanks to Marco's courageous effort, I can remove soon this from my todo list. BTW, Marco I can help on the framework part, if you have nothing pending there yet... Thanks! Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com From: David E Jones jone...@hotwaxmedia.com Are we feeling a little domineering today? No actually I'm not domineering, simply exhausted. These 500+ changes certainly discouraged me, hence my reaction. I should keep cool, and I will... Just because internationalizing code is a best practice doesn't mean it's the ONLY practice, and I don't think we want to force it for any and all users of OFBiz (ie those writing their own applications, etc). That's the thing with best practices: we want them and we want to recommend them and for the main code base even ask people to follow them. We also want primary and secondary/other best practices. Still, not being omniscient we don't want to think we know everything and not have any flexibility in the framework. Yes I was re-thinking about it, and it occured to me that of course we should keep it and simply discourage its usage in OFBiz stock (yes, you contributors, commiters, ... :o) Jacques -David On Jul 12, 2008, at 2:10 PM, Jacques Le Roux wrote: Hi, I think we should deprecate, and at term remove the fail-message tag. There are 500+ ot them in current code. They are not localisable. So for me it's a bad practice, and we should prevent people to use this tag anymore. I can't see from the top of my head if there are some other aspects in OFBiz which encourage such bad practices (not localisable). What do you think ? Jacques
Re: Create/New Terminology Best Practice
from a UI point of view, New. from a programing point of view Create. I think how Edit got into it was,it assumes that there is already data, so on the edit page is a New link. Adrian Crum sent the following on 12/22/2010 11:03 AM: = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man The OFBiz UI is very inconsistent in the terminology for creating something new - for example creating a new order, a new fixed asset, a new party, etc. Some screens are titled New [Artifact], others are titled Create [Artifact], and lately Edit [Artifact]. Can we agree on one term and add it to the UI Best Practices? -Adrian
Re: Create/New Terminology Best Practice
I like Create New - it removes all ambiguity. -Adrian On 12/22/2010 12:48 PM, Bruno Busco wrote: ...and even Create New [Artifact] !!! :-) My proposal is to use New [Artifact] everywhere. I faced the same issue with the create buttons. I changed many of them using the New [Artifact] pattern. This is why now I suggest to use the same for the title. Thank you, Bruno 2010/12/22 Adrian Crumadri...@hlmksw.com The OFBiz UI is very inconsistent in the terminology for creating something new - for example creating a new order, a new fixed asset, a new party, etc. Some screens are titled New [Artifact], others are titled Create [Artifact], and lately Edit [Artifact]. Can we agree on one term and add it to the UI Best Practices? -Adrian
Re: fail-message
Marco, Thank you very much for working on this! -Adrian On 12/22/2010 12:00 PM, Marco Risaliti wrote: Hi Jacques, I saw that there are a few fail-message tag in use into the framework components so I have removed by myself. I have also closed jira issue OFBIZ-1874. Thank a lot for you availability. Marco Il giorno 22/dic/2010, alle ore 14.06, Jacques Le Roux ha scritto: OK, count me in Jacques From:mrisal...@libero.it Yes, Jacques I'm still working to remove fail-message tag from applications and specialpurpose components. If you want to help me to remove it from framework components I will appreciate it. Thanks Marco Messaggio originale Da: jacques.ler...@9business.fr Data: 22/12/2010 11.43 A:dev@ofbiz.apache.org Ogg: Re:lt;fail-messagegt; Thanks to Marco's courageous effort, I can remove soon this from my todo list. BTW, Marco I can help on the framework part, if you have nothing pending there yet... Thanks! Jacques From: Jacques Le Rouxjacques.le.r...@les7arts.com From: David E Jonesjone...@hotwaxmedia.com Are we feeling a little domineering today? No actually I'm not domineering, simply exhausted. These 500+ changes certainly discouraged me, hence my reaction. I should keep cool, and I will... Just because internationalizing code is a best practice doesn't mean it's the ONLY practice, and I don't think we want to force it for any and all users of OFBiz (ie those writing their own applications, etc). That's the thing with best practices: we want them and we want to recommend them and for the main code base even ask people to follow them. We also want primary and secondary/other best practices. Still, not being omniscient we don't want to think we know everything and not have any flexibility in the framework. Yes I was re-thinking about it, and it occured to me that of course we should keep it and simply discourage its usage in OFBiz stock (yes, you contributors, commiters, ... :o) Jacques -David On Jul 12, 2008, at 2:10 PM, Jacques Le Roux wrote: Hi, I think we should deprecate, and at term remove thefail-message tag. There are 500+ ot them in current code. They are not localisable. So for me it's a bad practice, and we should prevent people to use this tag anymore. I can't see from the top of my head if there are some other aspects in OFBiz which encourage such bad practices (not localisable). What do you think ? Jacques
Discussion: Move securityext component to framework
I have run into a HUGE obstacle in the process of moving security-related UI artifacts to the framework - they call services defined in applications/securityext. Indeed, they call ALL of the services defined in securityext. The securityext component depends on the entity and service components, so it needs to be loaded after those, but I can't see any reason why securityext needs to be in the applications folder. I think the securityext component should be in the framework folder. What do you think? -Adrian
Re: Discussion: Move securityext component to framework
Here's the history: http://svn.ofbiz.org/viewcvs?rev=4536view=rev If it no longer depends on party then I don't see an issue with moving it back. Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/12/2010, at 11:57 AM, Adrian Crum wrote: I have run into a HUGE obstacle in the process of moving security-related UI artifacts to the framework - they call services defined in applications/securityext. Indeed, they call ALL of the services defined in securityext. The securityext component depends on the entity and service components, so it needs to be loaded after those, but I can't see any reason why securityext needs to be in the applications folder. I think the securityext component should be in the framework folder. What do you think? -Adrian smime.p7s Description: S/MIME cryptographic signature
Re: Discussion: Move securityext component to framework
Okay, I just did a trial component move and securityext has some dependencies on components in the applications folder. Instead of moving securityext to the framework, I will just move all of the security-related services to the common component. -Adrian On 12/22/2010 2:57 PM, Adrian Crum wrote: I have run into a HUGE obstacle in the process of moving security-related UI artifacts to the framework - they call services defined in applications/securityext. Indeed, they call ALL of the services defined in securityext. The securityext component depends on the entity and service components, so it needs to be loaded after those, but I can't see any reason why securityext needs to be in the applications folder. I think the securityext component should be in the framework folder. What do you think? -Adrian
refactoring to frame work
I would like to see those parts taken from application to be in a folder in the Common with the same name as the application sort of like how products and facilities are called out it would sure make development easier when I forget about what was moved and where it is, even with the artifact tool. BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man
Re: Create/New Terminology Best Practice
Yes, but as BJ outlined beware of cases where the same screen is used to create and edit! Jacques From: Adrian Crum adri...@hlmksw.com I like Create New - it removes all ambiguity. -Adrian On 12/22/2010 12:48 PM, Bruno Busco wrote: ...and even Create New [Artifact] !!! :-) My proposal is to use New [Artifact] everywhere. I faced the same issue with the create buttons. I changed many of them using the New [Artifact] pattern. This is why now I suggest to use the same for the title. Thank you, Bruno 2010/12/22 Adrian Crumadri...@hlmksw.com The OFBiz UI is very inconsistent in the terminology for creating something new - for example creating a new order, a new fixed asset, a new party, etc. Some screens are titled New [Artifact], others are titled Create [Artifact], and lately Edit [Artifact]. Can we agree on one term and add it to the UI Best Practices? -Adrian
Re: refactoring to frame work
+1, also better to clearly state to which application it's related Jacques From: BJ Freeman bjf...@free-man.net I would like to see those parts taken from application to be in a folder in the Common with the same name as the application sort of like how products and facilities are called out it would sure make development easier when I forget about what was moved and where it is, even with the artifact tool. BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man
[jira] Assigned: (OFBIZ-4071) disable-if-empty is not working for menu item.
[ https://issues.apache.org/jira/browse/OFBIZ-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-4071: - Assignee: Scott Gray disable-if-empty is not working for menu item. -- Key: OFBIZ-4071 URL: https://issues.apache.org/jira/browse/OFBIZ-4071 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 10.04, SVN trunk Reporter: Deepak Dixit Assignee: Scott Gray Priority: Minor Fix For: Release Branch 10.04, SVN trunk Attachments: OFBIZ-4071.patch There is an disable-if-empty tag available for menu-item tag to display menu item. But it does not working. If we use disable-if-empty attribute then menu item does not disable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
