Customers can View their Payments and Balance

Software improvement 5-Done
,
1

Specification
After a user has logged in going to /account takes them to a view of previous orders. Currently this is not overly useful as orders for all hubs and producers are mixed up together.

1: Users in the UK have asked to be able to see:

  • past orders (this exists already)
  • past payments
  • their balance
    Balance is specific to a Hub/producer so to implement this functionality users will need to be able to choose which hub/producer they are look at.

2: StroudCo currently allows users to see how much of their current order has been paid for via their current balance and how much they owe at checkout. @NickWeir has asked if this functionality can be included in OFN. This will take more thought on how best to implement. Paypal payments, for example, will need to be charged only the outstanding amount rather that the full amount on checkout.

account.jpg1600×1200 357 KB

Inspired by @oeoeaio’s work on the enterprise accounts page, we thought this page can take much the same format as it is a similar relationship one level down the fractal.

The diagrams includes the ability for a user to be able to see some of the information from the customers table. This will likely need to be configurable to hub, and therefore not included in the phase one implementation.

Phase One Functionality
A table of enterprises that the user has ordered from (most to least regularly), showing each balance.
Table rows can be expanded to show transaction history for the distributor.

3

Thanks for starting on this. Yes I can see that it is going to be tricky.

However, lots of the Stroudco shoppers do hold a credit balance on their account and use this to pay for orders. I guess the way this will work is if a shopper is shopping on a particular hub, then any balance they hold with that hub can be used on their order. - they wont be able to use that credit balance to buy from any other hub or producer.

Maybe the balance could show up only when they click to shop with a particular hub. Would that be easier to set up than giving shoppers the option to be able to select which hub/producer they want to check their balance with?

4

We’ve gone for the simplest solution, which I think is reasonably straight forward.

The current plan is to keep the format the same as exists… so leaving this in the area Accounts from the cog or url/accounts.

This is a page that is shown per user. So from here a user will need to be able to check anywhere they have shopped with or make payment to.

I think this is more straight forward than trying to find somewhere within the shopfront, after log in, that users can see their balance from. It would, however, be very useful for users to be able to engage with their balance during their shop and after checkout. I think this will be a future feature though.

5

This sounds fine as long as when they checkout they will see that their credit has been used to pay all or part of their order.

We also need to think about how the administrator will be able to adjust balances - adding credit when a regular standing order comes in, making a deduction if the shopper orders home delivery at the last minute, etc.

6

I don’t think balances themselves will be manipulated. This is done in StroudCo due to the bugs in the StroudCo system, not because adjusting balances directly is a good implementation.

7

Yes, completely agree we need to get away from the heath robinson fixes that have become normal around the Storudco software.

8

I have moved this page into feature/wishlist while on my info sorting mission … hope is ok, move back into development/doing when someone is assigned, you have a clear spec and is being built

9

Hi @stveep,
Really great that you are up for taking on the next challenge :smile:
This will be quite a big task with a steep learning curve. However I think it is a good one because I am doing a similar piece of work (which will involve a lot of angular implementation) and it will be a big learning curve for me as well. So we can perhaps help each other to work it out as we go?

Rob (@oeoeaio) has been working on some nice templates that we’ll be able to make use of to implement these respective pieces. Have a look at the implementation of the Enterprise tab if you log into OFN as an enterprise (not as super admin). The template for angular indexing with interactive drop downs will work well for this work.

@oeoeaio emailed this morning that he’s going to do some updates to his templates but perhaps next week we could have a skype with him and he can walk us both around his code a bit to help with the understanding.

10

Hi @stveep
As agreed on Monday, I have looked through the spec above and have nothing to add except thanks very much for taking this on and please let me know if it would help to talk through any detail. My phone is 01453 840037 and skype nickweir63
Thanks again
Nick

11

anyone object if I move this thread into development/doing? @stveep @lin_d_hop @oeoeaio @NickWeir

12

Go for it!!!

If that seems overenthusiastic it’s because there’s a 20-character minimum…

13

fine by meeeeeeeeee (23 characters!)

14

Been looking at this a bit more. As far as i can see, I this /account page is not using angular at the moment and I think the data comes in quite a spree-native way, though I can’t quite see where from. I assume its quite an old page. I can angularise it (well, I can try!) but want to make sure whatever I do is aligned with more recent and future front end development.

So I think my options are

  1. follow the kind of pattern in the /producers page (for example), providing the data via injection or
  2. use ng-resource as @oeoeaio has been doing for recent updates to the backend.

Hope I’ve understood it ok. Maybe these are not mutually exclusive? Anyway I wanted to ask whether there is any preferred pattern to use before I get stuck into writing it, or if you’re happy for me to just decide.

Cc @RohanM and @Kirsten

S

15

@stveep

Hey Steve, thanks for working on this!

Re data: stuff around users can be a bit tricky to follow down the rabbit hole, but once you know the right place to look it’s usually pretty easy to work out what is going on. As far as I can tell, the data for this page is actually being loaded by the spree_auth_devise gem, which declares the frontend UsersController and gives us a show method. All this method really does is load the @user and their @orders, which gives us all the data we need to build the view (which we have overridden in our own repository) at: app/views/spree/users/show.html.haml.

Re loading data for angular: I have been doing a bit of thinking about this, and the more I work with different pages the more I am coming to think that there is a place for both data injection using rails, and direct access to data using ajax requests and ngResource. I think the split depends on the makeup of the page, and it is often beneficial to use both within the one page.

I think in general: if the data set that you are thinking about (say a list of hubs/shops for this account page you are working on) is going to be static (ie. loaded once and then not updated or changed) then injection is a better way to load the data, because it removes the need for a dedicated route for fetching your data, as it can just be loaded by the controller when the user requests the page. This is particularly advantageous if you have a particular set of constraints on the data set that you are loading that makes it difficult to use the same route for other pages.

If on the other hand, you have a data set which you need to update, or one for which a route that does exactly what you need already exists, then using ngResource to load that route is a really nice clean way of making that data available to your app in a way that you can send CRUD requests to the server with relatively little work.

So I guess for this page, given that you might be wanting to allow the user to update payments on their orders or something like that, maybe using ngResource for that data set might be a good idea. However, for the list of hubs, that correspond to those orders (which you will want to load to that you can filter the orders), injection is probably a better fit, especially because the criteria for loading hubs is quite specific: you only want hubs that the user has actually shopped from - not an overly complicated query, but not one that really warrants creation of a dedicated route / controller action.

Anyway, that is just my currently thinking, very happy to hear your thoughts if you have any alternative ideas.

16

@oeoeaio hi, I’m far from being an expert on this area but I just wanted to check about terminology. Is it really “injection” when the data is retrieved on the server side and included as part of the page building process using views? I would have thought the injection method purely refers to using Angular to inject data into an already built page?

17

@pmackay

Hi Paul,

Sorry I didn’t make myself very clear there - I guess I am only talking about views built using AngularJS, and various strategies for making data available to AngularJS. By ‘injection’ I mean exactly the process you have just described: loading data in a rails controller and rendering into a script tag in the rails view, and from there making it available to AngularJS via a service. I would tend to describe this entire strategy as ‘injection’ rather than just the latter part of it, but I am happy to be corrected if that is a misuse of term. As far as I know, this is not a widely used method, and possibly therefore not a widely recognised term for what we are doing here.

I will admit that this is a slightly confusing because the term ‘injection’ is also used in angular-speak to describe the process of taking a service and making it available to another component (ie. controller, directive, etc.). While certainly related, I think that our use of ‘injection’ really just results in the declaration of a service (or value), which is then available for ‘injection’ (in the angular sense) into a component.

Perhaps we should come up with a better term for what we are doing?

18

Would it be worth drafting a wiki page that lists the different methods of presenting data? And give them names?

19

Yes, definitely. It’s on my to-do list. :smile:

20

Well I meant the same as @oeoeaio’s definition above (taking my cue from the inject_enterprises etc. methods in OFN), and now I think more about it this is different to injection in angular - but since the methods are named inject_foo this type of “injection” is much more obvious to people new to the project (like me!).

I decided to go with injection [in the OFN injection_helpers sense] for this in the end, since at least in this spec the page is just for information and I preferred to calculate the balances for each hub and organise the data within rails. I now have a basic page (needs styling) similar to the one in the photo with a drop-down table for each hub the user has shopped with showing the orders, and I can add payments in too, although the orders incorporate the payment status already.

account_tables.png1396×1110 41.9 KB

I was going to have the order numbers link to the order confirmation page showing what items were ordered, shipping info etc., but as far as I can see such a page doesn’t exist at the moment? I can see an orders/:id route but get the grumpy cat.

I had a couple of questions about the frontend while I was doing this, if anyone can answer:

  • Is there any framework used for calculating and displaying amounts of money in angular (similar to the Spree::Money system)? I saw that a currencyConfig object is injected in the common Darkswarm part of the page but not sure what this is used for.
  • Similarly, any nice way to format those dates and do we have a consistent OFN style? :smile:
  • Is there any clever way to generate links to rails routes, analogous to link_to helpers, in content that is rendered client side (like the table of orders here).

I’m still not clear about how credit balances can be implemented using the current software - but I did come across this gem:


which looks as if it could work. It allows admins to grant credit to Spree::Users that can then be used as order adjustments (i.e. to pay for stuff). I think it might be suitable if scoped to a hub. The 1-3-stable branch linked above seems to install ok without breaking anything at least.

21

I pushed the latest on this to the uk/account-balances branch. Tests pass but the build failed for some reason so @pmackay or @lin_d_hop could you take a look at it for me in buildkite? Hopefully we can get this on UK staging soon to see how it looks in the wild.

I think all the data we need are now there. I haven’t done the running total yet. @NickWeir is there anything else you need for Stroudco specifically?

I am not so hot on the front end stuff and having a bit of trouble with styling - e.g. getting the headings to take up the full width and making the table width consistent; see the screenshot below. Would someone mind either reviewing the code (see uk/account-balances branch, /app/views/spree/users) or screen sharing with me sometime to walk me through it? Not sure who would be best for this so just going to ping @danielle, @oeoeaio, @RohanM!

Pasted image700×462 40.6 KB