vmelnalksnis / gnomeshade Goto Github PK

Maybe it's worth splitting transaction dates and times, so that times can be separately nullable. Some sources, for example bank reports, only give the date.

Also - maybe it's worth moving to https://nodatime.org/.

• Rename project from Tracking.Finance to VMelnalksnis.Gnomeshade
• Move from Azure DevOps to GitHub Actions CI/CD
• Configure GitHub repository

• Add PUT endpoint for products
• Edit imported product
• Add PUT endpoint for transaction items
• Replace imported product with new one
• Replace imported product with existing one
• Update product amount and other transaction item fields

Should it be possible to also change Source/Target account directly? Or should the be left to account merging?

Currently source/target amount is simply summed ignoring accounts

• Product list after creating/updating
• Unit list after creating/updating
• Unit create button after updating multiplier
• Transaction item list in transaction detail view after adding

All current importable report examples have single transaction item per transaction, so it will be necessary to split the single item into multiple.

• PUT endpoint for updating a transaction with all items
• Split transaction item into multiple from/to the same account, but different product

The current balance of users accounts should be calculated and displayed, maybe in account overview?

It would be easier to check against invoices/receipts.

Once a somewhat stable state has been reached, mutation testing should be added with https://github.com/stryker-mutator/stryker-net.

• Import a camt.052.001.02 BankToCustomerAccountReportV02 report
• Detect transactions that were already imported
• Provide summary after import of imported data and created entities
  Apply user defined transformations during import

Currently it is hard to spot whether a transaction deposits or withdraws from the users accounts.

All transaction items should be visible in the transaction overview.

A single bank reference should not be used in multiple transactions.

The viewmodels/logic of avalonia applications should be extracted to another project, Avalonia.Core, and only the views/desktop specific logic should remain in the Desktop project. That should make it easier to add more interfaces, for example a mobile app.

Currently ViewModelBase<TView> specifies a single view for a view model, which is wrong since there can be multiple different views for the same view model. The type parameter should be removed from ViewModelBase, and ViewBase<TViewModel> should be added.

Need to add some way to categorize or tag transactions/transaction items.

Build locally with the same parameters produces the expected result, however release artifacts don't have assembly information, e.g., version and copyright information.

The current transaction/transaction item model does not allow to express a transaction were money was withdrawn from multiple accounts, and were the amounts don't match up with purchased products.

For example see the following transactions:

• purchased an item for $10
• delivery for said item for $5
• paid $7 from paypal
• paid $8 from bank account

By default all requests made from desktop app use HTTP/1.1. The quick solution would be to set client.DefaultRequestVersion = new(2, 0);. However, if HttpClient does not fallback to previous versions, this could be a braking change, so it should be configurable.

After importing transactions each table shows only 2 data rows. Something probably changed after Avalonia update.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-argument-validation

Introduced in #112

Currently the only way to 'update' and existing transaction item is to split it into a single, new item.

Currently the workflow of

1. import data from bank
2. update imported transaction with extra data

works, however the other way has not bee tested. Currently transaction are only matched using the bank reference, which would have to me manually entered for each transaction so that it is correctly matched during import.

The first solution that comes to mind would some sort of rule engine, were the user could define rules how to match the input data to existing transactions. That would also allow to automatically add accounts to existing counterparties, instead of always create a new one which then needs to be manually merged.

The rules should probably be defined on either API models or database entities, so that each different import type can map the data, and then it can be matched. Of course, need to be careful not to over complicate the abstraction and initial implementation. Currently only one type of import is support, and a need for another is not immediately visible.

After signing in with an oauth2 provider in the desktop application, the token is not refreshed.

At the very least, the token should be refreshed when calling the API if nearing expiration.
Maybe also should continue refreshing the token even if not doing anything for some period, so that frequent login is not required.

Currently both the API and desktop application is published as self-contained single-file applications. Self-contained applications also support trimming, however some of the potential issues outlined in the documentation are applicable. From initial tests trimming reduced the output size by about half, but generated a lot of warnings and probably removed code that was actually used.

Currently the base address can only be set by modifying the appsettings.json file, however it should be possible to set it from the application before logging in.

When importing data it's usually too granular, however when manually entering data it's tedious to enter the same amount of information. Some sort of balance needs to be found.

Large companies, e.g. Amazon, usually have multiple accounts, so after an import there will be many accounts following the pattern Amazon 100001, Amazon 100002, etc. I guess that really does not matter afterwards, as all those accounts should be grouped under just Amazon. However, that would probably complicate the import process.

An easier and options would be to create a 'counterparty' model, which would represent a single party participation in a transaction. It would also help the multi user model, because in that case the users accounts would be any more special than Amazon's, as all the users accounts would be grouped the same way under a single counterparty.

It could complicate the manual entry process, because that's one more model to enter. It could probably be simplified to automatically creating a counterparty and account with the same name.

Another thing, cash accounts probably need to be treated differently. I don't see why one counterparty should have multiple cash accounts Hmm, I guess one could want to physically separate cash and count that as separate 'accounts.' However, if each counterparty could have a generic cash account, and more specific one could be created if needed. Have to think the best way to mark it, whether to do it counterparty or account level. Probably counterparty would be best.

Would merging multiple imported accounts also be possible?

• Add transaction with single item
• Add account with single currency
• Add account with multiple currencies
• Add product
• Add unit
• Add transaction with multiple items from/to the same accounts
• Add transaction with multiple items from/to different accounts
• Add item to existing transaction
• Add currencies to existing account
• Delete single transaction item
• Delete single transaction with all items
• Bulk delete multiple transactions
• Enable/disable currency for an account for new transactions
• Enable/disable account for new transactions
• Display transaction items in transaction overview
• Select period in transaction overview
• Edit existing account

A transfer between the users account will be imported twice, once for each account.

Currently it is not possible for multiple counterparties to have a "Cash" account.

The name of the counterparty should be showed instead of, or in addition to, the account name for all counterparties besides the one that represents the current user. Since counterparties have multiple accounts, it would be easier to identify by the counterparty name.

It should be possible to upload and/or link invoices in PDF or image formats.

Currently for nightly releases only the API for linux-x64 and desktop application for win10-x64 is published. More targets should be added, at the very least both applications should be built both for windows and linux.

Received 400. Also currency drop down shows empty names

Currently Gnomeshade.Interfaces.WebApi.Client depends on Gnomeshade.Interfaces.WebApi due to reusing API models. Either the models have to be moved to a separate assembly, or copied to Gnomeshade.Interfaces.WebApi.Client. Copying will be harder to maintain, but then the Model suffix can be droped for the client.

Introduced earlier, but migrations added in #114.