Dashboard multi-user setup

[m...@maikhoepfel.de]

Hello everybody,

I'm involved with Oscar because I'm building a classifieds website for motorcycle parts. Dealers sign up to list their items; I market them, and the sale is made between the dealer and the general public.

The first thing I'd like to tackle is reproducing the connection between dealers and products, and customizing the dashboard to the logged in dealer. 

The dashboard functionality will be a bit reduced from the sandbox version, mainly giving access to the dealer's products, orders and reports. To keep things simple, I'm not considering reviews, promotions and offers for the time being, and shipping will be handled by the dealers. 

Nonetheless, I'm starting to get into uncharted grounds with Oscar here (for me anyway), and would really appreciate a bit of feedback before I hack away. 

In my imagination, Oscar is almost there, which would be amazing. Each dealer (User instance) could get a OneToOne field to a partner instance. Product instances and order instances would have to be limited to one partner. The remaining work would then be overriding most of the dashboard app's views get_queryset functions to ensure that only the appropriate orders and products are displayed/used for reporting. Do you think that would work? Am I missing any major hurdles? Can it be that simple? Am I breaking any core concepts?

I'm more than happy to contribute back, so if you'd like to see anything of the above in Oscar, please let me know.

Thank you,

Maik

[m...@maikhoepfel.de]

For documentation purposes, here's how I ended up doing it. Quite similar to what I anticipated.

I've replaced the Partner model. AbstractPartner already carries a ManyToMany field to users (which is not used as far as I can tell). My model instead got a OneToOne field to users and duck-typing to ensure compatibility with Oscar. https://gist.github.com/4690160 

I create a Partner instance for every User via a post_save signal.

When a Product with StockRecord is created, Stockrecord.partner gets set to self.request.user.partner, and hence the connection is made.

The dirty work is overriding all the get_query_set functions in dashboard views to limit results to the logged in user. An example:

# views.py

class FilteredProductListView(ProductListView):

    def get_queryset(self):

        qs = super(FilteredProductListView, self).get_queryset()

        partner = self.request.user.partner

        return qs.filter(stockrecord__partner=partner)

So far, I haven't run into any issues with my solution.

Regards,

Maik

[Carlosedo]

Hi Maik, 

I'm working in a project with similiar behavior, dealers upload digital products so that users can buy them. I have been working on it and got to the same conclusion, I needed to modify the Partners model.

How is your solution working? Did you need to do any more changes?

I can see that you have a bit of experience with this and, as I am kind of new, I could really use your help.

Thank you!!

[Maik Hoepfel]

Hi,

above changes work fine for me, and I know somebody else who had success with it. What I forgot to document was that you have to override the get_login_decorator (or whatever it is called) function for the dashboard app and hand out login_required instead of staff_member_required, so that "normal" users can access the dashboard.

But, for both his use case and mine, it was needed to considerably reduce the dashboard functionality anyway, so there isn't too much overriding views involved. Depending on what you need from the dashboard, that could get messy.

So far, I also haven't come up with a good solution to get two dashboards, one for the dealers, and one for overall admin.

I've created myself an issue (https://github.com/tangentlabs/django-oscar/issues/574) to write some docs to collect the wisdom gathered so far. I'm also hoping I can sneak in some changes to adapting the dashboard less painful. (:

Cheers,

Maik

[Jonathan Meran]

Hey Mark,

I'm wondering how your experiences have been using Oscar for this type of business model. I too am creating a marketplace where designers sell to customers and we simply provide the marketplace for those transactions. I have been going back and forth between rolling my own solution and starting off with a base such as Oscar, Satchno, django-shop etc. One common theme I have noticed is that many of these frameworks do not have native support for multiple shops (sellers) and managing their transactions to buyers (or at least I haven't found documentation for it). Any feedback you can give regarding your experience with Oscar and other django e-commerce frameworks for this type of business model would be much appreciated.

Thanks you!

/Jon

[Maik Hoepfel]

Hi Jon,

there's two answers, really. I've documented changes to Oscar 0.5 above, and while I haven't gone live with my website, I think they're feasible and Oscar definitely gives is a much better choice than DIY or the other Django frameworks I looked at. This is the reason I got involved with Oscar in the first place.

Secondly, there's work under way for Oscar 0.6 which limits the products and orders a user can manage. This is aimed directly at the use case, basically allowing sellers to manage their parts, and their parts only. That is happening in https://github.com/tangentlabs/django-oscar/pull/732, and feedback is very welcome. If you send us a more detailed description of your scenario, we'll try to get support for it incorporated.

Further down the line is support for multi-tenancy, i.e. having more than one store front to all parts or a subset thereof. That is tracked in https://github.com/tangentlabs/django-oscar/issues/547, and will definitely happen. There's no ETA that I'm aware of though.

Again, you can make things move quicker by contributing code or requirements.

Cheers,

Maik

[Jonathan Meran]

Thanks Maik,

I appreciate the valuable and timely feedback. I am currently working on a startup company that has this marketplace scenario in which sellers manage their own "shops" and buyers can buy from 1 or more sellers (perhaps even in the same order which could make things interesting. We still aren't sure how important this requirement is). 

I would be more than happy to help with code contributions as well as requirements as I use the framework and see what is and isn't supported. I now feel more confident in the direction that Oscar as going as a feature-rich, yet fully extensible framework for Django e-commerce and will most likely try using it in our product. Here are a couple requirements that I can think of that I will run into:

1. Sellers having their own back-end to manage inventory, sales reports, shipping requests, analytics etc. We would likely create our own templates for this since our UI designs will typically not be satisfied by an "out-of-the-box" view provided by a framework. Is there typically a lot of out-of-the-box templates provided by Oscar? Are they easily replaced or extended? I have read a lot of the documentation and this seems to be the case which is great.
2. The ability to hold funds until some type of confirmation number from a shipping company can be verified by our system.

I look forward to playing with the framework and contributing back to the community in any way I can. If I feel I am extending Oscar in some way that could be made generic I will contact the project team and pitch the idea to you all!

Cheers,

Jon

[Maik Hoepfel]

Hi Jon,

I appreciate the valuable and timely feedback. I am currently working on a startup company that has this marketplace scenario in which sellers manage their own "shops" and buyers can buy from 1 or more sellers (perhaps even in the same order which could make things interesting. We still aren't sure how important this requirement is). 

When I'm not working for Tangent, I'm doing exactly the same - working on a startup that acts as a marketplace for sellers. For me, it's currently sufficient to split the order internally. Once payment gets trickier, I presume I'll have to implement order splitting similar to what Amazon does.

 

I would be more than happy to help with code contributions as well as requirements as I use the framework and see what is and isn't supported. I now feel more confident in the direction that Oscar as going as a feature-rich, yet fully extensible framework for Django e-commerce and will most likely try using it in our product. Here are a couple requirements that I can think of that I will run into:

1. Sellers having their own back-end to manage inventory, sales reports, shipping requests, analytics etc. We would likely create our own templates for this since our UI designs will typically not be satisfied by an "out-of-the-box" view provided by a framework. Is there typically a lot of out-of-the-box templates provided by Oscar? Are they easily replaced or extended? I have read a lot of the documentation and this seems to be the case which is great.

Oscar ships with a complete set of templates for a working store, this is the sandbox implementation. Every template is extensible or recplaceable though, you should not have any trouble tweaking the design.

 

1. The ability to hold funds until some type of confirmation number from a shipping company can be verified by our system.

I'm afraid I don't understand what you're trying to do. But payment logic is completely pluggable, so it's probably possible :)
 
Looking forward to hearing from you,

Maik

[David Winterbottom]

1. The ability to hold funds until some type of confirmation number from a shipping company can be verified by our system.

A common payment approach is to pre-auth (ring-fence) funds on a customer's bankcard when they checkout.  Then, when some later event occurs (eg items are picked for shipping) then a second "settle" transaction is performed to settle the money.  Most payment gateway (even PayPal) support this mechanism.

 

--
https://github.com/tangentlabs/django-oscar
http://django-oscar.readthedocs.org/en/latest/
https://twitter.com/django_oscar
---
You received this message because you are subscribed to the Google Groups "django-oscar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-oscar/8aa15780-b4e3-4a32-a1b5-c2313e184bfa%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
David Winterbottom
Head of Programming

Tangent Labs
84-86 Great Portland Street
London W1W 7NR
England, UK