Closed jb3 closed 1 month ago
Oh that's *$%ing sexy. Damn.
The layout does feel a bit 'tablet' to me, but that's a personal preference for sure.
I'll give it the in depth look it deserves shortly, but :star:. Nice.
Feels like we need better test data finance wise now! :laughing:
Now watch the stochastic test suite fail on the second run through...
Was seeing a critical application error loading the dashboard yesterday - went to investigate today and it appears to no longer be occurring? Weird...
Stochastic in all respects
Was seeing a critical application error loading the dashboard yesterday - went to investigate today and it appears to no longer be occurring? Weird...
I think this could be because I made the great application design decision of defaulting to all payments ever.
I'm going to swap it around to default to the smallest time period first and then I'll look at some query optimisation, this was just a starting point and there are some optimisations to be made to the ORM-generated SQL.
Average time to pay seems to be showing a slightly questionable number on the live data, as well?
Average time to pay seems to be showing a slightly questionable number on the live data, as well?
This was also noticed the other day with Alfie. I think this is a technicality that internal SU payments are all attributed to the same day.
I'm going to break it down by payment method to hopefully get some more sensible data.
Adds a new finance dashboard requested by Alfie which should allow for some interesting figures to be presented in the upcoming General Meeting.
This follows the same RBAC as other routes within the invoices section of the application so only trusted users can view this information.
Time periods allow for figures to be viewed for all time, for the last week, month or year.
The above screenshot misattributes payment sources as they are not part of the seeded data generated by the bootstrap script, though this data is accurately attributed in production.