Bug 27379 - Autocomplete addresses for a patron using Google Places API (Maps).
Summary: Autocomplete addresses for a patron using Google Places API (Maps).
Status: RESOLVED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Ivan Dziuba
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-11 17:11 UTC by Ivan Dziuba
Modified: 2023-10-20 20:50 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Google suggests addresses (32.07 KB, image/png)
2021-01-11 17:11 UTC, Ivan Dziuba
Details
Bug 27379 - Autocomplete addresses for a patron using Google Places API (Maps). (17.51 KB, patch)
2021-01-12 16:04 UTC, Ivan Dziuba
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Dziuba 2021-01-11 17:11:36 UTC
Created attachment 115043 [details]
Google suggests addresses

We are starting fill an address for a patron, Google suggests addresses which are related with patron's address. When you select a suitable address, the corresponding fields are filled automatically.
Comment 1 Katrin Fischer 2021-01-11 22:32:58 UTC
I know a lot of libraries would really like this, but for some there might be data privacy concerns. If we add this, can we please make it optional?
Comment 2 Ivan Dziuba 2021-01-12 16:04:24 UTC
Created attachment 115097 [details] [review]
Bug 27379 - Autocomplete addresses for a patron using Google Places API (Maps).

This patch adds the preference 'GooglePlacesAPI'. You need do ./updatedatabase.pl
Now, we can fill API Key Google Places and use autocomplete for addresses.
This patch works on the pages:
1. moremember.pl (Add/Edit patron).
Field:
    -  Address (Main address, Alternate address, Alternate contact)
2. supplier.pl (Add/Edit vendor).
Fields:
    - Postal address.
    - Physical address.
Comment 3 Ivan Dziuba 2021-01-12 16:05:33 UTC
(In reply to Katrin Fischer from comment #1)
> I know a lot of libraries would really like this, but for some there might
> be data privacy concerns. If we add this, can we please make it optional?

Yes, it is optional.
Comment 4 Lucas Gass 2021-01-13 17:56:29 UTC
Hey Ivan,

I think a lot of libraries would find this useful. 

When I apply the patch, and create an deveolpers API with Google, then attempt to test this patch I get the following console error:

You must enable Billing on the Google Cloud Project at https://console.cloud.google.com/project/_/billing/enable Learn more at https://developers.google.com/maps/gmp-get-started Places API error: BillingNotEnabledMapError
https://developers.google.com/maps/documentation/javascript/error-messages#billing-not-enabled-map-error


Although I can get a 'free trial account' I still have to provide Google with a credit card and billing information, making this patch difficult to test.
Comment 5 Owen Leonard 2021-01-19 16:19:13 UTC
I see a few issues with this:

1. There are errors returned by the QA tool
2. In the "Alternate address" section the zip code does not get filled in. I see an error in the console, Uncaught TypeError: type_google is undefined
3. In the alternate contact section when I select an address from the dropdown the number is separated from the street by a comma:

95, West Washington Street. The comma shouldn't be there.

4. In both the main and alternate address sections, if I disable the "streetnumber" fields (streetnumber and B_streetnumber), the number isn't appended to the street name in the address field.
Comment 6 Benjamin Daeuber 2021-02-17 16:05:16 UTC
Is this better approached as a plugin? This development locks libraries into Google Maps, where if this were a plugin, it's easier to use alternate providers.
Comment 7 Katrin Fischer 2023-07-01 15:55:28 UTC
External APIs lend themselves to plugins as they can then be easier kept up to date if anything about the API changes.

Should we mark this WONTFIX here maybe?
Comment 8 David Cook 2023-07-02 23:19:33 UTC
(In reply to Katrin Fischer from comment #7)
> External APIs lend themselves to plugins as they can then be easier kept up
> to date if anything about the API changes.
> 
> Should we mark this WONTFIX here maybe?

I'm thinking so
Comment 9 Katrin Fischer 2023-07-16 13:19:36 UTC
Inlibro: do you agree with closing?
Comment 10 Blou 2023-10-20 20:50:52 UTC
yes, you can close it.  We'll revive as a plugin if needed.