When paying listing fees from Anon balances the related transactions info is confusing
bacoinin opened this issue · comments
Describe the bug
When a listing fee is payed from the Public balances all the related transactions in the Wallet module are registered as "Publishing fee" but when one pays the listing fee from the Anon balances half of the relevant transactions are registered as "Blinded Escrow" and the other half as "Received" with the # of confirmation counter stuck forever at 0/1 and the displayed tx info "TX fee" and "Total amount" are always zero.
To Reproduce
Steps to reproduce the behavior:
- Post a listing with several images paid from Anon balances
- Switch to the Wallet module->History
- Observer the mess
Expected behavior
Any listing posting related txs when the fee is paid from Anon balances should s "Publishing fee (Anon)" and have the transaction info like TX fee properly updated.
Screenshots
Screenshots available upon request
Versions (please complete the following information):
- Particl Desktop: [v3.0 RC004]
- Particl Core: [v0.18.2.12]
Thanks for mentioning this!
In general, its difficult to tell what the intended transaction is for. We've largely made an assumption previously about what the transaction is for when posting listings in the past, and this is no different: there's an assumed label thats implicitly applied to the transaction to try and help the user make sense of what it is for. However, this quickly breaks down in certain scenarios, such as the one described. There's only a limited number of transaction variations, and when a number of different "transaction types" overlap, we cannot necessarily know which transaction type is for which action (for consideration, when another app/module sends a smsg for its own process, we cannot distinguish that from the market sending an smsg).
We really shouldn't be assigning default labels for transactions, and trying to "process" them in the wallet app according to this applied label. The transaction processor should instead be applying an appropriate label, although in saying that, I wonder if smsg sending (which is essentially a fee as well, so there's no separate fee IIRC, although I'd need to check this again) allows for a label to be applied to the transaction?
Best I maybe go review the details specifically again 😸 Although I'd still prefer to have the whole PD/wallet app labeling of "market" transactions removed, and go back to a straightforward indication of simple transaction activity, as provided by core. Anybody have any thoughts or opinions on this?
I understand that added labelling complicates things but I'll just say that when you have multiple marketplace transactions going on, things can get confusing without appropriate labels. I wonder if, perhaps, instead of adding specific labels for each type of action, perhaps transactions that result from market activities could perhaps tag the TX ID associated with it. At least, it becomes easier to follow up when looking at the transaction history. That'd be very useful for both buyers and sellers who make a lot of purchases/sales.
Accounting is ultra important for a professional seller. No seller can afford to do the accounting on assumptions.
But, at the same time, Arnold's point is correct about privacy and data sovereignty.
A viable solution seems to match locally in a JSON file or an additional DB file. A local transaction journal that logs the uses locally. Basically a local ledger. Optional to turn on to satisfy the seller's needs. If this file is not present, there is no proof of what a TX was used for. No trace on the blockchain. If the option is not turned on, a fallback solution to the current behavior seems a natural fit.
So the client's GUI journal shows the tags, what a TX was used for, but derives that data not from the chain and doesn't assume based on probabilities. That enables statistics and sales analysis as well. It's fact-based, and the only proof is the envisioned local ledger file.
I can understand that this may be a pain in the ass to develop because it means additional work. Still, to me, it seems the only way to do proper accounting.
Solution "B" is to wait until enough sellers are unsatisfied. 🤷♀️ …. which is to me some kind of living on the edge.
[...] perhaps transactions that result from market activities could perhaps tag the TX ID associated with it. At least, it becomes easier to follow up when looking at the transaction history. That'd be very useful for both buyers and sellers who make a lot of purchases/sales.
@cryptoguard
Thats the idea I was trying to suggest with my previous comment: The transaction processor should instead be applying an appropriate label, although in saying that, I wonder if smsg sending (which is essentially a fee as well, so there's no separate fee IIRC, although I'd need to check this again) allows for a label to be applied to the transaction?
The marketplace (or omp-lib, for that matter) should be attaching appropriate labels etc to the transactions to identify them accordingly. The wallet app already caters to displaying labels for the transaction entries, and so it should be possible to show history or something similar, as needed. Keep in mind that the sending of smsg from the wallet wouldn't be "tagged" or labelled, so that wouldn't necessarily count towards this historical record accounting.
In general, something to note as well: the wallet app is a separate entity. Its like a bank statement: showing the actual transaction data that was observed, regardless of who/what initiated those transactions for whatever purpose/reason. It shouldn't be trying to infer anything from the data really.
To compliment what @DrDBanner mentioned, the app/module that made various transactions for various reasons should be recording the specifics.
@DrDBanner
We're not going to be fitting an accounting type of solution into the v3.0 release. Perhaps in a later revision. There's already a long list of features that are "absolute essentials" and as we develop and implement these, additional "essentials" will invariably be added. At some point we need to release the software: having something and adding to it is infinitely better than not ever having anything at all to use.
I also don't want to pollute the marketplace with all sorts of related industry activity. Other e-commerce solutions don't typically provide full on accounting/logistics/warehousing/etc solutions as part of their offering, and theres reasons for it. More often than not, a very basic system is provided if anything at all. But, a means to extract or interface with the data in their solution is provide so that external systems that deal with the requirements better can more appropriately handle those requirements.
To be clear, the wallet app is not meant as a full-on accounting solution. It never was, and likely won't ever be.
Concurrently, nothing in the marketplace caters for this requirement either... and my opinion is neither should it.
Instead, the more correct solution, at least to me, seems to provide for a means for external systems to interface with the marketplace system. Thats it. By doing so, we then allow for people to use whatever system they intend to use (so long as someone can create the glue bridge that allows that software to talk to the marketplace interface), which meets their specific goals and needs, cater to whatever requirements they have, and that they are comfortable with.
I do like the general concept that you suggested though: providing an intermediary transaction journal. This is something that can maybe be provided in the market app as a sort of basic solution that I referred to. Then using the market API, webhooks, or some other provided means, a means of interfacing to an external accounting solution can be provided. Can be addressed in a future version: would you mind maybe opening a new feature request issue so that we can track this separately to this particular issue?
@DrDBanner
I also feel the need to address this comment separately:
I can understand that this may be a pain in the ass to develop because it means additional work.
I'm kindly requesting that we avoid comments like this in the future please. This has the tendency to suggest that any feedback that does not agree with the requirement/suggestion is simply due to somebody not wanting to do "additional work". Regardless of the actual intention, this tend to break down engagement and does not contribute towards any positive direction to the conversation/topic.
If the intention, for example, was to indicate an understanding/acknowledgement of there being some additional effort involved and that PD should not be released without implementing a solution as it has a negative impact on user engagement, then thats already a better phrasing than what was mentioned. :)
I also don't want to pollute the marketplace with all sorts of related industry activity. Other e-commerce solutions don't typically provide full on accounting/logistics/warehousing/etc solutions as part of their offering, and theres reasons for it.
I am interested in solutions for the users and their needs. That doesn't mean a solution needs to be a native integration into the GUI. Just a solution to a real and potentially underlying problem. "Accounting" in itself is a question of definition. But I believe there are no two opinions about that a seller has the need to be able to determine how and where costs were incurred without noting this manually.
I do like the general concept that you suggested though: providing an intermediary transaction journal. This is something that can maybe be provided in the market app as a sort of basic solution that I referred to. Then using the market API, webhooks, or some other provided means, a means of interfacing to an external accounting solution can be provided. Can be addressed in a future version: would you mind maybe opening a new feature request issue so that we can track this separately to this particular issue?
Yep. It goes hand in hand with a greater vision of an interface to bigger ERP's and multi-channel listing (management) software.
I also feel the need to address this comment separately ....
Well, the idea is and was to highlight that this is a lot of work. Without opposite logic or subliminal disparagement attached. And no, I wouldn't want to postpone any release because of this.
Instead, the more correct solution, at least to me, seems to provide for a means for external systems to interface with the marketplace system. Thats it. By doing so, we then allow for people to use whatever system they intend to use (so long as someone can create the glue bridge that allows that software to talk to the marketplace interface), which meets their specific goals and needs, cater to whatever requirements they have, and that they are comfortable with.
This would be ideal.
For each smsg sending transaction that uses anon funds, there are currently 2 transactions shown: the 'received' transaction, and the 'blinded escrow' transaction.
The 'blinded escrow' transaction has been corrected to display as 'Publishing fee' now instead.
The receive transaction seems to be returned from particl-core: not much the desktop can do about this. Note that this 'receive' transaction entry is cleared up after the wallet is unloaded and reloaded: core seems to identify that the recieve transactions are erroneous and fixes them during the wallet load... after this the receive transactions no longer exist. This has been mentioned to the core team, but from the perspective of PD, this issue should now be resolved: the changes should be available in the next release.
Closing: fixed for mainnet release of v3.0.0