[GNC] How to edit pop-up menu when typing transaction descriptions

[Eric Chapman]

I also like the idea of having a separate user-editable list/table for 
each account with Payees. When we input a transaction in with a payee 
not in the list it could ask us if we'd like to save it to the list and 
then, if yes, it could allow us to input other data such as the payee 
address.

-- 
Eric Chapman
GnuCash 4.13 on MacOS 13.1 Ventura running on 2018 Mac Mini (3.2 GHz 6-Core Intel Core i7)

On 6/6/23 12:12, Sherman Yoder wrote:
>     Populating the list from a separate table would be a splendid idea,
>     especially if the table could include the payee addresses so the
>     address could print on the check without typing it in each time.
>
>     Sherman
>
>     On 6/6/2023 11:53 AM, David Carlson wrote:
>
> Adrien,
>
> Who are you asking to provide an example?
> My point was that the manual editing method that you suggested couldn't be
> used if the existing descriptions must be kept.
> In my data file that is often the case.
> I agree that there is a lot of 'noise' in the drop down list of suggestions
> caused by searching existing transactions to populate this list.
>
> I think that such a list would best be populated from an independent table
> which would be entirely new to GnuCash.  It could be called 'Payees' and it
> should be independent for each account.
>
>
>
> On Tue, Jun 6, 2023 at 10:07 AM Adrien Monteleone <
> [1]adrien.monteleone at lusfiber.net> wrote:
>
>
> How would you envision this would work in a case where you want to edit
> an existing transaction that has a description which you've removed from
> the list for new transactions? Since every transaction as it is being
> entered is a 'new' transaction, where does this cutoff happen?
>
> Maybe an example could illustrate this use case?
>
>
> Regards,
> Adrien
>
> On 6/6/23 9:32 AM, David Carlson wrote:
>
> The problem with the solution that Adrien suggests is that there is a
>
> real
>
> possibility that the existing descriptions may be correct for existing
> transactions but inappropriate for new transactions.  I think there is no
> solution as long as the current method is used to populate the list, so
>
> we
>
> must live with it.