dustin/receipts/pipeline/head This commit looks goodDetails
Now that there are quite a few receipts in the database, scrolling to
the end to see the most recent entries is rather cumbersome. Let's show
the most recent receipts first, and hide older ones by default by
splitting the list into multiple pages.
The _Add Receipt_ form now has a _Restaurant_ toggle. When uploading a
receipt that creates or updates a Firefly III transaction, if the toggle
is activated, a special tag will be added to the transaction. The
assumption is that Firefly will have a rule to automatically adjust the
destination account, category, and/or budget for the transaction if this
tag is present. The tag is configurable and defaults to `Food & Drink`.
dustin/receipts/pipeline/head This commit looks goodDetails
Unlike the normal `<textarea>` element, `<sl-textarea>` uses a `value`
attribute to store the prefilled value of the field, rather than a child
text node.
Instead of sending the whole image file for every receipt shown on the
list page, we now generate thumbnails for them on the fly. This
dramatically reduces the amount of bytes sent for each image, especially
very large, high-quality photographs. It also improves support for
non-image attachments like PDFs, by rendering image previews in the
grid view instead of a broken image placeholder.
We use GraphicsMagic to do the conversion. Its `MagickWand` API is
pretty straightforward and convenient, and it supports a plethora of
image and image-like formats.
dustin/receipts/pipeline/head This commit looks goodDetails
The Add Receipt form can now create or update transactions in Firefly
III in certain circumstances:
* For existing transactions, if the description, amount, or notes
submitted on the form differ from the corresponding values in Firefly,
the Firefly transaction will be updated with the submitted information
* For gas station transactions, since Chase does not send useful
notifications about these, there is now an option to create an
entirely new transaction in Firefly, using the values provided in the
form
* Similarly for refunds and deposits, which we also do not get helpful
notifications about, the values in the form will be used to create a
new transaction in Firefly
This functionality should help cover most of the edge cases that
`xactmon` cannot handle.
The Add Receipt form now has a dropdown box that will automatically
populate the data fields from the properties of an existing transaction.
This will be helpful for the cases where the transaction was created
automatically, but still needs a receipt attached to it (e.g. Wal-Mart,
Target, etc. purchases and restaurants).
A receipt can now be deleted by clicking the little trash can icon on
its card on the receipt list page. To make this look nice, I had to
adjust some of the CSS for that page. Incidentally, I was able to get
the cards to be properly aligned by changing the images to be cropped
instead of scaled, via the `object-fit: cover` CSS property.
Rethinking the workflow again. Requiring the transaction to be present
in Firefly already will be problematic for two very important cases:
* Gas station purchase never show up in Firefly automatically
* HSA purchase show up hours or days later and have no information
besides the amount
These are arguably the most important cases, since they are the ones
that really need receipts in order to keep the transaction register
correct. Thus, we need a different way to handle these types of
transactions.
Really, what I need is a way to associate transaction data with an image
I really liked the original idea of storing receipts in Paperless, but
that ended up not working out because the OCR failed miserably and thus
made it impossible to search, so finding a receipt meant looking at each
image individually. I think, therefore, the best solution is to store
the images along with manually-entered data.
To implement this new functionality, I am using `sqlx`, a SQL toolkit
for Rust. It's not exactly an ORM, nor does it have a dynamic query
builder like SQLAlchemy, but it does have compile-time checking of
query strings and can produce type-safe query results. Rocket has
support for managing its connection pools as part of the server state,
so that simplifies usage quite a bit.
On the front-end, I factored out the camera image capture into an HTML
custom element, `camera-input`. I did not update the original form to
use it, since I imagine that workflow will actually go away entirely.
It turns out the cropper is _way_ too hard to use on mobile. The
cropper handles are much too small for a touch screen. Maybe I can
figure out how to improve the UX eventually, but for now, Tabitha
requested that we remove that functionality.
And now we come to the meat of the thing: the ability to update
transactions and attach receipts. Most of this is straightforward,
except for changing the amount of split transactions. Hopefully, this
won't come up too often, since I can't really split transactions without
a receipt. Just to be on the safe side, attempting to change the amount
of a split transaction will return an error.
This is all pretty straightforward. The only real problem is that
the search results only contain matching transactions *splits*. Since
transactions themselves do not have an amount, the value shown in the
_Amount_ column on the transaction list may be incorrect if a
transaction contains multiple splits and some of them do not match the
search query.
Dustin