[GNC] Pending Edit Behavior in GnuCash
John Ralls
jralls at ceridwen.us
Fri Jun 28 12:29:02 EDT 2019
Perhaps that would be a better behavior for the current jump button.
Regards,
John Ralls
> On Jun 28, 2019, at 9:20 AM, David Carlson <david.carlson.417 at gmail.com> wrote:
>
> I would like to throw out a new suggestion to add a permanent menu item to
> the account register window that would jump to the current transaction in
> the journal view, where there is no anchor account. This would allow
> editing without worrying about whether an anchor account split is being
> edited.
>
> David Carlson
>
> On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone <
> adrien.monteleone at lusfiber.net> wrote:
>
>> I figured as much, but suggested it anyway at least as a temporary
>> workaround. I do see the utility of an edit-only tab.
>>
>> Regards,
>> Adrien
>>
>>> On Jun 7, 2019, at 8:37 PM, David Carlson <david.carlson.417 at gmail.com>
>> wrote:
>>>
>>> Returning to Adrien's comment on my Edit window Suggestion:
>>>
>>>>> Finally, I will throw out a radical suggestion that all edits get
>> their own
>>>>> new window instead of happening within a certain register view with a
>>>>> certain "anchor" account which has special behavior compared to other
>> split
>>>>> lines. This Edit window would not be tied to any account and would be
>>>>> obviously not saved as long as it exists.
>>>>>
>>>> This already exists as the ‘General Journal’ (Tools menu) It’s your
>> choice to use it. Though it is not implemented for only the currently
>> edited transactions, but the entirety of your data file.
>>>>
>>>
>>> My reasoning for suggesting a dedicated edit window for each transaction
>> edit is to serve a completely different purpose than that served by the
>> General Journal, but it may share some code in an implementation. If each
>> transaction edit was in it's own dedicated window, they would all be very
>> easy to find and commit or cancel at a later time. Then the possible
>> ambiguity of having some pending edits in search windows or the General
>> Ledger would also be avoided. There may be a better coding technique to
>> implement this, especially in SQL, so I do not want to be so specific to
>> prevent the developers from thinking creatively in an implementation.
>>>
>>>> David Carlson
>>
>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
More information about the gnucash-user
mailing list