When built with the ghcdebug flag and started with --debug=-1 (or -2
to pause at startup, or -3 to pause before exit), hledger can be
controlled by ghc-debug clients like ghc-debug-brick or a custom
ghc-debug query script.
Also, refactor version string code.
The hledger-web tests have been cleaned up and now allow more testing
of command line options like (though still not everything).
Note tests now run the app listening on its default host and port,
127.0.0.1 and 5000, instead of "any IPv4 or IPv6 hostname" and 3000.
This would seem to mean hledger-web tests can conflict more with
things running on port 5000, eg a normal hledger-web instance, but I
haven't been able to reproduce it.
Changes:
1. rename the sandstorm "manage" permission to "edit"
(old permission names: view, add, manage;
new permission names: view, add, edit).
Rationale: "edit" best describes this permission's current powers, to users and to operators.
If we ever added more manager-type features we'd want that to be a new permission,
not a rename of the existing one (which would change the powers of existing users).
2. rename the sandstorm roles for consistency with permissions
(old role names: viewer, editor, manager;
new role names: viewer, adder, editor)
Rationale: it's needed to avoid confusion.
3. add a new option: --allow=view|add|edit|sandstorm (default: add).
'sandstorm' sets permissions according to the X-Sandstorm-Permissions header.
Drop the --capabilities and --capabilities-header options.
Rationale: it's simpler and more intuitive.
4. replace "capability" with "permission" in ui/docs/code.
Rationale: consistent with the above, more familiar.
Now not broken, https rather than http, and pointing to the "Data
formats" section, which has links to each of the file formats
(in case editing a non-journal file).
This is useful when serving on 0.0.0.0, such that querying from any
other device with <IP>:<PORT> does not fallback to 0.0.0.0:PORT,
which would fail.
Tested: Manually
This test appeared to have failed after adding source positions to
generated transactions. This is because the generated transaction id for
web pages appears to be dependent on whether the transaction has an
associated source file. Because it has one associated now, the id was
updated to be 'transaction-2-1' for instance, instead of
'transaction-0-1' as it would have been before. The fix is to change the
test.
