First, prepare a CSV transaction import file for an existing account such as a credit card account. Then commence importing that file, configuring the CSV importer with valid settings including the target account name, date format, and desired import column information. Save the settings under an appropriate name for later use. Complete the import to verify that it works properly. Then edit the name of the account by changing a few characters to represent some change that the financial institute made such as a name change or credit limit change. Then prepare a new CSV transaction import file for that account. Commence importing the file. Note that when the named settings configuration is loaded, the account name is missing. I would expect the changed account name to be updated as it would be in the main database.
There's been some big changes to the CSV transaction importer. Does 4.4 exhibit such behaviour?
The behavior is the same in release 4.4 in Windows 10. The account name is lost from the saved import configuration if the target account name has been edited by changing a few characters.
I know what is wrong with this, we are saving the account full name instead of the account guid. Will try and change later.
I have pushed a change to maint and will be in version 4.5 which saves the base account setting by its Guid. When the base account is recalled from the saved settings, the account will first be found by Guid lookup, if unsuccessful the full path will be used as before and if found the saved base account setting will immediately be updated with the Guid for future use. Please test and confirm bug is fixed.
Thanks for working on this Bob. A note: while this is certainly an improvement it will break import matching in gnucash 4.4 and older when opening a file that had imports done in 4.5 or more recent. The imports in 4.5 will overwrite the full account names stored in the maps with guids. When you then try to import again in an older gnucash version, it will search for full account name but find a guid, so no match. Personally I think that's ok. There's no important data loss, just the inconvenience of having to retrain the importer when going back and forth between gnucash versions. Because of that I believe it should come with an explanation or warning in the release notes.
Thank you gentlemen for working on this bug. Would it be possible to either provide alternative code to leave the setting generated by previous versions while saving the new settings to be backwards compatible at least until the next major release, or if some settings have been found to include a warning when release 4.5 or later is first run that they will no longer be found if the file is opened by an earlier release, as Geert has suggested? Also, do you need any additional information from me?
This new strategy would fail for an obtuse user who has a top-level account whose name is the guid of a different top-level account <evil-grin> I'd be possible to be fwd+backwd compatible by adding another field; so, CSV import settings have: - account name - account guid (maybe) The account search would first query GUID; - if missing then retrieve name and store GUID. - if present then retrieve both, find account using GUID and test if name matches if they match then all good; return account if they mismatch then name has priority; find using name and store GUID. I think this works?
(In reply to Christopher Lam from comment #7) > if they mismatch then name has priority; find using name and store GUID. > This part would mean this very bug would continue to exist. If the name mismatch happens because an account name has been changed, the old name wouldn't match the new name and hence the existing map would be skipped, even though the guid would have pointed to the proper account.
We set a feature when we did this conversion for Bayesian maps so ISTM we should do the same here, and while we're at it we should check for and fix anywhere else that we're using account names instead of guids as references so we don't have to do this again.
(In reply to Christopher Lam from comment #7) > This new strategy would fail for an obtuse user who has a top-level account > whose name is the guid of a different top-level account <evil-grin> That user deserves the outcome. Actually, that user deserves GnuCash refusing to load the data file, but it's too much work to implement and would slow down loading, something that already takes too long. > > I'd be possible to be fwd+backwd compatible by adding another field; so, CSV > import settings have: > - account name > - account guid (maybe) > > The account search would first query GUID; > - if missing then retrieve name and store GUID. > - if present then retrieve both, find account using GUID and test if name > matches > if they match then all good; return account > if they mismatch then name has priority; find using name and store GUID. > > I think this works? Nope. It would work better if it gives priority to GUID, best if it raises an error and refuses the import.
(In reply to Geert Janssens from comment #5) > Thanks for working on this Bob. > > A note: while this is certainly an improvement it will break import matching > in gnucash 4.4 and older when opening a file that had imports done in 4.5 or > more recent. The imports in 4.5 will overwrite the full account names stored > in the maps with guids. When you then try to import again in an older > gnucash version, it will search for full account name but find a guid, so no > match. > I forgot about backward compatibility and I am inclined not to make it more complicated but maybe Chris has a point and do the following... For 4.5 going forward, Save BaseAccount, full path saved, as existing Save BaseAccountGuid, guid of account, new setting Load from BaseAccountGuid first, if it fails, could be missing Load from BaseAccount, if successful immediately save BaseAccountGuid if unsuccessful then that's it, account selection blank. For 4.4 and below they will try and use existing full path, the BaseAccountGuid will survive until the CSV save button is pressed. I think that may work.
I have pushed my suggestion to maint. So going forward the BaseAccountGuid is searched first, if successful a check is made on the saved full path and updated if required. If no Guid found, the full path is used and if found the account Guid is immediately saved for future use, if not the account combo is blank with a warning message as before. Previous version can still use the BaseAccount full path as before and on testing the BaseAccountGuid will stay until the CSV save settings button is used. I think that should be OK for now, I will add to my list to try and check to see if there any more instances like this and maybe do a bulk change with a feature flag.
I had the same thought for bug 737006 and think the same strategy can be used.
The new Guid code: I wonder if the account name option should be deprecated in master to simplify code, and ensure future hackers don't wonder why maintain two account descriptors. The disadvantage is that 5.x CSV data won't be usable in 4.x.
