Hi,
I posted something similar a while back:
https://groups.google.com/forum/#!topic/mezzanine-users/-ltMQLoS8Jo
But now it is getting to the stage where I'm actually going to rebuild a
store and move off Satchmo, starting next week.
I've reassessed the options in Python land, and I'm mostly
Based on what you described I think subclassing is your best bet.
Variations currently have some limitations and I don't think would
accomplish what you are trying to do.
(https://groups.google.com/forum/#!topic/mezzanine-users/kYzgBKcwSsg)
On Wednesday, February 26, 2014 4:40:19 AM UTC-7,
I should have read that more thoroughly, it's at
https://bitbucket.org/stephenmcd/cartridge/src/a39b3a3fe825a895c720907f29578d5dbefb552a/cartridge/shop/payment/stripe_api.py?at=default
It looks like this implementation still posts the credit card info to the
server and then directly charges that
Ahh thanks! I agree, don't want exposure of keeping CC #'s!
On Wednesday, February 26, 2014 11:53:20 AM UTC-6, Josh Cartmell wrote:
I should have read that more thoroughly, it's at
On Wed, Feb 26, 2014 at 1:35 PM, Tom Brander tombran...@gmail.com wrote:
Ahh thanks! I agree, don't want exposure of keeping CC #'s!
Cartridge does not store credit card data in any of the payment handlers.
--
You received this message because you are subscribed to the Google Groups
Hey Tom, here is a form that is in the demo site right now,
http://mezzanine.jupo.org/en/admin/forms/form/49/. Click the view entries
button near the upper right and it will let you look through, filter on the
entries.
I don't think you can update things, but you can delete old entries.
On
Hey Tom, in no case is the CC info ever saved to the database.
The distinction is whether your server ever even sees the CC info.
In Stripe's default use case your server is never sent the CC info, instead
Stripe takes the CC info and provides a token that allows your server to
create a charge
Ahh yes,, I love the way history is now being kept but that is history on
form edits on the admin side, as well as entry from the user (but only
available on the admin side), I need all the CRUD on the front end.. Not
admin..
So user signs in
creates data via form
may review data using page
There's an old outdated pull request that implemented something like what
you're talking about here:
https://github.com/stephenmcd/cartridge/pull/57
If I recall it applies a similar approach to Mezzanine's pages where
concrete inheritance stems from a base product, allowing custom product
Hi Stephen,
That pull request is very interesting. I'll play with it in he coming days.
Thanks.
On Wednesday, 26 February 2014 21:55:14 UTC+2, Stephen McDonald wrote:
There's an old outdated pull request that implemented something like what
you're talking about here:
Went to create a pdf invoice and got this error:
I am using Python #.3 if that makes a diff??
Does not give me much to go on the view invoice is working fine...
Traceback:
File
/home/tom/myvenv3/lib/python3.3/site-packages/django/core/handlers/base.py
in get_response
107.
On 27/02/2014 7:29 AM, Tom Brander wrote:
Went to create a pdf invoice and got this error:
I am using Python #.3 if that makes a diff??
Does not give me much to go on the view invoice is working fine...
Can you do a pip list for us?
Do you have pisa and reportlab both installed? What
Yeah I'm not aware of anything else in Mezzanine so that may be the way to
go. You could also just roll something of your own.
On Wed, Feb 26, 2014 at 11:39 AM, Tom Brander tombran...@gmail.com wrote:
Ahh yes,, I love the way history is now being kept but that is history on
form edits on the
The error is coming from sx/pisa3/__init__.py, line 43 which says:
{{{
if not REPORTLAB22:
raise ImportError, Reportlab Toolkit Version 2.2 or higher needed
}}}
Now, obviously you do have reportlab of a version higher than 2.2 but
there was a bug mentioned on the cartridge issues a
It's been awhile since I've used Cartridge in a project, but I have one
that I'm working on right now. I was pleased to see that Cartridge now has
tax support, but I'm running into some issues. Right now for my tax
handler I have:
total = request.cart.total_price()
if
Makes sense, so it should probably be converted to a string here (I think
the same thing for set_shipping):
https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/utils.py#L116
I'll give that a shot and if it works create a pull request, other than
that am I calculating the total in
I need something like this but not quite :) I have non-admin users that can
read the form entries so I'll need to figure this out as well. Possibly
edit them as well.
Dave
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from
Hi,
Would it be feasible to add an optional 4th element to the sequences for
FORM_EXTRA_FIELDS to add a widget for the new field? Trying to find the
simplest way to use django-datetimewidget with a Form Field date.
Thanks
Dave
--
You received this message because you are subscribed to the
18 matches
Mail list logo
