Re: Date format changing to dd-mm-yyyy
Adrian Crum wrote: > > UtilDateTime.java would need to be modified. The static date/time format > string would need to be loaded from a properties file. > > -Adrian > > Jacques Le Roux wrote: >> This does not exist yet OOTB. Though I think I remember Adrian began >> some effort around. Not quite sure, you may may have a look using >> MarkMail or Nabble. >> >> Jacques >> >> From: "naveen chanda" >>> >>> Dear Pradeep, >>> >>> Thank you very much. >>> >>> But, when it is the forms, than how can i proceed it. >>> >>> When we select the calendar, i have changed the format to display but >>> when i >>> use the update, the format is changing to -mm-dd. >>> >>> How can it be done ? >>> >>> Is OFBiz provides any settings for date ? So, that modification in one >>> place >>> can effect the entire application. >>> >>> Please help me. >>> >>> Thanks and Regards, >>> Naveen >>> >>> >>> >>> >>> naveen chanda wrote: Dear all, I have a requirement to change the default date format of ofbiz to dd-mm- in entire application. So, could any one explain me the way to do this task. Thanks, Naveen Chanda >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Date-format-changing-to-dd-mm--tp25745093p25799185.html >>> >>> >>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>> >> >> > Hello Adrian, > > I changed Date format in UtilDateTime.java "-MM-dd" to "dd-MM-". > It was effected in forms after that I again changed date format in > UtilDateTime.java "dd-MM-" to "-MM-dd" but it is not effecting in > forms. Can you help me on this? > > Regards > Ananth > > > > -- View this message in context: http://n4.nabble.com/Date-format-changing-to-dd-mm--tp165544p276412.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Feedbacks on Bluelight theme
Thanks Bruno, I saw it's fixed at r828882, thanks Adrian. What a quick team we have :o) Jacques From: "Bruno Busco" Jacques, please find attached to https://issues.apache.org/jira/browse/OFBIZ-3044 a new patch to fix this. -Bruno 2009/10/22 Bruno Busco : Hi Jacques, thank you for reporting this is related to this: https://issues.apache.org/jira/browse/OFBIZ-3044 I will attach a patch soon to fix this... -Bruno 2009/10/22 Jacques Le Roux : Hi Bruno, I have noticed that with Blue Light in all(?) Catalog Manager screens but Product (ie Prices, Content, etc.) you don't see product Id, annoying ;o) It was there sometimes ago Jacques From: "Jacques Le Roux" Hi Bruno, Actually I use more, in that order, Flat Grey and Business Time. There are no real reasons. I will try to use it a bit more and will give you a feedbak then. Cheers Jacques From: "Bruno Busco" Hi users! I would like to have your feedback on the Bluelight theme. - Do you find it is usable? - Do you find it is user friendly? - How would you like it to be improved? Please fill free to report any issue. Thank you very much, Bruno
Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]
Ok - great - thanks Scott - I'm sure the other Scott will thank you. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Oct 22, 2009, at 1:19 PM, Scott Gray wrote: It actually never made it back into the trunk, the differences between the trunk and revision I was working on were too large for a simple merge and I was quite strapped for time. Thanks for the reminder though, I'll definitely look at putting this in there within the next weekend or two. Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/10/2009, at 5:11 AM, Tim Ruppert wrote: I hope this thread helps Scott. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 Begin forwarded message: From: Scott Gray Date: June 5, 2009 5:12:47 AM MDT To: d...@ofbiz.apache.org Subject: Re: Clearing credit card data after capture Reply-To: d...@ofbiz.apache.org Cool thanks, I'll look into it. Regards Scott On 5/06/2009, at 11:10 PM, David E Jones wrote: The more common recurring stuff in OFBiz right now is recurring orders using an auto-order shopping list. You could certainly check those before whacking the CC# and that would handle it. -David On Jun 5, 2009, at 4:58 AM, Scott Gray wrote: Thanks David, ProductStore it is. About the recurring billing I was hoping there would be someway to check if the cc is being used for it and to leave the information in place. That way we'd only be clearing unused cc data. I'm going to need to check for any pending transactions/ payment prefs before clearing the data anyway, would that check be sufficient to pick up on recurring payments do you think? Regards Scott On 5/06/2009, at 9:54 PM, David E Jones wrote: On Jun 4, 2009, at 11:59 PM, Scott Gray wrote: Hi All, I plan to add a configuration option to clear credit card data once there are no more auths pending against it. When I say clear the data I mean remove the expiry date and credit card number except for the last 4 digits. Any thoughts on where this should be configurable/how it should be implemented? I think the card clearing logic may have to be specific to the gateway being used, e.g. authorize.net needs you to keep the last 4 digits for refunds but others may not. I'm thinking perhaps I could add a new product store payment service type enumeration record, something like PRDS_PAY_CLEAR_DATA and the defined service would run after the capture and release services. That sounds pretty complex, and I'm wondering if the complexity is needed. I guess to really answer more research would be required, or maybe not. Keeping the last 4 digits should be pretty safe, although these days I suppose that could be valuable information for a hacker since for authentication over the phone banks and others generally just ask for the last 4 digits of your government ID#, the last 4 of your CC#, etc. Anyway, it would be more consistent and more simple to just have a setting on the ProductStore, and perhaps one with 3 options: keep CC #s, keep only last 4 digits of CC #s, don't keep CC #s. Recurring billing is the other thing I'm not sure about, I guess I'd need to leave the card data alone in that case but I've never worked with recurring payments so I'm not sure how I would detect if the card is being used for them. If an organization wants to avoid keeping CC #s then it will certainly limit certain otherwise automated things. Recurring orders or recurring billing would be something that is not possible, unless a third party payment provider is used that keeps the CC #. This is actually one of the very appealing things about services like PayPal or GoogleCheckout where the ecommerce site doesn't ever even accept payment information. In fact, for anyone who wants a feature like (ie remove CC numbers after use), they might consider using a third party payment site instead of the more transparent option of handling it through their application. -David smime.p7s Description: S/MIME cryptographic signature
Re: Feedbacks on Bluelight theme
Jacques, please find attached to https://issues.apache.org/jira/browse/OFBIZ-3044 a new patch to fix this. -Bruno 2009/10/22 Bruno Busco : > Hi Jacques, > thank you for reporting this is related to this: > https://issues.apache.org/jira/browse/OFBIZ-3044 > > I will attach a patch soon to fix this... > -Bruno > > 2009/10/22 Jacques Le Roux : >> Hi Bruno, >> >> I have noticed that with Blue Light in all(?) Catalog Manager screens but >> Product (ie Prices, Content, etc.) you don't see product Id, annoying ;o) >> It was there sometimes ago >> >> Jacques >> >> From: "Jacques Le Roux" >>> >>> Hi Bruno, >>> >>> Actually I use more, in that order, Flat Grey and Business Time. There are >>> no real reasons. I will try to use it a bit more and will give you a feedbak >>> then. >>> >>> Cheers >>> >>> Jacques >>> >>> From: "Bruno Busco" Hi users! I would like to have your feedback on the Bluelight theme. - Do you find it is usable? - Do you find it is user friendly? - How would you like it to be improved? Please fill free to report any issue. Thank you very much, Bruno >>> >>> >> >> >> >
Re: Question about authorize.net and PCI
in a nut shell if you through ofbiz collect a CC # you are under PCI. the only way is to send the customer to a site that handles CC and all ofbiz does is store the authorization code. I use Paypal that way. Paypal also lets you style you payment page on there site. it is transparent to the customer. Scott. sent the following on 10/22/2009 8:47 AM: > Hello all, > > We are very close to finalizing our method of credit card processing within > ofbiz and of course, PCI compliance is taking a front seat. We will be using > authorize.net as our gateway and they several different methods with regards > to integration. The easy thing would be to use the current supported method > but my preference would be to not store credit card info at all. > > They are the Simple Checkout, Server Integration Method (SIM) and the > Advanced Integration Method (AIM). I believe that ofbiz natively supports > AIM. The main difference between the three is that from a PCI standpoint the > simple and the SIM method store the credit card data on the Authorize.Net > PCI-compliant servers thus eliminate the PCI compliance for our company. If > I am correct, the SIM method keeps your checkout pages looking the way they > were designed and being able to use the native ofbiz to actually charge > authorizations, etc. > > Has anyone implemented this with ofbiz successfully? How much trouble will > be to modify the ofbiz payment services not to store/read any sensitive > credit card information. > > Thanks in advance for any thoughts. > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]
It actually never made it back into the trunk, the differences between the trunk and revision I was working on were too large for a simple merge and I was quite strapped for time. Thanks for the reminder though, I'll definitely look at putting this in there within the next weekend or two. Regards Scott HotWax Media http://www.hotwaxmedia.com On 23/10/2009, at 5:11 AM, Tim Ruppert wrote: I hope this thread helps Scott. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 Begin forwarded message: From: Scott Gray Date: June 5, 2009 5:12:47 AM MDT To: d...@ofbiz.apache.org Subject: Re: Clearing credit card data after capture Reply-To: d...@ofbiz.apache.org Cool thanks, I'll look into it. Regards Scott On 5/06/2009, at 11:10 PM, David E Jones wrote: The more common recurring stuff in OFBiz right now is recurring orders using an auto-order shopping list. You could certainly check those before whacking the CC# and that would handle it. -David On Jun 5, 2009, at 4:58 AM, Scott Gray wrote: Thanks David, ProductStore it is. About the recurring billing I was hoping there would be someway to check if the cc is being used for it and to leave the information in place. That way we'd only be clearing unused cc data. I'm going to need to check for any pending transactions/ payment prefs before clearing the data anyway, would that check be sufficient to pick up on recurring payments do you think? Regards Scott On 5/06/2009, at 9:54 PM, David E Jones wrote: On Jun 4, 2009, at 11:59 PM, Scott Gray wrote: Hi All, I plan to add a configuration option to clear credit card data once there are no more auths pending against it. When I say clear the data I mean remove the expiry date and credit card number except for the last 4 digits. Any thoughts on where this should be configurable/how it should be implemented? I think the card clearing logic may have to be specific to the gateway being used, e.g. authorize.net needs you to keep the last 4 digits for refunds but others may not. I'm thinking perhaps I could add a new product store payment service type enumeration record, something like PRDS_PAY_CLEAR_DATA and the defined service would run after the capture and release services. That sounds pretty complex, and I'm wondering if the complexity is needed. I guess to really answer more research would be required, or maybe not. Keeping the last 4 digits should be pretty safe, although these days I suppose that could be valuable information for a hacker since for authentication over the phone banks and others generally just ask for the last 4 digits of your government ID#, the last 4 of your CC#, etc. Anyway, it would be more consistent and more simple to just have a setting on the ProductStore, and perhaps one with 3 options: keep CC #s, keep only last 4 digits of CC #s, don't keep CC #s. Recurring billing is the other thing I'm not sure about, I guess I'd need to leave the card data alone in that case but I've never worked with recurring payments so I'm not sure how I would detect if the card is being used for them. If an organization wants to avoid keeping CC #s then it will certainly limit certain otherwise automated things. Recurring orders or recurring billing would be something that is not possible, unless a third party payment provider is used that keeps the CC #. This is actually one of the very appealing things about services like PayPal or GoogleCheckout where the ecommerce site doesn't ever even accept payment information. In fact, for anyone who wants a feature like (ie remove CC numbers after use), they might consider using a third party payment site instead of the more transparent option of handling it through their application. -David smime.p7s Description: S/MIME cryptographic signature
Re: Feedbacks on Bluelight theme
Hi Jacques, thank you for reporting this is related to this: https://issues.apache.org/jira/browse/OFBIZ-3044 I will attach a patch soon to fix this... -Bruno 2009/10/22 Jacques Le Roux : > Hi Bruno, > > I have noticed that with Blue Light in all(?) Catalog Manager screens but > Product (ie Prices, Content, etc.) you don't see product Id, annoying ;o) > It was there sometimes ago > > Jacques > > From: "Jacques Le Roux" >> >> Hi Bruno, >> >> Actually I use more, in that order, Flat Grey and Business Time. There are >> no real reasons. I will try to use it a bit more and will give you a feedbak >> then. >> >> Cheers >> >> Jacques >> >> From: "Bruno Busco" >>> >>> Hi users! >>> I would like to have your feedback on the Bluelight theme. >>> >>> - Do you find it is usable? >>> - Do you find it is user friendly? >>> - How would you like it to be improved? >>> >>> Please fill free to report any issue. >>> >>> Thank you very much, >>> Bruno >>> >> >> > > >
Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]
I hope this thread helps Scott. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 Begin forwarded message: From: Scott Gray Date: June 5, 2009 5:12:47 AM MDT To: d...@ofbiz.apache.org Subject: Re: Clearing credit card data after capture Reply-To: d...@ofbiz.apache.org Cool thanks, I'll look into it. Regards Scott On 5/06/2009, at 11:10 PM, David E Jones wrote: The more common recurring stuff in OFBiz right now is recurring orders using an auto-order shopping list. You could certainly check those before whacking the CC# and that would handle it. -David On Jun 5, 2009, at 4:58 AM, Scott Gray wrote: Thanks David, ProductStore it is. About the recurring billing I was hoping there would be someway to check if the cc is being used for it and to leave the information in place. That way we'd only be clearing unused cc data. I'm going to need to check for any pending transactions/payment prefs before clearing the data anyway, would that check be sufficient to pick up on recurring payments do you think? Regards Scott On 5/06/2009, at 9:54 PM, David E Jones wrote: On Jun 4, 2009, at 11:59 PM, Scott Gray wrote: Hi All, I plan to add a configuration option to clear credit card data once there are no more auths pending against it. When I say clear the data I mean remove the expiry date and credit card number except for the last 4 digits. Any thoughts on where this should be configurable/how it should be implemented? I think the card clearing logic may have to be specific to the gateway being used, e.g. authorize.net needs you to keep the last 4 digits for refunds but others may not. I'm thinking perhaps I could add a new product store payment service type enumeration record, something like PRDS_PAY_CLEAR_DATA and the defined service would run after the capture and release services. That sounds pretty complex, and I'm wondering if the complexity is needed. I guess to really answer more research would be required, or maybe not. Keeping the last 4 digits should be pretty safe, although these days I suppose that could be valuable information for a hacker since for authentication over the phone banks and others generally just ask for the last 4 digits of your government ID#, the last 4 of your CC#, etc. Anyway, it would be more consistent and more simple to just have a setting on the ProductStore, and perhaps one with 3 options: keep CC #s, keep only last 4 digits of CC #s, don't keep CC #s. Recurring billing is the other thing I'm not sure about, I guess I'd need to leave the card data alone in that case but I've never worked with recurring payments so I'm not sure how I would detect if the card is being used for them. If an organization wants to avoid keeping CC #s then it will certainly limit certain otherwise automated things. Recurring orders or recurring billing would be something that is not possible, unless a third party payment provider is used that keeps the CC #. This is actually one of the very appealing things about services like PayPal or GoogleCheckout where the ecommerce site doesn't ever even accept payment information. In fact, for anyone who wants a feature like (ie remove CC numbers after use), they might consider using a third party payment site instead of the more transparent option of handling it through their application. -David smime.p7s Description: S/MIME cryptographic signature
Re: Question about authorize.net and PCI
I'm not sure about your specific needs here being provided OOTB, but we recently added the ability to clean out the actual credit card information. I think that Scott did this at the product store level and we're using Authorize.net in this capacity. Sorry, I can't remember the flag off the top of my head - but I know that it was around June of this year. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Oct 22, 2009, at 9:47 AM, Scott. wrote: Hello all, We are very close to finalizing our method of credit card processing within ofbiz and of course, PCI compliance is taking a front seat. We will be using authorize.net as our gateway and they several different methods with regards to integration. The easy thing would be to use the current supported method but my preference would be to not store credit card info at all. They are the Simple Checkout, Server Integration Method (SIM) and the Advanced Integration Method (AIM). I believe that ofbiz natively supports AIM. The main difference between the three is that from a PCI standpoint the simple and the SIM method store the credit card data on the Authorize.Net PCI-compliant servers thus eliminate the PCI compliance for our company. If I am correct, the SIM method keeps your checkout pages looking the way they were designed and being able to use the native ofbiz to actually charge authorizations, etc. Has anyone implemented this with ofbiz successfully? How much trouble will be to modify the ofbiz payment services not to store/read any sensitive credit card information. Thanks in advance for any thoughts. -- View this message in context: http://n4.nabble.com/Question-about-authorize-net-and-PCI-tp276274p276274.html Sent from the OFBiz - User mailing list archive at Nabble.com. smime.p7s Description: S/MIME cryptographic signature
Question about authorize.net and PCI
Hello all, We are very close to finalizing our method of credit card processing within ofbiz and of course, PCI compliance is taking a front seat. We will be using authorize.net as our gateway and they several different methods with regards to integration. The easy thing would be to use the current supported method but my preference would be to not store credit card info at all. They are the Simple Checkout, Server Integration Method (SIM) and the Advanced Integration Method (AIM). I believe that ofbiz natively supports AIM. The main difference between the three is that from a PCI standpoint the simple and the SIM method store the credit card data on the Authorize.Net PCI-compliant servers thus eliminate the PCI compliance for our company. If I am correct, the SIM method keeps your checkout pages looking the way they were designed and being able to use the native ofbiz to actually charge authorizations, etc. Has anyone implemented this with ofbiz successfully? How much trouble will be to modify the ofbiz payment services not to store/read any sensitive credit card information. Thanks in advance for any thoughts. -- View this message in context: http://n4.nabble.com/Question-about-authorize-net-and-PCI-tp276274p276274.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Feedbacks on Bluelight theme
Hi Bruno, I have noticed that with Blue Light in all(?) Catalog Manager screens but Product (ie Prices, Content, etc.) you don't see product Id, annoying ;o) It was there sometimes ago Jacques From: "Jacques Le Roux" Hi Bruno, Actually I use more, in that order, Flat Grey and Business Time. There are no real reasons. I will try to use it a bit more and will give you a feedbak then. Cheers Jacques From: "Bruno Busco" Hi users! I would like to have your feedback on the Bluelight theme. - Do you find it is usable? - Do you find it is user friendly? - How would you like it to be improved? Please fill free to report any issue. Thank you very much, Bruno
Re: Forecast datetime problem
If you create a new sales forecast ,you can select a time period through Custom Time Period Id . when you run a mrp, it will treat a sales forecast as a sales order . Pierre Smits-3 wrote: > > How so? Please elaborate. > Regards, > > Pierre > > 2009/10/21 zhiyongcui > >> >> We are wrong. >> >> Pierre Smits-3 wrote: >> > >> > It is not in yet. Create a JIRA to address the improvement. >> > >> > 2009/10/21 zhiyongcui >> > >> >> >> >> I think that the forecast detail should have a field to indicate the >> >> time >> >> period for which the forecast ,but I could not find it .If I am wrong >> , >> >> pls >> >> point to me . If I am not wrong then how to implement it ? >> >> -- >> >> View this message in context: >> >> http://n4.nabble.com/Forecast-datetime-problem-tp275498p275498.html >> >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> >> >> > >> > >> >> -- >> View this message in context: >> http://n4.nabble.com/Forecast-datetime-problem-tp275498p275962.html >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> > > -- View this message in context: http://n4.nabble.com/Forecast-datetime-problem-tp275498p276253.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Forecast datetime problem
How so? Please elaborate. Regards, Pierre 2009/10/21 zhiyongcui > > We are wrong. > > Pierre Smits-3 wrote: > > > > It is not in yet. Create a JIRA to address the improvement. > > > > 2009/10/21 zhiyongcui > > > >> > >> I think that the forecast detail should have a field to indicate the > >> time > >> period for which the forecast ,but I could not find it .If I am wrong , > >> pls > >> point to me . If I am not wrong then how to implement it ? > >> -- > >> View this message in context: > >> http://n4.nabble.com/Forecast-datetime-problem-tp275498p275498.html > >> Sent from the OFBiz - User mailing list archive at Nabble.com. > >> > > > > > > -- > View this message in context: > http://n4.nabble.com/Forecast-datetime-problem-tp275498p275962.html > Sent from the OFBiz - User mailing list archive at Nabble.com. >
Re: Forecast datetime problem
2009/10/21 zhiyongcui > > We are wrong. > > Pierre Smits-3 wrote: > > > > It is not in yet. Create a JIRA to address the improvement. > > > > 2009/10/21 zhiyongcui > > > >> > >> I think that the forecast detail should have a field to indicate the > >> time > >> period for which the forecast ,but I could not find it .If I am wrong , > >> pls > >> point to me . If I am not wrong then how to implement it ? > >> -- > >> View this message in context: > >> http://n4.nabble.com/Forecast-datetime-problem-tp275498p275498.html > >> Sent from the OFBiz - User mailing list archive at Nabble.com. > >> > > > > > > -- > View this message in context: > http://n4.nabble.com/Forecast-datetime-problem-tp275498p275962.html > Sent from the OFBiz - User mailing list archive at Nabble.com. >
