Openfoodnetwork: As a producer, I can see a hub's customers firstname and name

Created on 27 Mar 2020  路  17Comments  路  Source: openfoodfoundation/openfoodnetwork

Description

- As a: enterprise manager, producing for a hub
- On page: On all of the following reports:

  • Orders and distributors (one column: Customer name)
  • Bulk Co-op (one column: Customer name)
  • Order Cycle Customer Totals (one column: Customer name)
  • All Customers (name and first names are two columns on these ones!)
  • Enterprise Fee
  • All Order Cycle Management (name and first names are two columns on this one!)
  • All Sale Tax
  • Xero invoices
  • All packing reports (name and first names are two columns on these ones!)

- I want to be able to do: see the names and firstnames of the hub customers. For that the hub has to enable shop preferences as seen in #5054

Acceptance Criteria & Tests

Scenario 1: A hub allows a producer to see the names

  1. As a supplier of the hub who enabled the shop preferences
  2. I go to /admin/reports/ and I try any of the listed reports above with a filter on the hub
  3. I can see online (or as a spreadsheet) any customer names or first names but not their emails or phone numbers

Scenario 3: The hub switch back to "no"

  1. As a hub, I can follow the same steps as in scenario 1, but then I change my mind and switch back the settings to "no"
  2. As a producer, when I hit "search" the table I see online (or as a spreadsheet) customers name and firstname hidden as well as emails and phone number.
  3. I can see a sentence if names and firstnames are hidden, please contact your hub and ask him to update their shop preferences above the search button.

image

  1. This scenario is the default scenario for any hub's suppliers.

Most helpful comment

@Matt-Yorkley thanks for raising this. Here are some feedbacks:

Maybe we just show the message if the current user manages any producer enterprises..?

Yeah I think this was the idea of the "if": not to introduce too many checks and just show the message to everyone. Yes it makes a more crowded page, but this can be reviewed once we really work on UX/UI for reports?

It's less concise though 馃槖

Yours is clearer indeed. But don't forget any instance manager will be able to update it in translations. So maybe you can go with yours and if something shorter is found we can change in Transifex later?

All 17 comments

@sauloperez do we make the sentence translatable in a way anyone can add a link to the user guide? I don't remember if we decided on this.

I don't think we actually decided it but I would go for it, yes.

wouldn't even be better to show a tooltip from the word "hidden" in the report itself? the more in context the information is, the better for users to understand, right? I'm even thinking we could link to the settings section from that tooltip so no one gets lost. This way many more users would discover this, I think.

@sauloperez I don't think this is a good idea... First reason a tooltip within a table is a bit weird (a title would be ok, but within a table... I'm not sure 脿 already saw something like this), and second a lot of people will also just download the csv. So it should work in both cases.

@RachL just wondering about emails and phone numbers - I don't clearly remember the conversation - seems like email and phone number very useful if customer doesn't actually rock up to collect the thing? Or producer needs to call customers i.e. to ask how they want someting. But probably we discussed this and decided not? At this point - with requests from farmers markets etc escalating - I'm tempted to think we should include by default and revisit later?

@RachL once clear on the above - these seem reasonable to go into Welcome New Devs with label AU - as potential projects for enthusiastic recruits?

First reason a tooltip within a table is a bit weird (a title would be ok, but within a table... I'm not sure 脿 already saw something like this),

I mean one of these little tooltips we have in many places (link title)

and second a lot of people will also just download the csv

It'd great to be able to compare downloads vs in-app views

@sauloperez that's easy. For France at least _none_ of the reports are usable as they are. You always need several reports or what to print it. So everyone downloads to do stuff in a spreadsheet.

I mean one of these little tooltips we have in many places (link title)

Yes but we don't have them inside a table.

So everyone downloads to do stuff in a spreadsheet.

that's very useful information that can influence decisions :+1:

In Canada too - everyone needs information from multiple csvs to do what they want to do - so everyone downloads and cuts and pastes each week - because they don't have skills (and neither do I) to do more sophisticated things like scripts.
Re: emails & other contact info...... I THINK this was something you mentioned @RachL ? If the hub is agreeing to let the supplier see the names.... does it matter if they also see the emails and addresses? Originally when we talked, I thought suppliers did not need customer contact info, because our use cases were wholesale shops with a relatively short list of customers, so easy for a supplier to get a list of contact info that works for the whole season. BUT - here, COVID is changing that. most farmers markets (as hubs) are asking suppliers to pack (so need the name) but also to deliver to the customer's home. (address needed). Markets are also asking suppliers to communicate items that are not available directly to the customer (email needed).

@tschumilas @kirstenalarsen re emails and phone numbers, these are my notes on discourse:

We agreed that displaying customer names and firstnames only would already answer 90% of the need. This seemed a good way to compromise between shops who don鈥檛 want the producer to get the credentials, and shops who do need them.

Releasing names only first can help us get feedback on how many people will really need the full credentials (emails, phone number etc), and then iterate.

If we include them, we need to push ToS and ToC of hubs in production before this. Indeed the hub would need to have consent from the shopper to share its credentials to the producer...

ok cool, go with it as is and let's get feedback

I'm not sure how to implement showing/hiding the message: If names and firstnames are hidden, please contact your hub and ask him to update their shop preferences in a way that makes sense. In various cases the enterprise user might manage multiple producers and hubs, right? Or: they might manage two producers, and one of them supplies a hub that allows customer names and the other supplies a hub that does not. Or: if the user only manages a hub, we shouldn't show this message, right?

Maybe we just show the message if the current user manages _any_ producer enterprises..?

I think the wording could be a bit clearer as well... maybe:

If customer names are hidden for orders you have supplied, please contact the distributor and ask them to update their shop preferences to allow their suppliers to view customer names.

It's less concise though :unamused:

@Matt-Yorkley thanks for raising this. Here are some feedbacks:

Maybe we just show the message if the current user manages any producer enterprises..?

Yeah I think this was the idea of the "if": not to introduce too many checks and just show the message to everyone. Yes it makes a more crowded page, but this can be reviewed once we really work on UX/UI for reports?

It's less concise though 馃槖

Yours is clearer indeed. But don't forget any instance manager will be able to update it in translations. So maybe you can go with yours and if something shorter is found we can change in Transifex later?

Closed by #5769

@sauloperez and @Matt-Yorkley I was reviewing this today and noticed that all customers see the checkbox in Shop Preferences in the Dashboard. Was that the intention, or should it only be shown for Hub enterprises (ie. those that distribute products from other suppliers?).

@emilyjeanrogers yes that was the intention, we didn't put an extra filter on that. It's something we can improve in the future, but as anything we show only in some cases, we need to be careful on how it is tested.

Was this page helpful?
0 / 5 - 0 ratings