Dynamic and customisable reports

Software improvement
1

In his ‘spare time’ the amazing @oeoeaio has been playing with a tool called UI-Grid which is an angular plug-in thing to build dynamic tables. He has been exploring its use for reports in OFN by applying it first to the Orders & Distributors report, to help inform a decision as to whether this is going to be a good thing to do

If it is, if will give us a bunch of functionality ‘out of the box’ like:

  • ability to sort and filter columns
  • hide and re-order columns
  • view summary lines or expand to line items (where there are groupings)
  • export and print to csv and pdf

Creating this page to help us organise how it would be done and by who, if we do go ahead

Phase 1: Replicate existing functionality

  • Rob to complete implementation of Orders & Distributors (OD) report so we can put it in staging and all have a play with it [Question: should keep the old version too so we don’t stuff up people who are using it?]
  • Work out which other reports need to be converted i.e. do we need to do them all, or there are some core reports which create the ‘base’ reports, from which the different versions can be made on the fly
  • Assess priority needs - which new reports and for who
  • Transfer required reports to new system

Phase 2: Customise and Retain

We will want people to be able to save their report settings e.g. the column configurations and sorting preferences etc.

This will require thinking / scoping

2 Likes
2

That’s great!
Having a tool that could enable a hub to build up its own custom report would be awesome.
One thing is missing today and needed by some hubs in France, is the ability to filter total by distributor by shipping option (some hubs propose various pick-up points as shipping options, and need to have part of the food deliver at one point and part at another, so need this info in the report).
Anyway, we can have some pre-established reports, or we could have a report builders tool that could enable easily a hub to build up its own :slight_smile:
Let’s try in staging before telling if i can replace the old version… I would says if it offers the same (or better) functionnality, that it could replace, but let’s test first and we’ll ask some involved users :slight_smile:

3

This sounds pretty good but I have a few doubts.

First of all, I would like to understand how this fits in our priorities. Is it something we would work on right away? I understand that all instances have their own needs in terms of reports but are they the top priority? Where can I check the backlog of tasks ordered by priority anyway?

From the technical standpoint, I have many concerns on the reports implementation on the backend. We have lots of duplicated logic, code hardly changeable and poor test coverage. Although UI Grid does all the magic on client side once the data is loaded from the backend (meaning there are no more requests to the server after that, is this right?), I assume this feature would require at least some tweaks on the backend. Because of the aforementioned quality of the reports codebase this would have a considerable impact on development.

We will want people to be able to save their report settings e.g. the column configurations and sorting preferences etc.

We all need to be aware that things like these :point_up: have a big development and testing cost and introduce a lot of complexity on the codebase, which will later get on the way when fixing bugs, tweaking the feature, etc. It is something we all tend to forget and find out when it’s too late.

Also from the performance perspective, we have some issues yet to solve. See the list of issue s in GH. Some ways to fix them are to improve the SQL queries, better database indexing and use pagination among others. However UI Grid’s pagination support seems to be still in an early stage. This means some of these problems would still persist unless we find a clever way to implement our own pagination (reloading the grid with data from the next page?).

Finally, something that we all have come to see in Katuma is that reports will hardly meet all the requirements of all OFN instances (they won’t even meet the needs of all the hubs in Barcelona!). By trying to meet all of these we risk turning OFN’s reports into an unmanageable complexity monster, both in terms of product and development.

To that end, this week we informally (a long after-lunch) started considering what a per-instance modular solution would look like and what approaches we could have. This however, needs to come after a production decision.

I apologize if any of this items is already covered somewhere else but I couldn’t find a broader discussion around reports in the community. I hope this brings some more arguments for the discussion anyway.

1 Like
4

In Canada we would also be excited about customizable reports - we have identified a rather urgent need for a report that isolates and totals all different types of fees (and taxes) in an order cycle for example - Report that isolates various 'fees'

I don’t understand the technical issues that @sauloperez raises - but am struggling to find a way forward. I think that we are going to find that overtime instances begin to look more similar (not more diverse) in terms of the ecosystem of enterprises/groups/networks/communities that are making projects on the platform. The sustainable community food spaces around the world are struggling with the same issues and getting more and more connected and learning from each other all the time. So it seems to me, that we’ll see a convergence, not divergence, in terms of the kinds of reports needed. IMHO.

5

I would like to agree on this point! But the reality is that OFN, as a product, has been stretched to cover the needs of hubs and producers from all over the world and many times that kind of adaptation/customization was our only way to convince some hub to use OFN.

I know that this is not the right thread to talk about it but we must be aware that we must take decisions at product level about which direction we want to go: super customizable fit-them-all thing or a platform that enforce that kind of “re-use” of best practices around the world? And this is not a negative note at all, I’m actually really excited about the point where we are and the different directions we could take. We just need to take some decision together and focus our (scarse) resources on that.

:muscle: we can do it!!!

1 Like
6

I like the way you put this @enricostn - and sorry if I sounded like I was in favour of OFN only being a platform that enforces ‘re-use’ of practices. I like the idea of customizability. Indeed for 20 years all of I done is social science research into ‘alternative’ and ‘sustainable’ food systems around the world - and what I know more than anything is that context matters. Context shapes everything - which is why things need to be customizable. BUT I was responding here to only the reports question, and the challenges raised by @sauloperez and concern that we risk turning OFN reports into a complexity monster :slight_smile: (which sounds like my job most days). I was trying to say that we might be able to find a ‘middle ground’ on the reports question - between total customizable and what we have now. After all, there are a liminted number of different variables here - there are only so many ways they can be cross-tabbed.

7

agree, this is an exciting discussion