Add a description of Match Groups to the manual; Section "Matchers".
Include two examples.
Clarify a description of regular expression features with respect
to match groups.
Expand the description of field assignments to cover match group
interpolation, cross-referencing to Section "Matchers" for the full
description.
Signed-off-by: Jonathan Dowland <jon@dow.land>
Add functional tests for matching substrings in field matchers and
interpolating them into the corresponding field assignments. Check
the following properties and use-cases:
* Use-case 1: matching a portion of a date in a known format
(YYY-MM-DD) and writing a comment-command to warp a posting date.
Useful for credit cards.
* Use-case 2: match a portion of a CSV field and use it as an
account assignment. Useful for my byzantine setup with two
separate ledgers cross-importing to each other.
* Ensure bracketed portions of field matchers are captured.
* Ensure bracketed portions of record matchers are captured.
* Check match token numerical offset is relative to match group,
not the whole rules file.
* Check nested matches work.
* Ensure match group token expansion works with or without
surrounding text.
Signed-off-by: Jonathan Dowland <jon@dow.land>
Replace occurrences of '\N' (where N is a positive number) in field
templates with the corresponding regular expression match group, if it
exists.
E.g. Warp the date to the first of the month for the second posting
if %date (....-..)-..
comment2 date:\1-01
E.g. Strip a prefix from an imported account name
if %account1 liabilities:jon:(.*)
account1 \1
Fixes#2009.
Signed-off-by: Jonathan Dowland <jon@dow.land>
All commands that suport csv output now also support tsv output. The
data is identical, but the fields are separated by tab characters and
there is no quoting or escaping. Tab, carriage return, and newline
characters in data are converted to spaces (this should rarely if ever
happen in practice).
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