GNOME Bugzilla – Bug 734922
'Type' in an A/R or A/P account should not be user settable
Last modified: 2018-06-29 23:33:02 UTC
The Type column in my (say PayPal) register contains either I, P or L, sometimes it's '?'. Clicking on the Type box currently cycles between P and I, I can never set it back to L. Should the Type be user changable anyway?
This bug is made partly obsolete by bug 734921 but the principal still stands except that after applying the patch for bug 734921 I get the following behaviour. In a Liability account, clicking a line of type '?' changes it to 'I' cliking again changes it to 'P', another click changes it back to 'I' then 'P' etc. never back to '?'. On leaving the line, if the type is 'I' then it can no longer be changed at all. This raises three points: 1. Why can't it ever be returned to '?' type? 2. Why once 'set' can it never be changed back to 'P' type? 3. Why can the user change the type at all? Perhaps point 3 is the most salient as I think the types should not be mutable anyway. I'll change the bug title to reflect my comments.
Small nit: the type information is only available/used by A/R or A/P type accounts, not ordinary liability accounts. The "I", "P" and "L" type entries are all created by the business logic and it would confuse the code if you could change the type of such transactions at will. I'm not sure why the "?" type has been made changeable initially. I believe Derek coded this, so I hope he can shed some light on this. @Derek: what's the use case of changing these ?
(In reply to Geert Janssens from comment #2) > The "I", "P" and "L" type entries are all created by the business logic and > it would confuse the code if you could change the type of such transactions > at will. > > I'm not sure why the "?" type has been made changeable initially. I believe > Derek coded this, so I hope he can shed some light on this. > > @Derek: what's the use case of changing these ? IIRC the issue what the inability to make a single cell read-only. Beyond that, I don't recall why I made it changeable.
Thanks. So the field should not really be changeable at all, but it may not be possible with the current code to make it so. Then that will be the core issue to fix here.
It's my intention in the rewrite to make account type immutable. I can't think of anything good that could come of changing an account's type after it has splits in it.
(In reply to John Ralls from comment #5) > It's my intention in the rewrite to make account type immutable. I can't > think of anything good that could come of changing an account's type after > it has splits in it. True. This bug however is not about the account type. It talks of the "type" field that only appears in the ledgers for A/R and A/P accounts. This field is used to mark the transaction type - was this for an invoice, a payment or (recently added) lot link ? This field is used by business logic and business reports. The discussion on this bug suggests that this field in itself should also be immutable. Only the business code should be able to set it. There is only one use case in which it should be changeable (in code). If the type is "?", which means the transaction was not created by the business code, it should be possible to convert this into a payment via assign as payment.
A/R and A/P accounts should never be used for Human Input. They are designed for use with the business features and transactions should only be entered into A/R and A/P accounts using those features. Unfortunately there was no way at the time to enforce this without making the whole register read-only.
Two comments: 1) Currently, the due date can only be set when the "type" filed is P. Shouldn't it always be modifiable by the user? 2) When set to I (as a liability), the whole transaction cannot be changed anymore. This is a really severe bug. (Workaround: duplicate transaction, then the field is unset, back to "?")
THOU SHALT NOT ENTER TRANSACTIONS INTO A/R OR A/P MANUALLY. THIS IS NOT A BUG. The code is behaving exactly as designed.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=734922. Please continue processing the bug there and please update any external references or bookmarks.