Paginate donation viewer API

[echarlie]

Donation viewer does not paginate. This means it will break when large numbers (say >200,000) of fake donations are made.

[echarlie]

for my own reference, this means use https://docs.sqlalchemy.org/en/14/orm/query.html?highlight=limit#sqlalchemy.orm.Query.limit and https://docs.sqlalchemy.org/en/14/orm/query.html?highlight=limit#sqlalchemy.orm.Query.offset

[echarlie]

Okay. I actually read the code. We use datatables.net to provite magical table pagination stuff (and search, etc.)

Note: this means datatables is an untracked JS dependency, which needs to be updated!!!

Datatables does support server-side handling of data, however SQLAlchemy does not appear to support naïve queries like determining the length of a query (without making it, thus constructing the relevant object and using a crapton of memory in the process, but less network bandwidth at least), kind of critical for the AJAX parameters to be used. And since datatables is using AJAX then, rather than us pre-rendering the table and having datatables format, almost all of the content (including e.g. buttons) would need to be handed out via an API that doesn't yet exist. This is a non-trivial development effort, and would be kind of annoying for the scale we work at (very small). If we don't make lots of filtered queries, it may be acceptable to just cache the records_total and records_filtered values, but this will have limitations. EDIT https://docs.sqlalchemy.org/en/14/orm/query.html?highlight=limit#sqlalchemy.orm.Query.count is actually what I'm looking for to make this easy...

A naïve solution to the underlying vulnerability would be to just change admin/views.py#L100 to show only orders 1) within the past 6 months, and 2) only 5000 (or some configurable value). And then allow date ranges for more sophisticated queries.

The alternative is to reimplement almost all of the functionality of Datatables server-side: we know how to paginate the database, and we know how to add a "next" button. We can build search and (more sophisticated) filtering if we need it. This will slow down performance, but since very few people actually look at this data this may be acceptable.