Re: [mezzanine-users] Price Rounding Off Issues

[Stephen McDonald]

Ok, seems like nothing to do then - please consider publishing a version
that works with Mezzanine at some point though!

On Mon, May 25, 2015 at 9:21 PM, vikraw  wrote:

> here is the link -
> https://github.com/payu-india/PayU-Integration-Kit-Django
> But that package didn't work out of the box and it needed lots of
> tweaking. So that statement must have been introduced then, as their code
> doesn't has that. Payu-India support for django is not very extensive and
> as a small business our focus is on making things up and running first,
> perfection comes later.
> Also, I don't know how to make that package install automatically using
> pip/fabric. Currently, i manually copy the package and then run their
> install and then sync the code changes.
>
> On Tuesday, May 26, 2015 at 1:25:38 AM UTC+5:30, Stephen McDonald wrote:
>>
>> Well you've resolved it for yourself but surely someone else will hit
>> this.
>>
>> So which payment processor was it?
>>
>> On Mon, May 25, 2015 at 9:45 AM, vikraw  wrote:
>>
>>> Looks like it is resolved for now. One of the payment processor libs had
>>> getcontext().prec = 2. After commenting it out, things looks ok. Once the
>>> flow reached that code, i had issues.
>>> But still not clear why it hasn't happening on dev environment
>>>
>>>
>>>
>>> On Monday, May 25, 2015 at 2:46:19 AM UTC+5:30, Danny S wrote:
>>>
  Is it possible that you are running with different versions of python
 between the runserver and nginx/gunicorn versions of your website?
 I've noticed before in other work that e.g. Python 2.7 has slightly
 different precision on floats than Python 2.6...

 But yeah, weird problem.

 On 25/05/2015 3:45 AM, vikraw wrote:

 The staged server have the locale correctly set ( see at end of my
 message the settings).
 Steps on my Staged server - Amazon Ec2 - Ubuntu 14
 - stopped supervisor and nginx on my staged machine
 - switched my staged machine to run using - python manage runserver
 0.0.0.0:8000
 - put "printf value" statement in the "currency" filter under
 shop_tags.py
 now when i browse (using windows machine) the site running on ec2
 machine I have NO issues with the Product prices, Cart total etc..Both the
 Browser and the printf values match

 However, when I switch the machine to nginx and start browsing from
 windows machine, i start getting the incorrect prices (alternate between
 correct and wrong) when
 - I press the different products or go back and forth from cart to
 product pages
 - Switching between incorrect price and correct prices happens
 everytime when I goto my payment processor and click the back button again
 to website (neglecting browser warnings that page has expired). BUT this
 doesn't happens when site running from "python manage runserver"

 ex: Rs.249 is displayed as Rs.250 and Rs.349 as Rs.350. clicking the
 same link toggles between those 2 values

 Help is greatly appreciated as i am near completion and can't figure
 this ambiguous behavior.
 My development is on Local Machine a Ubuntu 12.01LTS and I was testing
 using "python manage runserver" on 127.0.0.0:8000... This is working
 as expected


 locale command on ubuntu-14 amazon-ec2
 LANG=en_IN
 LANGUAGE=en_IN:en
 LC_CTYPE="en_IN"
 LC_NUMERIC="en_IN"
 LC_TIME="en_IN"
 LC_COLLATE="en_IN"
 LC_MONETARY="en_IN"
 LC_MESSAGES="en_IN"
 LC_PAPER="en_IN"
 LC_NAME="en_IN"
 LC_ADDRESS="en_IN"
 LC_TELEPHONE="en_IN"
 LC_MEASUREMENT="en_IN"
 LC_IDENTIFICATION="en_IN"
 LC_ALL=





 The currencies symbol is correctly shown on the browser. However, i the
 prices change sometimes alternately and sometimes randomly. Correct price
 is 249. it switches between 249 and 250 when i click the same page or cart
 button. the cart total is updated

 On Saturday, May 23, 2015 at 10:59:37 PM UTC+5:30, Stephen McDonald
 wrote:
>
> It looks like you're calculating the correct value being stored in the
> DB, and only getting the error on output. Each currency value gets passed
> through the "currency" template tag, which is where the problem likely is.
> It also deals with machine specific locale settings, which will vary per
> machine - also making it a likely candidate for the error.
>
>  Here's the source for it -
> https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templatetags/shop_tags.py#L17-L41
>
>  Have you consistently defined (and installed) the correct locale?
> (defined with the SHOP_CURRENCY_LOCALE setting).
>
>  Can you debug what happens in the "currency" template tag on your
> deployed machine? That might entail adding some logging to it, making a
> copy of it in your own project, printing out values while manually running
> it in a termin

Re: [mezzanine-users] Price Rounding Off Issues

[vikraw]

here is the link - https://github.com/payu-india/PayU-Integration-Kit-Django
But that package didn't work out of the box and it needed lots of tweaking. 
So that statement must have been introduced then, as their code doesn't has 
that. Payu-India support for django is not very extensive and as a small 
business our focus is on making things up and running first, perfection 
comes later.
Also, I don't know how to make that package install automatically using 
pip/fabric. Currently, i manually copy the package and then run their 
install and then sync the code changes. 

On Tuesday, May 26, 2015 at 1:25:38 AM UTC+5:30, Stephen McDonald wrote:
>
> Well you've resolved it for yourself but surely someone else will hit 
> this. 
>
> So which payment processor was it? 
>
> On Mon, May 25, 2015 at 9:45 AM, vikraw > 
> wrote:
>
>> Looks like it is resolved for now. One of the payment processor libs had 
>> getcontext().prec = 2. After commenting it out, things looks ok. Once the 
>> flow reached that code, i had issues.
>> But still not clear why it hasn't happening on dev environment
>>
>>
>>
>> On Monday, May 25, 2015 at 2:46:19 AM UTC+5:30, Danny S wrote:
>>
>>>  Is it possible that you are running with different versions of python 
>>> between the runserver and nginx/gunicorn versions of your website?
>>> I've noticed before in other work that e.g. Python 2.7 has slightly 
>>> different precision on floats than Python 2.6...
>>>
>>> But yeah, weird problem.
>>>
>>> On 25/05/2015 3:45 AM, vikraw wrote:
>>>  
>>> The staged server have the locale correctly set ( see at end of my 
>>> message the settings).
>>> Steps on my Staged server - Amazon Ec2 - Ubuntu 14
>>> - stopped supervisor and nginx on my staged machine
>>> - switched my staged machine to run using - python manage runserver 
>>> 0.0.0.0:8000 
>>> - put "printf value" statement in the "currency" filter under 
>>> shop_tags.py 
>>> now when i browse (using windows machine) the site running on ec2 
>>> machine I have NO issues with the Product prices, Cart total etc..Both the 
>>> Browser and the printf values match
>>>
>>> However, when I switch the machine to nginx and start browsing from 
>>> windows machine, i start getting the incorrect prices (alternate between 
>>> correct and wrong) when
>>> - I press the different products or go back and forth from cart to 
>>> product pages
>>> - Switching between incorrect price and correct prices happens everytime 
>>> when I goto my payment processor and click the back button again to website 
>>> (neglecting browser warnings that page has expired). BUT this doesn't 
>>> happens when site running from "python manage runserver"
>>>
>>> ex: Rs.249 is displayed as Rs.250 and Rs.349 as Rs.350. clicking the 
>>> same link toggles between those 2 values 
>>>
>>> Help is greatly appreciated as i am near completion and can't figure 
>>> this ambiguous behavior. 
>>> My development is on Local Machine a Ubuntu 12.01LTS and I was testing 
>>> using "python manage runserver" on 127.0.0.0:8000... This is working as 
>>> expected
>>>
>>>
>>> locale command on ubuntu-14 amazon-ec2 
>>> LANG=en_IN
>>> LANGUAGE=en_IN:en
>>> LC_CTYPE="en_IN"
>>> LC_NUMERIC="en_IN"
>>> LC_TIME="en_IN"
>>> LC_COLLATE="en_IN"
>>> LC_MONETARY="en_IN"
>>> LC_MESSAGES="en_IN"
>>> LC_PAPER="en_IN"
>>> LC_NAME="en_IN"
>>> LC_ADDRESS="en_IN"
>>> LC_TELEPHONE="en_IN"
>>> LC_MEASUREMENT="en_IN"
>>> LC_IDENTIFICATION="en_IN"
>>> LC_ALL=
>>>
>>>
>>>
>>>
>>>
>>> The currencies symbol is correctly shown on the browser. However, i the 
>>> prices change sometimes alternately and sometimes randomly. Correct price 
>>> is 249. it switches between 249 and 250 when i click the same page or cart 
>>> button. the cart total is updated 
>>>
>>> On Saturday, May 23, 2015 at 10:59:37 PM UTC+5:30, Stephen McDonald 
>>> wrote: 

 It looks like you're calculating the correct value being stored in the 
 DB, and only getting the error on output. Each currency value gets passed 
 through the "currency" template tag, which is where the problem likely is. 
 It also deals with machine specific locale settings, which will vary per 
 machine - also making it a likely candidate for the error. 

  Here's the source for it - 
 https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templatetags/shop_tags.py#L17-L41

  Have you consistently defined (and installed) the correct locale? 
 (defined with the SHOP_CURRENCY_LOCALE setting).

  Can you debug what happens in the "currency" template tag on your 
 deployed machine? That might entail adding some logging to it, making a 
 copy of it in your own project, printing out values while manually running 
 it in a terminal, whatever works for you.

  
  
  
  
 On Sat, May 23, 2015 at 3:26 AM, vikraw  wrote:

> Hi
>
> Almost near launching a site. But running into Price rounding issues 
> today when I fab deployed

Re: [mezzanine-users] Price Rounding Off Issues

[Stephen McDonald]

Well you've resolved it for yourself but surely someone else will hit this.

So which payment processor was it?

On Mon, May 25, 2015 at 9:45 AM, vikraw  wrote:

> Looks like it is resolved for now. One of the payment processor libs had
> getcontext().prec = 2. After commenting it out, things looks ok. Once the
> flow reached that code, i had issues.
> But still not clear why it hasn't happening on dev environment
>
>
>
> On Monday, May 25, 2015 at 2:46:19 AM UTC+5:30, Danny S wrote:
>
>>  Is it possible that you are running with different versions of python
>> between the runserver and nginx/gunicorn versions of your website?
>> I've noticed before in other work that e.g. Python 2.7 has slightly
>> different precision on floats than Python 2.6...
>>
>> But yeah, weird problem.
>>
>> On 25/05/2015 3:45 AM, vikraw wrote:
>>
>> The staged server have the locale correctly set ( see at end of my
>> message the settings).
>> Steps on my Staged server - Amazon Ec2 - Ubuntu 14
>> - stopped supervisor and nginx on my staged machine
>> - switched my staged machine to run using - python manage runserver
>> 0.0.0.0:8000
>> - put "printf value" statement in the "currency" filter under
>> shop_tags.py
>> now when i browse (using windows machine) the site running on ec2 machine
>> I have NO issues with the Product prices, Cart total etc..Both the Browser
>> and the printf values match
>>
>> However, when I switch the machine to nginx and start browsing from
>> windows machine, i start getting the incorrect prices (alternate between
>> correct and wrong) when
>> - I press the different products or go back and forth from cart to
>> product pages
>> - Switching between incorrect price and correct prices happens everytime
>> when I goto my payment processor and click the back button again to website
>> (neglecting browser warnings that page has expired). BUT this doesn't
>> happens when site running from "python manage runserver"
>>
>> ex: Rs.249 is displayed as Rs.250 and Rs.349 as Rs.350. clicking the same
>> link toggles between those 2 values
>>
>> Help is greatly appreciated as i am near completion and can't figure this
>> ambiguous behavior.
>> My development is on Local Machine a Ubuntu 12.01LTS and I was testing
>> using "python manage runserver" on 127.0.0.0:8000... This is working as
>> expected
>>
>>
>> locale command on ubuntu-14 amazon-ec2
>> LANG=en_IN
>> LANGUAGE=en_IN:en
>> LC_CTYPE="en_IN"
>> LC_NUMERIC="en_IN"
>> LC_TIME="en_IN"
>> LC_COLLATE="en_IN"
>> LC_MONETARY="en_IN"
>> LC_MESSAGES="en_IN"
>> LC_PAPER="en_IN"
>> LC_NAME="en_IN"
>> LC_ADDRESS="en_IN"
>> LC_TELEPHONE="en_IN"
>> LC_MEASUREMENT="en_IN"
>> LC_IDENTIFICATION="en_IN"
>> LC_ALL=
>>
>>
>>
>>
>>
>> The currencies symbol is correctly shown on the browser. However, i the
>> prices change sometimes alternately and sometimes randomly. Correct price
>> is 249. it switches between 249 and 250 when i click the same page or cart
>> button. the cart total is updated
>>
>> On Saturday, May 23, 2015 at 10:59:37 PM UTC+5:30, Stephen McDonald
>> wrote:
>>>
>>> It looks like you're calculating the correct value being stored in the
>>> DB, and only getting the error on output. Each currency value gets passed
>>> through the "currency" template tag, which is where the problem likely is.
>>> It also deals with machine specific locale settings, which will vary per
>>> machine - also making it a likely candidate for the error.
>>>
>>>  Here's the source for it -
>>> https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templatetags/shop_tags.py#L17-L41
>>>
>>>  Have you consistently defined (and installed) the correct locale?
>>> (defined with the SHOP_CURRENCY_LOCALE setting).
>>>
>>>  Can you debug what happens in the "currency" template tag on your
>>> deployed machine? That might entail adding some logging to it, making a
>>> copy of it in your own project, printing out values while manually running
>>> it in a terminal, whatever works for you.
>>>
>>>
>>>
>>>
>>>
>>> On Sat, May 23, 2015 at 3:26 AM, vikraw  wrote:
>>>
 Hi

 Almost near launching a site. But running into Price rounding issues
 today when I fab deployed to AWS ec2 instance. Never had those issues
 before on ec2.
 My Development environment is working great with no issues.

 However on deployed machine -Prices are getting rounded off in various
 places ex: 249 was rounded off to 250 in cart.html, as well as HTML
 invoice, PDF invoice.
 Unit Price was displaying correctly as 249 But "Total Price" was
 showing 250

 Also, facing rounding off issues in PDF invoice and View Invoice in
 browser.

 The amounts are accurate in email invoice though. Even the amounts sent
 to payment gateway are correct. When the account user goes to history of
 orders, the amounts are correctly displayed in the columns. Only issues are
 cart, html invoice, pdf templates.

 I have a tax_handler where i calculate tax as 

Re: [mezzanine-users] Re: The Readme on Github - I would like to give it a revamp

[Stephen McDonald]

It's just a regular Mezzanine project - there aren't any special
instructions.

On Sun, May 24, 2015 at 3:08 PM, Graham  wrote:

>  Thanks Brandon
> I will get going with the feedback I have.
> Stephen, could you please give me the instructions on how to install the
> 'project site' on my local development machine.
> I can do the git clone but I am a bit hazy after that.
> Thanks
> g
>
>
> On 24/05/15 21:41, Brandon Keith Biggs wrote:
>
> Hello,
> I believe most people who read the readme on github have already seen the
> website.
> So they would like to know technical stuff and how to get started and do
> basic and essential things.
> Perhaps a link to Dgango's guide and then instructions on how to get
> started and instructions on how to deploy.
> thanks,
>
>  Brandon Keith Biggs 
> On 5/24/2015 11:20 AM, Graham wrote:
>
> Hello all...
> I am also interested in the 'who' and the 'why' and this may help us
> decide what should go in the README...
>
> *Who* are we designing the README for?
> *Why* would the reader of the README choose to become involved, what would
> 'hook them in'?
> *Why* choose Mezzanine over any other 'similar' project?
> *Who* would we like to attract to the project / to use Mezzanine?
> Is there a minimum skill level that we want to mention?
>
> Clearly I have my own responses to these questions, but interested to hear
> others points of view before I unduly influence anyone!
>
> Cheers
> g
>
>
> On 24/05/15 05:40, Stephen McDonald wrote:
>
>
>
> On Fri, May 22, 2015 at 11:14 PM, Mathias Ettinger <
> mathias.ettin...@gmail.com> wrote:
>
>> Why not swap it entirely with doc/overview.rst?
>>
>
>  I think this will be the general approach - move stuff out of the
> README, and directly into the docs, and adding links in the README back to
> the docs for these moved pieces.
>
>  Here's my initial thoughts on each section, feedback welcome.
>
>  Overview -> leave as is
> Features -> leave as is
> Dependencies -> move to end of "installation" section
> Installation -> move to "overview" in docs, and link from README
> Themes -> move to "overview" in docs, no link needed from README
> Browser support -> move to "overview" in docs, no link needed from README
> Contributing -> leave as is
>  Multi-lingual sites -> already has a docs section, merge into that or
> remove
> Third party plugins -> move to "overview" in docs, and link from README
> Donating -> leave as is
> Support -> leave as is, but move up to a more prominent spot (the number
> of invalid issues opened when posting to the mailing list would suffice is
> overwhelming)
> Sites using Mezzanine -> move to "overview" in docs, and link from README
> (refactoring demo site required)
> Quotes -> leave as is
>
>
>
>
>
>
>
>>
>> This way, what relies on README.rst today can rely on overview.rst
>> tomorow without breaking anything. Or is the point to shorten both?
>>
>>
>> Le vendredi 22 mai 2015 22:32:01 UTC+2, Stephen McDonald a écrit :
>>>
>>> It's a good idea.
>>>
>>>  Please keep in mind there's some functionality of the project site
>>> dependent on the format of the readme, particularly those lists we'll
>>> probably remove:
>>>
>>>
>>> https://github.com/stephenmcd/mezzanine.jupo.org/blob/master/demo/__init__.py
>>>
>>> On Fri, May 22, 2015 at 1:26 PM, Geo  wrote:
>>>
 +1

 Mezzanine's Readme is, at the time of writing, 795 lines long - pretty
 much an essay! The GH Readme for Django itself is short and sweet at just
 44 lines. That's a massive 94% reduction in lines.

 If you are looking for a python CMS to use, you want to read about 3
 key features of Mezzanine that make it stand out from all the others,
 that's all. Then one could link to the Mezzanine website and documentation
 website for further details and even for installation steps etc.

 Just my thoughts. Interesting to hear what the core devs think...


 On Friday, 22 May 2015 10:43:37 UTC+1, Graham Oliver wrote:
>
> Hi all
> I would like to have a go at revamping the readme on GitHub
> https://github.com/stephenmcd/mezzanine/blob/master/README.rst
>
> Initial thoughts
> - Make it way shorter
> - Put the 'third party plugins' and 'sites using Mezzanine' lists in
> separate documents
> - Add details of 'Core Development Team'
>
> Possibly also something for people (relatively) new to the Open Source
> thing.
>
> All feedback appreciated...
>
> This one I quite like (apart from the crypto stuff)
> http://svn.apache.org/repos/asf/httpd/httpd/trunk/README
>
> Take Care
> g
>
> --
 You received this message because you are subscribed to the Google
 Groups "Mezzanine Users" group.
  To unsubscribe from this group and stop receiving emails from it, send
 an email to mezzanine-use...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Getting posts for specific category

[Eduardo Rivas]

Nice :)

--
You received this message because you are subscribed to the Google Groups "Mezzanine 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Getting posts for specific category

[Jonathan Sandoval]

Many thanks. That's exactly what I needed.

El lunes, 25 de mayo de 2015, 12:48:29 (UTC-5), Eduardo Rivas escribió:
>
> Mezzanine's blog comes with a template tag that can pull recent posts 
> into your template context, optionally filtering by category. 
> Documentation here: 
>
> http://mezzanine.jupo.org/docs/packages.html?highlight=recent_posts#mezzanine.blog.templatetags.blog_tags.blog_recent_posts
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Getting posts for specific category

[Eduardo Rivas]

Mezzanine's blog comes with a template tag that can pull recent posts 
into your template context, optionally filtering by category. 
Documentation here: 
http://mezzanine.jupo.org/docs/packages.html?highlight=recent_posts#mezzanine.blog.templatetags.blog_tags.blog_recent_posts


--
You received this message because you are subscribed to the Google Groups "Mezzanine 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Getting posts for specific category

[Jonathan Sandoval]

Hi everyone.
I have experience in python, but not much in django or mezzanine, so, maybe 
this question is more django related (or maybe not). I'm creating a site 
and the homepage has sections like latest news, latest articles and so on. 
So, I'm needing a way to get a list of posts for a specific category (and 
only a slice of this, but, I think I can do this with the slice in django 
templates).  ¿How can I do this, I mean, in a template to get only specific 
posts?.

Thanks for any help or advice.

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Price Rounding Off Issues

[vikraw]

Looks like it is resolved for now. One of the payment processor libs had 
getcontext().prec = 2. After commenting it out, things looks ok. Once the 
flow reached that code, i had issues.
But still not clear why it hasn't happening on dev environment


On Monday, May 25, 2015 at 2:46:19 AM UTC+5:30, Danny S wrote:
>
>  Is it possible that you are running with different versions of python 
> between the runserver and nginx/gunicorn versions of your website?
> I've noticed before in other work that e.g. Python 2.7 has slightly 
> different precision on floats than Python 2.6...
>
> But yeah, weird problem.
>
> On 25/05/2015 3:45 AM, vikraw wrote:
>  
> The staged server have the locale correctly set ( see at end of my message 
> the settings).
> Steps on my Staged server - Amazon Ec2 - Ubuntu 14
> - stopped supervisor and nginx on my staged machine
> - switched my staged machine to run using - python manage runserver 
> 0.0.0.0:8000 
> - put "printf value" statement in the "currency" filter under shop_tags.py 
> now when i browse (using windows machine) the site running on ec2 machine 
> I have NO issues with the Product prices, Cart total etc..Both the Browser 
> and the printf values match
>
> However, when I switch the machine to nginx and start browsing from 
> windows machine, i start getting the incorrect prices (alternate between 
> correct and wrong) when
> - I press the different products or go back and forth from cart to product 
> pages
> - Switching between incorrect price and correct prices happens everytime 
> when I goto my payment processor and click the back button again to website 
> (neglecting browser warnings that page has expired). BUT this doesn't 
> happens when site running from "python manage runserver"
>
> ex: Rs.249 is displayed as Rs.250 and Rs.349 as Rs.350. clicking the same 
> link toggles between those 2 values 
>
> Help is greatly appreciated as i am near completion and can't figure this 
> ambiguous behavior. 
> My development is on Local Machine a Ubuntu 12.01LTS and I was testing 
> using "python manage runserver" on 127.0.0.0:8000... This is working as 
> expected
>
>
> locale command on ubuntu-14 amazon-ec2 
> LANG=en_IN
> LANGUAGE=en_IN:en
> LC_CTYPE="en_IN"
> LC_NUMERIC="en_IN"
> LC_TIME="en_IN"
> LC_COLLATE="en_IN"
> LC_MONETARY="en_IN"
> LC_MESSAGES="en_IN"
> LC_PAPER="en_IN"
> LC_NAME="en_IN"
> LC_ADDRESS="en_IN"
> LC_TELEPHONE="en_IN"
> LC_MEASUREMENT="en_IN"
> LC_IDENTIFICATION="en_IN"
> LC_ALL=
>
>
>
>
>
> The currencies symbol is correctly shown on the browser. However, i the 
> prices change sometimes alternately and sometimes randomly. Correct price 
> is 249. it switches between 249 and 250 when i click the same page or cart 
> button. the cart total is updated 
>
> On Saturday, May 23, 2015 at 10:59:37 PM UTC+5:30, Stephen McDonald wrote: 
>>
>> It looks like you're calculating the correct value being stored in the 
>> DB, and only getting the error on output. Each currency value gets passed 
>> through the "currency" template tag, which is where the problem likely is. 
>> It also deals with machine specific locale settings, which will vary per 
>> machine - also making it a likely candidate for the error. 
>>
>>  Here's the source for it - 
>> https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/templatetags/shop_tags.py#L17-L41
>>
>>  Have you consistently defined (and installed) the correct locale? 
>> (defined with the SHOP_CURRENCY_LOCALE setting).
>>
>>  Can you debug what happens in the "currency" template tag on your 
>> deployed machine? That might entail adding some logging to it, making a 
>> copy of it in your own project, printing out values while manually running 
>> it in a terminal, whatever works for you.
>>
>>  
>>  
>>  
>>  
>> On Sat, May 23, 2015 at 3:26 AM, vikraw  wrote:
>>
>>> Hi
>>>
>>> Almost near launching a site. But running into Price rounding issues 
>>> today when I fab deployed to AWS ec2 instance. Never had those issues 
>>> before on ec2.
>>> My Development environment is working great with no issues.
>>>
>>> However on deployed machine -Prices are getting rounded off in various 
>>> places ex: 249 was rounded off to 250 in cart.html, as well as HTML 
>>> invoice, PDF invoice.
>>> Unit Price was displaying correctly as 249 But "Total Price" was showing 
>>> 250
>>>
>>> Also, facing rounding off issues in PDF invoice and View Invoice in 
>>> browser. 
>>>
>>> The amounts are accurate in email invoice though. Even the amounts sent 
>>> to payment gateway are correct. When the account user goes to history of 
>>> orders, the amounts are correctly displayed in the columns. Only issues are 
>>> cart, html invoice, pdf templates.
>>>
>>> I have a tax_handler where i calculate tax as follows - TAX_RATE = 0.05  
>>>  tax_total = Decimal(amount_to_tax) * Decimal(str(settings.TAX_RATE)) 
>>>
>>> See attached files - 366.45 is the correct amount being shown in 
>>> Order-History page, but invoice is generated or 370.
>>>

Re: [mezzanine-users] Re: Mezzanine master version in requirements.txt

[Federico Bruni]

Ok, if I use -e option then pip freeze shows the exact commit used:

-e git+
https://github.com/stephenmcd/mezzanine.git@48776c2f5e19b780349da05f14b6527ffaa165e4#egg=Mezzanine-master

Thanks
Federico


2015-05-25 14:42 GMT+02:00 Mathias Ettinger :

> You can use the -e option of pip install. Example:
> pip install -e git+
> https://github.com/stephenmcd/mezzanine.git@master#egg=Mezzanine
> pip install -e git+
> https://github.com/stephenmcd/cartridge.git@master#egg=Cartridge
>
> If you need a requirements.txt file afterwards, just use the output of pip
> freeze.
>
>
>
> Le lundi 25 mai 2015 13:07:54 UTC+2, Federico Bruni a écrit :
>>
>> Even if I install mezzanine from git repository, the requirements file
>> created by mezzanine-project will be taken from the version present in
>> project_template:
>>
>> https://github.com/stephenmcd/mezzanine/blob/081dd68c8c53893c28c6c96cca666f6db15317ca/mezzanine/project_template/requirements.txt
>>
>> that is, the last stable release.
>>
>> How can I turn this:
>>
>> $ cat requirements.txt
>> Mezzanine==3.1.10
>>
>> into a git version?
>> I need it also for deploying.
>>
>> I've read this page
>> https://pip.pypa.io/en/stable/user_guide.html#requirements-files
>> and I tried several variants of this:
>>
>> Mezzanine==git+
>> https://github.com/stephenmcd/mezzanine@master#egg=mezzanine
>>
>> but nothing works and I get this error:
>>
>> File
>> "/home/fede/.virtualenvs/mezzanine/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py",
>> line 2880, in scan_list
>> raise ValueError(msg, line, "at", line[p:])
>> ValueError: ("Expected ',' or end-of-list in", 'Mezzanine==git+
>> https://github.com/stephenmcd/mezzanine@master#egg=mezzanine', 'at', '://
>> github.com/stephenmcd/mezzanine@master#egg=mezzanine')
>>
>>
>> Thanks in advance
>> Federico
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Mezzanine Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/mezzanine-users/Av5nZzD4bLw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> mezzanine-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: Mezzanine master version in requirements.txt

[Mathias Ettinger]

You can use the -e option of pip install. Example:
pip install -e 
git+https://github.com/stephenmcd/mezzanine.git@master#egg=Mezzanine
pip install -e 
git+https://github.com/stephenmcd/cartridge.git@master#egg=Cartridge

If you need a requirements.txt file afterwards, just use the output of pip 
freeze.


Le lundi 25 mai 2015 13:07:54 UTC+2, Federico Bruni a écrit :
>
> Even if I install mezzanine from git repository, the requirements file 
> created by mezzanine-project will be taken from the version present in 
> project_template:
>
> https://github.com/stephenmcd/mezzanine/blob/081dd68c8c53893c28c6c96cca666f6db15317ca/mezzanine/project_template/requirements.txt
>
> that is, the last stable release.
>
> How can I turn this:
>
> $ cat requirements.txt 
> Mezzanine==3.1.10
>
> into a git version?
> I need it also for deploying.
>
> I've read this page 
> https://pip.pypa.io/en/stable/user_guide.html#requirements-files
> and I tried several variants of this:
>
> Mezzanine==git+
> https://github.com/stephenmcd/mezzanine@master#egg=mezzanine
>
> but nothing works and I get this error:
>
> File 
> "/home/fede/.virtualenvs/mezzanine/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py",
>  
> line 2880, in scan_list
> raise ValueError(msg, line, "at", line[p:])
> ValueError: ("Expected ',' or end-of-list in", 'Mezzanine==git+
> https://github.com/stephenmcd/mezzanine@master#egg=mezzanine', 'at', '://
> github.com/stephenmcd/mezzanine@master#egg=mezzanine')
>
>
> Thanks in advance
> Federico
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Mezzanine master version in requirements.txt

[Federico Bruni]

Even if I install mezzanine from git repository, the requirements file 
created by mezzanine-project will be taken from the version present in 
project_template:
https://github.com/stephenmcd/mezzanine/blob/081dd68c8c53893c28c6c96cca666f6db15317ca/mezzanine/project_template/requirements.txt

that is, the last stable release.

How can I turn this:

$ cat requirements.txt 
Mezzanine==3.1.10

into a git version?
I need it also for deploying.

I've read this page 
https://pip.pypa.io/en/stable/user_guide.html#requirements-files
and I tried several variants of this:

Mezzanine==git+https://github.com/stephenmcd/mezzanine@master#egg=mezzanine

but nothing works and I get this error:

File 
"/home/fede/.virtualenvs/mezzanine/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py",
 
line 2880, in scan_list
raise ValueError(msg, line, "at", line[p:])
ValueError: ("Expected ',' or end-of-list in", 
'Mezzanine==git+https://github.com/stephenmcd/mezzanine@master#egg=mezzanine', 
'at', '://github.com/stephenmcd/mezzanine@master#egg=mezzanine')


Thanks in advance
Federico

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Mathias Ettinger]

You best bet might be to ping @*sjkingo * on 
the github issue to see if he can share what he already started. That might 
even (re)start the discussion on how to best integrate it into cartridge.


Le lundi 25 mai 2015 12:20:59 UTC+2, Tomlin a écrit :
>
> Unfortunately, it is a problem. I can't rely on a unique combination of 
> options (in some cases it will only be the dimensions that differ).
>
> The ProductVariation manager does have a check that ensures option sets 
> must be unique in order to save the variation (the try/except): 
> def create_from_options(self, options):
> """
> Create all unique variations from the selected options.
> """
> if options:
> options = SortedDict(options)
> # Build all combinations of options.
> variations = [[]]
> for values_list in list(options.values()):
> variations = [x + [y] for x in variations for y in 
> values_list]
> for variation in variations:
> # Lookup unspecified options as null to ensure a
> # unique filter.
> variation = dict(list(zip(list(options.keys()), 
> variation)))
> lookup = dict(variation)
> 
> lookup.update(self._empty_options_lookup(exclude=variation))
> try:
> self.get(**lookup)
> except self.model.DoesNotExist:
> self.create(**variation)
>
> It's s tempting to hack away at some of these files but I'll persevere 
> and find a way of doing it while leaving the cartridge files intact :)
>
> On Monday, May 25, 2015 at 7:32:45 PM UTC+10, Mathias Ettinger wrote:
>>
>> If you used EXTRA_MODEL_FIELDS to inject fields into ProductVariation, 
>> then ProductVariation.option_fields won't consider them for the “identity 
>> check” unless they are of type cartridge.shop.fields.OptionField (which I 
>> doubt, I would bet on regular IntegerField).
>>
>> So it might not be a problem for you.
>>
>>
>> Le lundi 25 mai 2015 10:56:06 UTC+2, Tomlin a écrit :
>>>
>>> Good thing you pointed that out. I just read this - "You'll also see in 
>>> ProductVariation.option_fields its used as an identity check".
>>>
>>> Seems I still need every variation to have a unique set of options. Doh!
>>>
>>> On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote:

 There is also the begining of a discussion on dynamic variation fields 
 here: https://github.com/stephenmcd/cartridge/issues/232
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Tomlin]

Unfortunately, it is a problem. I can't rely on a unique combination of 
options (in some cases it will only be the dimensions that differ).

The ProductVariation manager does have a check that ensures option sets 
must be unique in order to save the variation (the try/except): 
def create_from_options(self, options):
"""
Create all unique variations from the selected options.
"""
if options:
options = SortedDict(options)
# Build all combinations of options.
variations = [[]]
for values_list in list(options.values()):
variations = [x + [y] for x in variations for y in 
values_list]
for variation in variations:
# Lookup unspecified options as null to ensure a
# unique filter.
variation = dict(list(zip(list(options.keys()), variation)))
lookup = dict(variation)
lookup.update(self._empty_options_lookup(exclude=variation))
try:
self.get(**lookup)
except self.model.DoesNotExist:
self.create(**variation)

It's s tempting to hack away at some of these files but I'll persevere 
and find a way of doing it while leaving the cartridge files intact :)

On Monday, May 25, 2015 at 7:32:45 PM UTC+10, Mathias Ettinger wrote:
>
> If you used EXTRA_MODEL_FIELDS to inject fields into ProductVariation, 
> then ProductVariation.option_fields won't consider them for the “identity 
> check” unless they are of type cartridge.shop.fields.OptionField (which I 
> doubt, I would bet on regular IntegerField).
>
> So it might not be a problem for you.
>
>
> Le lundi 25 mai 2015 10:56:06 UTC+2, Tomlin a écrit :
>>
>> Good thing you pointed that out. I just read this - "You'll also see in 
>> ProductVariation.option_fields its used as an identity check".
>>
>> Seems I still need every variation to have a unique set of options. Doh!
>>
>> On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote:
>>>
>>> There is also the begining of a discussion on dynamic variation fields 
>>> here: https://github.com/stephenmcd/cartridge/issues/232
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Mathias Ettinger]

If you used EXTRA_MODEL_FIELDS to inject fields into ProductVariation, then 
ProductVariation.option_fields won't consider them for the “identity check” 
unless they are of type cartridge.shop.fields.OptionField (which I doubt, I 
would bet on regular IntegerField).

So it might not be a problem for you.


Le lundi 25 mai 2015 10:56:06 UTC+2, Tomlin a écrit :
>
> Good thing you pointed that out. I just read this - "You'll also see in 
> ProductVariation.option_fields its used as an identity check".
>
> Seems I still need every variation to have a unique set of options. Doh!
>
> On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote:
>>
>> There is also the begining of a discussion on dynamic variation fields 
>> here: https://github.com/stephenmcd/cartridge/issues/232
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Tomlin]

Good thing you pointed that out. I just read this - "You'll also see in 
ProductVariation.option_fields its used as an identity check".

Seems I still need every variation to have a unique set of options. Doh!

On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote:
>
> There is also the begining of a discussion on dynamic variation fields 
> here: https://github.com/stephenmcd/cartridge/issues/232

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Tomlin]

Thanks, I'll take a look at that. Product variations in general have proven 
to be a bit of a pain-point for me. If I were going to be administering the 
site myself I wouldn't be so concerned but it's tough trying to wrangle the 
admin into something that a layperson can use intuitively. It's getting 
easier every day though!

On Monday, May 25, 2015 at 6:35:37 PM UTC+10, Mathias Ettinger wrote:
>
> There is also the begining of a discussion on dynamic variation fields 
> here: https://github.com/stephenmcd/cartridge/issues/232

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Tomlin]

Thanks Mathias,

That was the approach I had taken but it was getting a bit out of hand 
(especially because the options are ordered by the time they were added so 
I was ending up with a huge list of options that weren't even in numerical 
order). I managed to solve it by adding some extra fields to the 
ProductVariation model. I was also pretty keen to not give the admin user 
the ability to add new options as some of them (framing, format) shouldn't 
be added to or deleted.

On Monday, May 25, 2015 at 6:31:33 PM UTC+10, Mathias Ettinger wrote:
>
> You can use the default variation handling to achieve that. It might not 
> be ideal because it will add a lot of checkboxes but it will do the job. 
>
> Just add width and height (or juste size if you prefer) to the 
> SHOP_OPTION_TYPE_CHOICES setting and create as much product options as 
> needed for your produits using numerical values. You will then be able to 
> use the chexboxes to get the desired size for your variations.

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] What would be the best way to accept arbitrary values for product variations?

[Mathias Ettinger]

There is also the begining of a discussion on dynamic variation fields here: 
https://github.com/stephenmcd/cartridge/issues/232

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] What would be the best way to accept arbitrary values for product variations?

[Mathias Ettinger]

You can use the default variation handling to achieve that. It might not be 
ideal because it will add a lot of checkboxes but it will do the job.

Just add width and height (or juste size if you prefer) to the 
SHOP_OPTION_TYPE_CHOICES setting and create as much product options as needed 
for your produits using numerical values. You will then be able to use the 
chexboxes to get the desired size for your variations.

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: What would be the best way to accept arbitrary values for product variations?

[Tomlin]

For anyone that might be interested, I solved this by adding 
EXTRA_MODEL_FIELDS to the ProductVariation model in my settings.py and 
subclassing ProductVariationAdmin in my admin.py to insert those extra 
fields.

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.