Repository: django-oscar/django-oscar

Issue:
Improve documentation about dashboard partner permissions
In the dashboard order list orders are filtered with respect to the partner permissions (for non-staff users), so that partners see orders with stock records they own - https://github.com/django-oscar/django-oscar/blob/master/src/oscar/apps/dashboard/orders/views.py#L123-L124

Despite that, in the order detail page partner sees **all** order lines, which belongs to the other partners too. In the multi-vendor projects even though partners treated as suppliers, it does not make much sense for me to display all lines and not only relevant ones.

Thanks @mightym for the observation.

@solarissmoke @mvantellingen WDYT?


Discussion:
Duplicate of https://github.com/django-oscar/django-oscar/issues/2240 .

My personal view is that Oscar's default behaviour is sensible - there may be reasons why partners need to see the rest of the order (e.g., to coordinate shipping, or to check whether the order is paid in full before releasing goods). 

Projects should override that view if they want to restrict what partners can see. This is because the logic of what to display to the partner is likely to be project-specific. e.g., can a partner see the shipping cost for the order? or should they be able to edit the status of the whole order? or do they need to see payment status for the order as a whole?
Right, makes sense. I suppose we'd add note to the documentation highlighting this.
From my perspective this usecase is quite rare: " there may be reasons why partners need to see the rest of the order (e.g., to coordinate shipping, or to check whether the order is paid in full before releasing goods).". But I hear you. Maybe this could be handled like you currently already do with the dashboard access for users (Full dashboard, limited dashboard). And just add there another option. 

Anyway, I think if this is the case then at least order lines need their own shipping costs per partner. Thats something independent from the topic if a partner can see other partners orders. 

Also from a "marketing" perspective pro oscar I think this should be more clear. It would help if that feature is better carved out for people. I've chosen oscar because of the partner mechanism. But I expected it to work like on amazon or other shops where you have partner shops inside the shop. 
> From my perspective this usecase is quite rare: " there may be reasons why partners need to see the rest of the order (e.g., to coordinate shipping, or to check whether the order is paid in full before releasing goods).". But I hear you. Maybe this could be handled like you currently already do with the dashboard access for users (Full dashboard, limited dashboard). And just add there another option.

Despite I haven't met this use-case too, I agree with @solarissmoke that project-specific cases anyway need customizations, hence I don't think it can be universal solution there. However, we can make order detail page a bit more flexible for this kind of customization - move order lines query to the separate method or etc.

> Anyway, I think if this is the case then at least order lines need their own shipping costs per partner. Thats something independent from the topic if a partner can see other partners orders.

Quite different topic, but I already encountered potential necessity of multiple shipping lines per order on my projects. Although, not sure if this particular change would be enough for full-fledged multi-vendor support on the marketplace projects.

> Also from a "marketing" perspective pro oscar I think this should be more clear. It would help if that feature is better carved out for people. I've chosen oscar because of the partner mechanism. But I expected it to work like on amazon or other shops where you have partner shops inside the shop.

Yes, documentation improvement is something that will always be useful. If we made it more clear - it would allow to set more proper expectations and more accurately estimate efforts.
I had raised the same issue sometime back since i felt that  partners should not be concerned with the other items that the customer orders. I mean in most cases, a partner only cares about the movement of their product and if shipping needs to be coordinated, i thought that responsibility should go to the person running the site. Also in my version the partner could not only see the orders but he could also edit them so i thought that it can pose some sort of integrity issue.

Anyway, I am glad you guys are discussing this.

Resolving patch:
diff --git a/src/oscar/apps/dashboard/orders/views.py b/src/oscar/apps/dashboard/orders/views.py
--- a/src/oscar/apps/dashboard/orders/views.py
+++ b/src/oscar/apps/dashboard/orders/views.py
@@ -448,6 +448,9 @@ def get_object(self, queryset=None):
         return get_order_for_user_or_404(
             self.request.user, self.kwargs['number'])
 
+    def get_order_lines(self):
+        return self.object.lines.all()
+
     def post(self, request, *args, **kwargs):
         # For POST requests, we use a dynamic dispatch technique where a
         # parameter specifies what we're trying to do with the form submission.
@@ -481,7 +484,9 @@ def handle_line_action(self, request, order, action):
         if len(line_ids) == 0:
             return self.reload_page(error=_(
                 "You must select some lines to act on"))
-        lines = order.lines.filter(id__in=line_ids)
+
+        lines = self.get_order_lines()
+        lines = lines.filter(id__in=line_ids)
         if len(line_ids) != len(lines):
             return self.reload_page(error=_("Invalid lines requested"))
 
@@ -525,6 +530,7 @@ def get_context_data(self, **kwargs):
         ctx['note_form'] = self.get_order_note_form()
         ctx['order_status_form'] = self.get_order_status_form()
 
+        ctx['lines'] = self.get_order_lines()
         ctx['line_statuses'] = Line.all_statuses()
         ctx['shipping_event_types'] = ShippingEventType.objects.all()
         ctx['payment_event_types'] = PaymentEventType.objects.all()


Test patch: