[jira] Commented: (OFBIZ-1716) POS: CVV2 code is not always deleted from the DB
[ https://issues.apache.org/jira/browse/OFBIZ-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608293#action_12608293 ] Jacques Le Roux commented on OFBIZ-1716: Hi Chris, What is the status of this patch, now ? Thanks POS: CVV2 code is not always deleted from the DB Key: OFBIZ-1716 URL: https://issues.apache.org/jira/browse/OFBIZ-1716 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk, Release Branch 4.0 Reporter: Chris Lombardi Assignee: Jacques Le Roux Priority: Critical Attachments: ofbiz-1716.patch I ran a transaction that was declined by the processor. I later noticed that the cvv2 code was still present in the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to use Display in POS
Hello developers, I need to use the price display (a Seperate Display Device which is used to display the total price to the customer at the time of checking out.) with the POS, for this, i need to show the price on that when the product is scanned by the store clerk. How that can be achieved?? Any kind of related help / Idea will be appreciated. Thank beforehand. o Ajay Sodhi Pal InfoCom Technologies. Mohali (India) Portland (USA)
Re: How to use Display in POS
This is often called a Line Display. As you can see in pos-containers.xml, it's not yet implemente in POS property name=LineDisplay value=[NOT IMPLEMENTED]/ So check specialpurpose/pos/src/org/ofbiz/pos/device/impl/LineDisplay.java But please use rather user ML for such questions : http://docs.ofbiz.org/display/OFBADMIN/Mailing+Lists#MailingLists-DeveloperList:dev@ofbiz.apache.org Thanks Jacques From: [EMAIL PROTECTED] Hello developers, I need to use the price display (a Seperate Display Device which is used to display the total price to the customer at the time of checking out.) with the POS, for this, i need to show the price on that when the product is scanned by the store clerk. How that can be achieved?? Any kind of related help / Idea will be appreciated. Thank beforehand. o Ajay Sodhi Pal InfoCom Technologies. Mohali (India) Portland (USA)
Re: Question About Fixed Assets
Done : http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-Developmenttips Which leads to http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities Jacques From: Jacques Le Roux [EMAIL PROTECTED] From: David E Jones [EMAIL PROTECTED] [...big snip...] BTW, whenever we deprecate an entity in OFBiz there are certain things that now MUST be done or all committers should reject the patch: 1. rename the entity to deprecate by adding an Old prefix to it, then specify a table-name attribute on the entity so it still points to the same table in the database 2. create a new entity the replaces the old one, and comment on that fact 3. implement a service to move data from the old/deprecated entity to the new one You'll see this pattern used in a few places. This is kind of the way that users in general have some sort of hope of being able to update from one revision of OFBiz to another. -David I will at least put these very important informations in the FAQ. But finally should not those kind of stuff being put in our Best Practices ? Jacques
Re: Freemarker deprecated built-ins
I did it locally, but I wonder now if it's a good idea since ?exists and ?if_exists are more readable than ?? and ! ?exists and ?if_exists still work and and only ! is bringing some more features (mostly dealing with false also). If we don't do it now, maybe in a future we will have to do it. It's a 10 min work anyway... I think that as soon as you are used to them (I mean ?? and !) it's not a big deal, but please express yourself Thanks Jacques From: Vikas Mayur [EMAIL PROTECTED] +1 Vikas On Mon, Jun 23, 2008 at 10:56 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: Hi All, Why do you think about updating all our templates following http://freemarker.sourceforge.net/docs/ref_depr_builtin.html ? At least the second and the third could be done automatically. Jacques
Re: Freemarker deprecated built-ins
I just noticed that Freemarker 2.4 is not yet available http://freemarker.sourceforge.net/freemarkerdownload.html It's not needed for the 1st builtin replacement but we should preferably use this version as explained in the link below. We may wait for 2.4 to do this one... BTW there is a new Eclipse Freemarker plugin from RedHat/JBoss IDE : http://www.jboss.org/tools/download/index.html (i used the http://download.jboss.org/jbosstools/updates/stable link) Jacques From: Jacques Le Roux [EMAIL PROTECTED] I did it locally, but I wonder now if it's a good idea since ?exists and ?if_exists are more readable than ?? and ! ?exists and ?if_exists still work and and only ! is bringing some more features (mostly dealing with false also). If we don't do it now, maybe in a future we will have to do it. It's a 10 min work anyway... I think that as soon as you are used to them (I mean ?? and !) it's not a big deal, but please express yourself Thanks Jacques From: Vikas Mayur [EMAIL PROTECTED] +1 Vikas On Mon, Jun 23, 2008 at 10:56 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: Hi All, Why do you think about updating all our templates following http://freemarker.sourceforge.net/docs/ref_depr_builtin.html ? At least the second and the third could be done automatically. Jacques
Re: Wish list for features in the upcoming framework release
+1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework-candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
Re: Freemarker deprecated built-ins
I am also using the Freemarker plugin distributed by Jboss. Its working fine for me. -- Ashish On Thu, Jun 26, 2008 at 5:06 AM, Jacques Le Roux [EMAIL PROTECTED] wrote: I just noticed that Freemarker 2.4 is not yet available http://freemarker.sourceforge.net/freemarkerdownload.html It's not needed for the 1st builtin replacement but we should preferably use this version as explained in the link below. We may wait for 2.4 to do this one... BTW there is a new Eclipse Freemarker plugin from RedHat/JBoss IDE : http://www.jboss.org/tools/download/index.html (i used the http://download.jboss.org/jbosstools/updates/stable link) Jacques From: Jacques Le Roux [EMAIL PROTECTED] I did it locally, but I wonder now if it's a good idea since ?exists and ?if_exists are more readable than ?? and ! ?exists and ?if_exists still work and and only ! is bringing some more features (mostly dealing with false also). If we don't do it now, maybe in a future we will have to do it. It's a 10 min work anyway... I think that as soon as you are used to them (I mean ?? and !) it's not a big deal, but please express yourself Thanks Jacques From: Vikas Mayur [EMAIL PROTECTED] +1 Vikas On Mon, Jun 23, 2008 at 10:56 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: Hi All, Why do you think about updating all our templates following http://freemarker.sourceforge.net/docs/ref_depr_builtin.html ? At least the second and the third could be done automatically. Jacques
Re: Freemarker deprecated built-ins
From: Jacques Le Roux [EMAIL PROTECTED] I just noticed that Freemarker 2.4 is not yet available http://freemarker.sourceforge.net/freemarkerdownload.html It's not needed for the 1st builtin replacement but we should preferably use this version as explained in the link below. We may wait for 2.4 to do this one... Ooops, this remark makes no sense forget it. I understood Freemarker explanation the wrong side. Actually the deprecated ?default builtin will behave better in future. Those guys are serious : they enhance deprecated builtins ;o) Jacques BTW there is a new Eclipse Freemarker plugin from RedHat/JBoss IDE : http://www.jboss.org/tools/download/index.html (i used the http://download.jboss.org/jbosstools/updates/stable link) Jacques From: Jacques Le Roux [EMAIL PROTECTED] I did it locally, but I wonder now if it's a good idea since ?exists and ?if_exists are more readable than ?? and ! ?exists and ?if_exists still work and and only ! is bringing some more features (mostly dealing with false also). If we don't do it now, maybe in a future we will have to do it. It's a 10 min work anyway... I think that as soon as you are used to them (I mean ?? and !) it's not a big deal, but please express yourself Thanks Jacques From: Vikas Mayur [EMAIL PROTECTED] +1 Vikas On Mon, Jun 23, 2008 at 10:56 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: Hi All, Why do you think about updating all our templates following http://freemarker.sourceforge.net/docs/ref_depr_builtin.html ? At least the second and the third could be done automatically. Jacques
Re: Wish list for features in the upcoming framework release
What if we just add a call-script/ element instead? We could then replace all the call-bsh / element to the new one. The new one will use the file suffix to use the proper Processor (.groovy, .bsh etc...) And we may add an optional parameter for the type (groovy, bsh etc... that can be used if the script files don't have the right suffix). For example call-script location=component://pathtoscript/myscript.groovy/ call-script location=component://pathtoscript/myscript.bsh/ call-script location=component://pathtoscript/mygroovyscript.grv type=groovy/ Jacopo On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote: +1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework-candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
Re: Wish list for features in the upcoming framework release
Jacopo I liked the idea while we include the script file in Screen Definition. But if you will notice Jacques was talking about the Mini Lang call-bsh replacement to call-groovy. Please let me know your thoughts in reference to Mini Lang. Thanks ! -- Ashish On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: What if we just add a call-script/ element instead? We could then replace all the call-bsh / element to the new one. The new one will use the file suffix to use the proper Processor (.groovy, .bsh etc...) And we may add an optional parameter for the type (groovy, bsh etc... that can be used if the script files don't have the right suffix). For example call-script location=component://pathtoscript/myscript.groovy/ call-script location=component://pathtoscript/myscript.bsh/ call-script location=component://pathtoscript/mygroovyscript.grv type=groovy/ Jacopo On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote: +1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework-candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
Re: Wish list for features in the upcoming framework release
Ashish, yes, what I meant that we could implement the new Minilang operation: call-script That operation could then be used to replace the existing call-bsh operation (that could be deprecated) and also it will be used to call Groovy scripts. Jacopo On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote: Jacopo I liked the idea while we include the script file in Screen Definition. But if you will notice Jacques was talking about the Mini Lang call- bsh replacement to call-groovy. Please let me know your thoughts in reference to Mini Lang. Thanks ! -- Ashish On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: What if we just add a call-script/ element instead? We could then replace all the call-bsh / element to the new one. The new one will use the file suffix to use the proper Processor (.groovy, .bsh etc...) And we may add an optional parameter for the type (groovy, bsh etc... that can be used if the script files don't have the right suffix). For example call-script location=component://pathtoscript/myscript.groovy/ call-script location=component://pathtoscript/myscript.bsh/ call-script location=component://pathtoscript/mygroovyscript.grv type=groovy/ Jacopo On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote: +1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework- candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
Re: Wish list for features in the upcoming framework release
Jacopo, Thanks for the clarification. Let's see what other's has to say about it. -- Ashish On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: Ashish, yes, what I meant that we could implement the new Minilang operation: call-script That operation could then be used to replace the existing call-bsh operation (that could be deprecated) and also it will be used to call Groovy scripts. Jacopo On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote: Jacopo I liked the idea while we include the script file in Screen Definition. But if you will notice Jacques was talking about the Mini Lang call-bsh replacement to call-groovy. Please let me know your thoughts in reference to Mini Lang. Thanks ! -- Ashish On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: What if we just add a call-script/ element instead? We could then replace all the call-bsh / element to the new one. The new one will use the file suffix to use the proper Processor (.groovy, .bsh etc...) And we may add an optional parameter for the type (groovy, bsh etc... that can be used if the script files don't have the right suffix). For example call-script location=component://pathtoscript/myscript.groovy/ call-script location=component://pathtoscript/myscript.bsh/ call-script location=component://pathtoscript/mygroovyscript.grv type=groovy/ Jacopo On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote: +1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework-candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
[jira] Updated: (OFBIZ-1852) Enhancement in ProjectMgr and WorkEffort component
[ https://issues.apache.org/jira/browse/OFBIZ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsha Chadhar updated OFBIZ-1852: -- Attachment: ProjectMgr.patch 1.Created Entity WorkEffortHistory. 2.Added PartyId to the FindProject Screen to search the projects associated with the Parties(Clients or Members).The Entity now used to search the records has been replaced to WorkEffortPartyAssignment. 3.Added PartyId,RoleTypeId,StatusId etc that display the Project and their associated Resources(Parties that could be of RoleType Client or Members involved) to the ListProjects. 4.The ProjectView now displays the list of Client Personnel and Members Involved(Resources) seperatly with a link to view their profile. Enhancement in ProjectMgr and WorkEffort component -- Key: OFBIZ-1852 URL: https://issues.apache.org/jira/browse/OFBIZ-1852 Project: OFBiz Issue Type: Improvement Components: specialpurpose/projectmgr Reporter: Ashish Vijaywargiya Assignee: Ashish Vijaywargiya Priority: Trivial Attachments: ProjectMgr.patch Original Estimate: 6h Remaining Estimate: 6h 1) Update the FindProject screen to use WorkEffortAndPartyAssignment entity instead of WorkEffort to display the associated party(that can be a client) list with the Project (aka WorkEffort). Add a Text Field by heading Party Id and put the search party lookup for it. Also add the Party Id field in the list displayed at the bottom. Party Id can be used to display resources i.e it can be either Client or Member who is assigned to work on the Project. 2) Add New Entity WorkEffortHistory. Reason :- When we update the Status of workeffort then in case of Hold and Cancel the reason should be specified. We can put the Reason into Description field.And the description associated with status can be maintained in WorkEffortHistory entity. We didn't find WorkEffortNote entity useful for this purpose. 3) From Project Summary Screen :- Divide the Resource screen into two parts :- 1) Member Involved 2) Client Personnel This will provide easy way of handling resources to navigate from the Project Summary Screen. -- Ashish Ratnesh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Wish list for features in the upcoming framework release
I like the idea for simple-method. One thing to keep in mind is that many scripts are included in-line under the current call-bsh tag rather than referred to as a file, so we'll have to have the type attribute that was mentioned, and we should probably have it default to groovy (and also support bsh or something). BTW, on a related note, I do NOT like the idea of supporting scripts in-line in a screen's action area. It would clutter the screen definition making it harder to read and maintain, and it would limit reusability of the scripts. -David On Jun 26, 2008, at 5:49 AM, Ashish Vijaywargiya wrote: Jacopo, Thanks for the clarification. Let's see what other's has to say about it. -- Ashish On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: Ashish, yes, what I meant that we could implement the new Minilang operation: call-script That operation could then be used to replace the existing call-bsh operation (that could be deprecated) and also it will be used to call Groovy scripts. Jacopo On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote: Jacopo I liked the idea while we include the script file in Screen Definition. But if you will notice Jacques was talking about the Mini Lang call-bsh replacement to call-groovy. Please let me know your thoughts in reference to Mini Lang. Thanks ! -- Ashish On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: What if we just add a call-script/ element instead? We could then replace all the call-bsh / element to the new one. The new one will use the file suffix to use the proper Processor (.groovy, .bsh etc...) And we may add an optional parameter for the type (groovy, bsh etc... that can be used if the script files don't have the right suffix). For example call-script location=component://pathtoscript/myscript.groovy/ call-script location=component://pathtoscript/myscript.bsh/ call-script location=component://pathtoscript/mygroovyscript.grv type=groovy/ Jacopo On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote: +1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework- candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
Re: Question About Fixed Assets
Thanks Jacques. I could have sworn we had this documented somewhere, but I really don't remember where... -David On Jun 26, 2008, at 2:29 AM, Jacques Le Roux wrote: Done : http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-Developmenttips Which leads to http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities Jacques From: Jacques Le Roux [EMAIL PROTECTED] From: David E Jones [EMAIL PROTECTED] [...big snip...] BTW, whenever we deprecate an entity in OFBiz there are certain things that now MUST be done or all committers should reject the patch: 1. rename the entity to deprecate by adding an Old prefix to it, then specify a table-name attribute on the entity so it still points to the same table in the database 2. create a new entity the replaces the old one, and comment on that fact 3. implement a service to move data from the old/deprecated entity to the new one You'll see this pattern used in a few places. This is kind of the way that users in general have some sort of hope of being able to update from one revision of OFBiz to another. -David I will at least put these very important informations in the FAQ. But finally should not those kind of stuff being put in our Best Practices ? Jacques
[jira] Created: (OFBIZ-1853) Successful TCP / Ethernet Epson printer implementation
Successful TCP / Ethernet Epson printer implementation -- Key: OFBIZ-1853 URL: https://issues.apache.org/jira/browse/OFBIZ-1853 Project: OFBiz Issue Type: New Feature Components: specialpurpose/pos Affects Versions: SVN trunk Environment: Epson TM-T88IV, With correct Ethernet module for back (replacing the Serial port), Epson ADK 1.9, Epson TMNet WINconfig, Reporter: Branden Strickland Priority: Minor Fix For: SVN trunk 1) First, replace the modules in back of the printer 2) While the printer is unplugged from power, you must change the reset dip-switch (2-7) from off to on. 3) Power on the printer, and plug it into the network. 4) As per the UB-E02 Technical Reference Guide. (get it, you'll need it) use the switch button on the Ethernet module to set the ROM back to factory defaults. This will also print a settings page afterward, and let you know the subnet / ip address that you'll need to know to configure the printer. 5) Use the Epson TMNet WINconfig utility on a Windows box (sorry! there is NO linux utility!) Set the PC on the same subnet, and set your gateway as the default IP address of the printer. 6) Change the settings of the printer (once connected) to suite your environment. 7) Add the printer to Epson JavaPOS with SetupPOS.sh using the IP address and info that you set previously. 8) Test with CheckHealth 9) Add printer to pos-containers. 10) start and test OFBIZ...You will receive the error at the bottom of the page. I think it's from something in the deviceloader that is able to check through serial and not though Ethernet! Nothing I wanted to fiddle with though, It works just fine and fast! FYIDO NOT use a passthrough drawer on Ethernet printers, or customer displays. It mentioned this several times in all of the technical guides. exception report -- Exception: jpos.JposException Message: The power supply of the device is off. stack trace --- jpos.JposException: The power supply of the device is off. jp.co.epson.upos.pntr.init.AbstractPrinterInitialization.getRealtimeStatus(Unknown Source) jp.co.epson.upos.pntr.init.AbstractPrinterInitialization.getPrinterStatus(Unknown Source) jp.co.epson.upos.pntr.init.AbstractPrinterInitialization.getPrinterStatus(Unknown Source) jp.co.epson.upos.pntr.init.AbstractPrinterInitialization.initializeCommon(Unknown Source) jp.co.epson.upos.pntr.init.AbstractPrinterInitialization.initialize(Unknown Source) jp.co.epson.upos.pntr.init.AbstractPrinterInitialization.initializeDevice(Unknown Source) jp.co.epson.upos.drw.CashDrawerPortControl.initializePrinterInstance(Unknown Source) jp.co.epson.upos.drw.CashDrawerPortControl.openPort(Unknown Source) jp.co.epson.upos.drw.CommonCashDrawerService.setDeviceEnabled(Unknown Source) jpos.BaseJposControl.setDeviceEnabled(Unknown Source) org.ofbiz.pos.device.GenericDevice.enable(GenericDevice.java:71) org.ofbiz.pos.device.GenericDevice.open(GenericDevice.java:46) org.ofbiz.pos.device.DeviceLoader.load(DeviceLoader.java:165) org.ofbiz.pos.container.JposDeviceContainer.start(JposDeviceContainer.java:50) org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:101) org.ofbiz.base.start.Start.startStartLoaders(Start.java:263) org.ofbiz.base.start.Start.startServer(Start.java:312) org.ofbiz.base.start.Start.start(Start.java:316) org.ofbiz.base.start.Start.main(Start.java:399) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1716) POS: CVV2 code is not always deleted from the DB
[ https://issues.apache.org/jira/browse/OFBIZ-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608446#action_12608446 ] Chris Lombardi commented on OFBIZ-1716: --- I don't remember. The patch looks pretty straight forward though, I'll test it today. POS: CVV2 code is not always deleted from the DB Key: OFBIZ-1716 URL: https://issues.apache.org/jira/browse/OFBIZ-1716 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk, Release Branch 4.0 Reporter: Chris Lombardi Assignee: Jacques Le Roux Priority: Critical Attachments: ofbiz-1716.patch I ran a transaction that was declined by the processor. I later noticed that the cvv2 code was still present in the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Wish list for features in the upcoming framework release
On Jun 26, 2008, at 4:03 PM, David E Jones wrote: I like the idea for simple-method. One thing to keep in mind is that many scripts are included in-line under the current call-bsh tag rather than referred to as a file, so we'll have to have the type attribute that was mentioned, and we should probably have it default to groovy (and also support bsh or something). David, thanks for bringing this to our attention. This is a really good point. BTW, on a related note, I do NOT like the idea of supporting scripts in-line in a screen's action area. It would clutter the screen definition making it harder to read and maintain, and it would limit reusability of the scripts. Yes, I agree... I don't think anyone is working on this right now :-) Jacopo -David On Jun 26, 2008, at 5:49 AM, Ashish Vijaywargiya wrote: Jacopo, Thanks for the clarification. Let's see what other's has to say about it. -- Ashish On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: Ashish, yes, what I meant that we could implement the new Minilang operation: call-script That operation could then be used to replace the existing call-bsh operation (that could be deprecated) and also it will be used to call Groovy scripts. Jacopo On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote: Jacopo I liked the idea while we include the script file in Screen Definition. But if you will notice Jacques was talking about the Mini Lang call-bsh replacement to call-groovy. Please let me know your thoughts in reference to Mini Lang. Thanks ! -- Ashish On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato [EMAIL PROTECTED] wrote: What if we just add a call-script/ element instead? We could then replace all the call-bsh / element to the new one. The new one will use the file suffix to use the proper Processor (.groovy, .bsh etc...) And we may add an optional parameter for the type (groovy, bsh etc... that can be used if the script files don't have the right suffix). For example call-script location=component://pathtoscript/myscript.groovy/ call-script location=component://pathtoscript/myscript.bsh/ call-script location=component://pathtoscript/ mygroovyscript.grv type=groovy/ Jacopo On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote: +1 for adding call-groovy in minilang. I can work on it in my free time as voluntarily if we would like to include it in framework release. Please let me know your thoughts on it. -- Ashish On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux [EMAIL PROTECTED] wrote: +1 for Confluence BTW, should we not add a call-groovy in minilang (or did I miss something) ? Jacques From: David E Jones [EMAIL PROTECTED] Like Jacopo hinted at, this is a community-driven effort and is therefore a bit chaotic. The main thing I was requesting from the community is to focus on the framework for a little while so we can stabilize and clean up the framework in preparation for a binary release of it (leading toward a good binary release of the whole project... but starting with something smaller and easier). Anyway, I do have a list of things I've been thinking about and collecting, some from years ago. What I want to avoid though is making my list the official list, or even any sort of majority of the official list. In other words, I want this to be a community effort more than I want to have everything on my pet list done. Still, I do like the idea of starting to compile a list of things we'd all like to see go into the framework, and it's probably about time to do that rather than having more random (less communicated) efforts on different things. I'm thinking that a confluence/wiki page might be a better place for now though, given the tentative nature of some of these things, and often a need for discussion before more concrete plans are made. What do others think of this? -David On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework- candidate- release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so
Re: Wish list for features in the upcoming framework release
Was anything done with this? Do we have a Jira issue or Wiki page? -Adrian Jacopo Cappellato wrote: I think that Bruno's suggestion of creating a framework-candidate-release-x version in Jira would be useful, especially because there is no official (or even unofficial) list of features/fixes to go in the framework... probably each of us has its own preferences. Of course we should try to keep the list small. Jacopo On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote: David, I think it will be beneficial to all contributors to have a list of what we would like to have included in the framework-only release, don't you? It will tell how far we are and to have, generally, more efforts on these tasks. Why don't define the framework-only version in JIRA and schedule for that the task-list ? Thank you, -Bruno 2008/6/20 David E Jones [EMAIL PROTECTED]: This looks good Adrian, thanks for working on it. This was on my own little list of things I'd like to see added to the framework before we do the framework-only release, so I'm really happy to see it in! -David
[jira] Commented: (OFBIZ-1852) Enhancement in ProjectMgr and WorkEffort component
[ https://issues.apache.org/jira/browse/OFBIZ-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608459#action_12608459 ] Ashish Vijaywargiya commented on OFBIZ-1852: David, Thanks for your comment. I will look at the WorkEffortStatus table tomorrow and try to find the way from it. Somehow I missed that entity so sorry for that. -- Ashish Enhancement in ProjectMgr and WorkEffort component -- Key: OFBIZ-1852 URL: https://issues.apache.org/jira/browse/OFBIZ-1852 Project: OFBiz Issue Type: Improvement Components: specialpurpose/projectmgr Reporter: Ashish Vijaywargiya Assignee: Ashish Vijaywargiya Priority: Trivial Attachments: ProjectMgr.patch Original Estimate: 6h Remaining Estimate: 6h 1) Update the FindProject screen to use WorkEffortAndPartyAssignment entity instead of WorkEffort to display the associated party(that can be a client) list with the Project (aka WorkEffort). Add a Text Field by heading Party Id and put the search party lookup for it. Also add the Party Id field in the list displayed at the bottom. Party Id can be used to display resources i.e it can be either Client or Member who is assigned to work on the Project. 2) Add New Entity WorkEffortHistory. Reason :- When we update the Status of workeffort then in case of Hold and Cancel the reason should be specified. We can put the Reason into Description field.And the description associated with status can be maintained in WorkEffortHistory entity. We didn't find WorkEffortNote entity useful for this purpose. 3) From Project Summary Screen :- Divide the Resource screen into two parts :- 1) Member Involved 2) Client Personnel This will provide easy way of handling resources to navigate from the Project Summary Screen. -- Ashish Ratnesh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1851) Sandbox: Fixed Asset Meter Reading Improvement
[ https://issues.apache.org/jira/browse/OFBIZ-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated OFBIZ-1851: --- Attachment: meter_reading.patch Improved meter_reading.patch file - now includes David's suggestions. I don't know how to set up an automatic service to move data from the old entity to the new one. If anyone could point me in the right direction it would be greatly appreciated! Sandbox: Fixed Asset Meter Reading Improvement -- Key: OFBIZ-1851 URL: https://issues.apache.org/jira/browse/OFBIZ-1851 Project: OFBiz Issue Type: Improvement Components: accounting Reporter: Adrian Crum Priority: Minor Attachments: meter_reading.patch, meter_reading.patch The current fixed asset meter reading logic is set up to only allow a meter reading when a fixed asset maintenance is created. This improvement would remove that requirement and make the connection to a maintenance optional. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
User Interaction for Background Form submit.
Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-1851) Sandbox: Fixed Asset Meter Reading Improvement
[ https://issues.apache.org/jira/browse/OFBIZ-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608577#action_12608577 ] Anil K Patel commented on OFBIZ-1851: - yes there is UI for it in Product screen set. Regards Anil Patel Sandbox: Fixed Asset Meter Reading Improvement -- Key: OFBIZ-1851 URL: https://issues.apache.org/jira/browse/OFBIZ-1851 Project: OFBiz Issue Type: Improvement Components: accounting Reporter: Adrian Crum Priority: Minor Attachments: meter_reading.patch, meter_reading.patch The current fixed asset meter reading logic is set up to only allow a meter reading when a fixed asset maintenance is created. This improvement would remove that requirement and make the connection to a maintenance optional. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: User Interaction for Background Form submit.
Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel
Asset Maintenance Idea
Now that it's clear to me that the ProductMaint entity is intended to be used as a type of template for recurring fixed asset maintenances, I'd like to add a data entry screen to the Asset Maintenance component for ProductMaint. I was thinking it would be more understandable for someone in the maintenance role to call it a Fixed Asset Maintenance Template. In other words, the ProductMaint entity would be used, but it would be called a Fixed Asset Maintenance Template in the UI. Also, to keep things simple for the users of Asset Maintenance, if the fixed asset isn't already connected to a product and a ProductMaint is created for it, would it be okay to create a Product record on the fly? What do you think? -Adrian
Re: User Interaction for Background Form submit.
Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel
Re: User Interaction for Background Form submit.
Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event-update- area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event- update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel smime.p7s Description: S/MIME cryptographic signature
Re: User Interaction for Background Form submit.
I don't how on-event-update-area event-type=submit is harder to understand than on-submit, but then maybe I'm smarter than the average developer. ;-) If you want to have different elements for different events, that's fine. I just see a lot of overlap down the road. By the way, the Ajax Example is broken. The Status dropdown doesn't work anymore, and it looks like the on-event-update-area element for the form refresh was removed. -Adrian Anil Patel wrote: Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event-update-area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel
Re: User Interaction for Background Form submit.
Adrian, I am sorry, Its ok to update form section on form submit and should not use form reset in javascript. I'll modify that part to back where it was. But then the problem is, I'll have to add code in update area part of javascript to execute any javascript block inside of new html loaded. Regards Anil Patel On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: I don't how on-event-update-area event-type=submit is harder to understand than on-submit, but then maybe I'm smarter than the average developer. ;-) I Agree that its true. If you want to have different elements for different events, that's fine. I just see a lot of overlap down the road. By the way, the Ajax Example is broken. The Status dropdown doesn't work anymore, and it looks like the on-event-update-area element for the form refresh was removed. I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. The Status drop down is now using Autocompleter dropdown. I'll check it for problems it might have. -Adrian Anil Patel wrote: Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event- update-area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on- event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel smime.p7s Description: S/MIME cryptographic signature
Re: User Interaction for Background Form submit.
Anil Patel wrote: I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. But doesn't that way of doing things conflict with the ideas you are presenting now? The original code called an Ajax event to refresh the data entry form. You changed it so the form refresh is hard-coded in JavaScript. What if you don't want the form refreshed after submit but instead want to use one of the responses that you mentioned in your list? -Adrian
Re: User Interaction for Background Form submit.
If you can get the form refresh back the way it was, and show me the difficulty you were having with JavaScript, then I'll try to help figure it out. -Adrian Anil Patel wrote: Adrian, I am sorry, Its ok to update form section on form submit and should not use form reset in javascript. I'll modify that part to back where it was. But then the problem is, I'll have to add code in update area part of javascript to execute any javascript block inside of new html loaded. Regards Anil Patel On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: I don't how on-event-update-area event-type=submit is harder to understand than on-submit, but then maybe I'm smarter than the average developer. ;-) I Agree that its true. If you want to have different elements for different events, that's fine. I just see a lot of overlap down the road. By the way, the Ajax Example is broken. The Status dropdown doesn't work anymore, and it looks like the on-event-update-area element for the form refresh was removed. I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. The Status drop down is now using Autocompleter dropdown. I'll check it for problems it might have. -Adrian Anil Patel wrote: Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event-update-area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel
Re: User Interaction for Background Form submit.
I'll get back the needed code soon. Regards Anil Patel On Jun 26, 2008, at 5:55 PM, Adrian Crum wrote: If you can get the form refresh back the way it was, and show me the difficulty you were having with JavaScript, then I'll try to help figure it out. -Adrian Anil Patel wrote: Adrian, I am sorry, Its ok to update form section on form submit and should not use form reset in javascript. I'll modify that part to back where it was. But then the problem is, I'll have to add code in update area part of javascript to execute any javascript block inside of new html loaded. Regards Anil Patel On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: I don't how on-event-update-area event-type=submit is harder to understand than on-submit, but then maybe I'm smarter than the average developer. ;-) I Agree that its true. If you want to have different elements for different events, that's fine. I just see a lot of overlap down the road. By the way, the Ajax Example is broken. The Status dropdown doesn't work anymore, and it looks like the on-event-update- area element for the form refresh was removed. I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. The Status drop down is now using Autocompleter dropdown. I'll check it for problems it might have. -Adrian Anil Patel wrote: Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event- update-area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel smime.p7s Description: S/MIME cryptographic signature
Re: User Interaction for Background Form submit.
Adrian, The Ajax.Updater that is used for updating section of screen on event take third parameters options. I don't see a way to pass values for this parameters form on-event-update-area, Do you know how I can do that. I want to be able to set evalScript options to true. Regards Anil Patel On Jun 26, 2008, at 6:00 PM, Anil Patel wrote: I'll get back the needed code soon. Regards Anil Patel On Jun 26, 2008, at 5:55 PM, Adrian Crum wrote: If you can get the form refresh back the way it was, and show me the difficulty you were having with JavaScript, then I'll try to help figure it out. -Adrian Anil Patel wrote: Adrian, I am sorry, Its ok to update form section on form submit and should not use form reset in javascript. I'll modify that part to back where it was. But then the problem is, I'll have to add code in update area part of javascript to execute any javascript block inside of new html loaded. Regards Anil Patel On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: I don't how on-event-update-area event-type=submit is harder to understand than on-submit, but then maybe I'm smarter than the average developer. ;-) I Agree that its true. If you want to have different elements for different events, that's fine. I just see a lot of overlap down the road. By the way, the Ajax Example is broken. The Status dropdown doesn't work anymore, and it looks like the on-event-update- area element for the form refresh was removed. I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. The Status drop down is now using Autocompleter dropdown. I'll check it for problems it might have. -Adrian Anil Patel wrote: Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event- update-area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel smime.p7s Description: S/MIME cryptographic signature
Re: User Interaction for Background Form submit.
Just set it true in selectall.js - it should be the default for our purposes anyway. -Adrian Anil Patel wrote: Adrian, The Ajax.Updater that is used for updating section of screen on event take third parameters options. I don't see a way to pass values for this parameters form on-event-update-area, Do you know how I can do that. I want to be able to set evalScript options to true. Regards Anil Patel On Jun 26, 2008, at 6:00 PM, Anil Patel wrote: I'll get back the needed code soon. Regards Anil Patel On Jun 26, 2008, at 5:55 PM, Adrian Crum wrote: If you can get the form refresh back the way it was, and show me the difficulty you were having with JavaScript, then I'll try to help figure it out. -Adrian Anil Patel wrote: Adrian, I am sorry, Its ok to update form section on form submit and should not use form reset in javascript. I'll modify that part to back where it was. But then the problem is, I'll have to add code in update area part of javascript to execute any javascript block inside of new html loaded. Regards Anil Patel On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: I don't how on-event-update-area event-type=submit is harder to understand than on-submit, but then maybe I'm smarter than the average developer. ;-) I Agree that its true. If you want to have different elements for different events, that's fine. I just see a lot of overlap down the road. By the way, the Ajax Example is broken. The Status dropdown doesn't work anymore, and it looks like the on-event-update-area element for the form refresh was removed. I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. The Status drop down is now using Autocompleter dropdown. I'll check it for problems it might have. -Adrian Anil Patel wrote: Then I'll rather add element on-submit that tells me exactly that what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is on-event-update-area adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: Your list of ideas all revolve around a form submit. So just like in the Example component, you can have different responses to the event. For example, if you want a form changed to read-only after a submit, use the on-event-update-area element and use a target that returns a read-only form. -Adrian Anil Patel wrote: Adrian, To me on-event-update-area is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its SUBMIT. To me on-event-update-area is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: Anil, Many thanks for your continuing work on the Ajax stuff! Why wouldn't the existing on-event-update-area element handle these requirements? What you are describing are different responses to the event, not different events. -Adrian Anil Patel wrote: Hi, We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel
Latitude, Longitude in PostalAdress
Hi, I will need to add Latitude and Longitude fields in PostalAdress. Could this be a change commited ? I will also need to add a type PHONE_HOTLINE in ContactMechPurposeType. Else, of course I will use extend-entity Thanks Jacques
[jira] Updated: (OFBIZ-1716) POS: CVV2 code is not always deleted from the DB
[ https://issues.apache.org/jira/browse/OFBIZ-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lombardi updated OFBIZ-1716: -- Attachment: ofbiz-1716.patch Updated patch to work with current trunk. Tested, works ok. POS: CVV2 code is not always deleted from the DB Key: OFBIZ-1716 URL: https://issues.apache.org/jira/browse/OFBIZ-1716 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk, Release Branch 4.0 Reporter: Chris Lombardi Assignee: Jacques Le Roux Priority: Critical Attachments: ofbiz-1716.patch, ofbiz-1716.patch I ran a transaction that was declined by the processor. I later noticed that the cvv2 code was still present in the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
