web feature request: remove transaction [$5]

[tantalor]

Should be able to delete an entry or remove transaction from the web ui.

--- There is a **[$5 open bounty](https://www.bountysource.com/issues/31702135-web-feature-request-remove-transaction?utm_campaign=plugin&utm_content=tracker%2F536505&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F536505&utm_medium=issues&utm_source=github).

[simonmichael]

Can we have some rationale/real-world examples where this is needed, and let's do some design thinking, to help move this forward.

• When/why is this needed, rather than editing the journal file ?
• Is it useful without access control ?
• Does it need to be possible to disable it ?
• Which storage formats should be supported ?
• How should concurrency be handled ? Eg if someone else changes the file between rendering the page and processing a delete request.
• How should the right entry (and its end) be located robustly in eg a journal file ? With journal format at least, transactions know their file, start position and transaction index within the whole journal, but the position and index can change if any changes are made earlier in the journal.
• How should multiple included files be handled ?
• As the first data-destroying operation in *ledger, how should edit history be handled ?

[sirtimbly]

When/why is this needed, rather than editing the journal file ?

For a user that can only access the application through the web interface on a hosted environment such as sandstorm.io. Otherwise a user has to download a copy of the file as a backup, edit the backup and re-upload the file in the proper archive format.

Is it useful without access control ?

Dangerous. Assuming access control has been handled through some other mechanism, again, see sandstorm.

Does it need to be possible to disable it ?

No. Configurable settings are to be avoided.

Which storage formats should be supported ?

Which ones are available? Normally this would be persisted in a sql database.

How should concurrency be handled ? Eg if someone else changes the file between rendering the page and processing a delete request.

This is a great point. Again, see SQL databases. The ability to lock a file for transactions is one option. I would like better having an intermediary store of pending updates and a journal updater service that negotiates those updates logically and maintains consistency in the file. It then streams websocket events of successful updates back to the client... yeah, I'm probably over architecting it...

How should the right entry (and its end) be located robustly in eg a journal file ? With journal format at least, transactions know their file, start position and transaction index within the whole journal, but the position and index can change if any changes are made earlier in the journal.

Hash of operation datetime, amount and title? base58 check encode the hash, insert as a special comment... feels wrong.

How should multiple included files be handled ? As the first data-destroying operation in *ledger, how should edit history be handled ?

I like the idea of a crypto signature based audit trail. The details of the operation are hashed and signed along with the previous signature/hash. Creating a chain of verifiability (kinda like the bitcoin ledger).

[simonmichael]

Thanks!