| Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
Bills and transactions can now be exported to json or csv
ref #28
|
|
ref #173
|
|
Checking item was broken when clicking on the label instead of the checkbox
|
|
|
|
Fix #173
Rewrite multi select widget as a template in order to have all values properly escaped.
|
|
WIP: Upgrade to bootstrap 4
|
|
|
|
Fix a regression introduced with BS4 update.
|
|
Allowing the modal to extend; thus "natural" page scrolling allows to see the
whole popup.
|
|
Actually switching to maintained fork at
https://github.com/uxsolutions/bootstrap-datepicker ; the original project
being unmaintained since 2012.
- Works with recent jQuery
- BS4 is not supported by bootstrap-datepicker, but actually, it works :-)
ref https://github.com/uxsolutions/bootstrap-datepicker/issues/1670
|
|
- modal classes and hierarchy changed since BS2
- striped tables are now handled by css3 pseudo-class rather than classes
- fix placement/alignment for the button and comment above the table
|
|
BS4 provides larger touch-friendly controls anyway.
|
|
Trying to keep same look'n'feel.
|
|
Also fixed some weird alignment issues.
I think this will need more work later (revamp the navbar layout to avoid that
sensation of thing which are floating at random places in the navbar).
|
|
There was no label, which is bad for accessibility.
|
|
|
|
- Adapt to BS4 class names and hierarchy
- Redesign some forms to have the label above the input (mobile-friendly)
- For the remaining inline form (add bill), use the grid, as BS no longer
provides inline form alignment helpers
|
|
|
|
Improve translation for user edit form.
|
|
|
|
|
|
Fix deprecation issues (ExtDeprecationWarning)
|
|
|
|
Fix unit test rounding
|
|
Test was Ok but failed due to some floating point errors.
|
|
Fix ServerTestCase.test_unprefixed test
|
|
Optimise sql queries
|
|
Fix zero-amount transfers and other rounding issues
|
|
Sort bills by (date.desc, ID.desc) instead of just date.desc
|
|
The test was always failing, actual reason is the `app.run.configure()` fails
to reset the `APPLICATION_ROOT` setting which `ServerTestCase.test_prefixed`
overloads (side effect).
This patch *do not* fix app.run.configure as it seems uneasy, but takes a
different approach which has the advantage of making the test more explicit.
Would still be a good thing to investigate more on configure().
Fix #163
|
|
A user with a "0.00" balance would have either a "+0.00" in green or a
"-0.00" in red, depending on the exact value of the floating-point value.
Fix this by simply rounding to 2 digits before comparing to zero.
|
|
This workarounds a rounding issue caused by the (incorrect) usage of
floats for bill amounts.
This fixes #138
|
|
|
|
When viewing the list of bills, bills are (correctly) sorted by date. But
the order of all bills for a given day is not intuitive: I would expect
bills to be sorted by reverse order of insertion. That is, the last bill
to be added for a given day should appear first, not last. Otherwise,
when adding several bills in a row for a given day, it's confusing to see
that the new bills do not appear on top of the list.
Fix this by sorting by decreasing ID after sorting by date.
|
|
This avoids creating thousands of small SQL queries when computing the
balance of users. This significantly improves the performance of
displaying the main page of a project, since the balance of users is
displayed there:
Before this commit: 4004 SQL queries, 19793 ms elapsed time, 19753 ms CPU time, 2094 ms SQL time
After this commit: 12 SQL queries, 3688 ms elapsed time, 3753 ms CPU time, 50 ms SQL time
Measured request: display the sidebar with the balance of all users for the project (without displaying the list of bills)
This commit also greatly improves the performance of the "settle bills" page:
Before this commit: 8006 SQL queries, 39167 ms elapsed time, 39600 ms CPU time, 4141 ms SQL time
After this commit: 22 SQL queries, 7144 ms elapsed time, 7283 ms CPU time, 96 ms SQL time
Measured request: display the "Settle bills" page
Test setup to measure performance improvement:
- 5 users with various weights
- 1000 bills, each paid by a random user, each involving all 5 users
- laptop with Celeron N2830@2.16 GHz, SSD Samsung 850 EVO
- sqlite database on SSD, using sqlite 3.15.2
- python 2.7.13
- Flask-DebugToolbar 0.10.0 (to count SQL queries and loading time)
Performance measurements (using Flask-DebugToolbar on the second request,
to avoid measuring cold-cache performance):
- number of SQL queries
- elapsed time (from request to response)
- total CPU time consumed by the server handling the request
- total time spent on SQL queries (as reported by SQLAlchemy)
|
|
By defaut, SQLAlchemy uses lazy loading, which means that displaying n
bills will generate around n queries (to get the list of owers of each
bill). Pre-load the list of owers to drastically decrease the number of
SQL queries.
Before this commit: 1004 SQL queries, 7535 ms elapsed time, 7536 ms CPU time, 530 ms SQL time
After this commit: 5 SQL queries, 3342 ms elapsed time, 3393 ms CPU time, 15 ms SQL time
Measured request: display the list of all bills for the project (without displaying the sidebar with balances)
Test setup to measure performance improvement:
- 5 users with various weights
- 1000 bills, each paid by a random user, each involving all 5 users
- laptop with Celeron N2830@2.16 GHz, SSD Samsung 850 EVO
- sqlite database on SSD, using sqlite 3.15.2
- python 2.7.13
- Flask-DebugToolbar 0.10.0 (to count SQL queries and loading time)
Performance measurements (using Flask-DebugToolbar with the second
request, to avoid measuring cold-cache performance):
- number of SQL queries
- elapsed time (from request to response)
- total CPU time consumed by the server handling the request
- total time spent on SQL queries (as reported by SQLAlchemy)
|
|
Enable Travis CI
|
|
|
|
|
|
Change ihatemoney.notmyidea.org → ihatemoney.org
|
|
As the old domain seams dead and not even redirecting.
|
|
Allow negative bill amounts
|
|
|
|
Convert readthedocs links for their .org -> .io migration for hosted projects
|
|
REST API doc precisions
|
|
|
|
… And use a multi-valued example, as it's IMHO the "standard" use-case with
IHM.
|
|
|