Bug 412259 - Add ability to enter payee city and state
Summary: Add ability to enter payee city and state
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Phil
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-23 22:03 UTC by Phil
Modified: 2020-02-14 03:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attachment-9476-0.html (1.51 KB, text/html)
2019-09-25 17:28 UTC, Phil
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phil 2019-09-23 22:03:29 UTC
Kmymoney UI can store payee information except for the payee city and state. The ability to add and modify the payee city and state needs to be added.
Comment 1 Jack 2019-09-23 22:38:47 UTC
There are already fields for address and for postal code.  Why are these not sufficient?
Comment 2 Phil 2019-09-23 22:48:22 UTC
The fields are in the XML or the database but there is no way to enter data into the fields since the UI does not support it. This functionality needs to be added. 

The payee UI need to be modified to provide this ability.
Comment 3 Phil 2019-09-23 22:51:01 UTC
The address prints out wrong without the payee cite and state. The check template provided uses these fields. The payee address is for the street address not the city and state. The UI needs to be modified to allow this data to be entered.
Comment 4 Jack 2019-09-23 22:54:25 UTC
What version are you using, as this functionality works just fine.

Go to the payees view, select a payee, and then select the Address tab.  There are fields for Address, Postal Code, Telephone/Fax, E-Mail, and Notes.  I can enter data in all of them.
Comment 5 Jack 2019-09-23 22:57:21 UTC
OK - you are talking about check printing, and not the basic functionality of the Payee view.  Have you entered city and state in the Address field?  Have you left enough room in the template for more than one line for the address?  (I have not tried using the Address in a check template.  I will try when I get a chance.)

You could certainly change this to a wishlist to add city and state as separate fields, and also make them available to the check printing templates, but if you only want to use them as part of a complete address, the current state should work.
Comment 6 Phil 2019-09-23 23:12:04 UTC
Let me try again, if this comment shows twice forgive me.

If one uses the address to hold the payee city and state and prints a check, everything prints on one line. This is incorrect functionality. The UI needs to be modified to populate these fields.

Looking at the code and documentation the address field is for street address only, not the city or state.
Comment 7 Jack 2019-09-24 00:15:41 UTC
I'm having problems finding the check templates on my own PC right now, but from my memory, the templates use HTML syntax, ao try adding <BR> where you want the line breaks in the address.
Comment 8 Jack 2019-09-24 00:37:38 UTC
OK, found them, and the templates are HTML, so using <BR> "should" work, if only as a temporary workaround.  I see in the code that $PAYEE_CITY and $PAYEE_STATE are treated as proper substitute variables, so I can only assume the check printing somehow got out of sync with the fields actually handled on the payee address tab.  I'm going to change the title to reflect this.  I'm hoping it will be fairly easy to make the necessary changes.

As for the documentation on check printing, I have intended to include the list of available substitution variables, but have just not gotten to it yet.  I'll up the priority.
Comment 9 Phil 2019-09-24 00:43:03 UTC
Yes, they use HTML and using <br /> works, but they after saving they don't show and one doesn't know that they are there. If you modify the address and don't remember the  <br /> you can easily mess it up. Further the documentation is showing to use the payee city when writing a check template. 

The UI needs to be modified to make this work properly.

I spent a lot of time figuring out a way to make this work but it is easily messed up which wouldn't happen if the payee city and state could be populated.
Comment 10 Phil 2019-09-24 00:45:38 UTC
I believe that the changes are fairly easy.  I think that there are two files that need to be modified and the existing code provides a model to make the additions.

I will look closer at the code later this evening.
Comment 11 Phil 2019-09-24 04:25:56 UTC
I have a set of patches on my machine for this request. If you want to assign this to me I will upload my patches in a day or two.
Comment 12 Phil 2019-09-24 04:27:58 UTC
I assigned it to myself and I will upload the patches in a day or two. I need to do a bit of testing.
Comment 13 Thomas Baumgart 2019-09-25 06:04:50 UTC
Please make sure that the DB backend is working as well. The necessary columns are already present and maybe, you don't have to do anything besides testing.
Comment 14 Phil 2019-09-25 17:28:40 UTC
Created attachment 122868 [details]
attachment-9476-0.html

Thanks for reminding me about the sql back end, I will test it.

I have a question, I see the payee information quite different from the
other information that is saved. What I mean is that the payee information
saves the payee city and state (the seems to be very North American
oriented) where the rest of the data uses locality, country and region.
Should  I revise the payee data to be inline or the same as the individual
data? or leave it alone?

Please let me know, which is preferable.

Phil

On Wed, Sep 25, 2019 at 1:04 AM Thomas Baumgart <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=412259
>
> --- Comment #13 from Thomas Baumgart <tbaumgart@kde.org> ---
> Please make sure that the DB backend is working as well. The necessary
> columns
> are already present and maybe, you don't have to do anything besides
> testing.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
> You reported the bug.