Some customers use appointment systems which support and use different locations for making an appointment. Currently, we only support one location which is configured as a default setting (see admin/config/services/dvg_appointments).
Add a 'wa_location' component which can be used optionally as an extra step after product choose and before date/time choice. The locations are requested from the service if the client supports it.
* create component
* valdiation functions
* add new methods to all clients
* add orchestra6, qmatic3 and lamson clients to dvg_appointemtns
* review
* test all clients
An additional component "Location" which can be used.
New methods for each client to be implemented:
public function get_gov_locations() {
return array();
}
public function get_filtered_locations($products) {
return array();
}
public function get_location_details($location_id) {
return FALSE;
}
public function set_location($location_id) {
return FALSE;
}
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | location_component-2934297-7.patch | 26.56 KB | joshahubbers |
Comments
Comment #2
Danny.Wouters commentedThe following patch adds the option for multiple locations while booking an appointment.
The new functions are currently only implemented in AppointmentsGPlanMultipleClient. A following patch could add the new functions to all clients.
Comment #3
paulvandenburg commentedFurther progress on the addition of locations.
However it needs further refactoring, as well as testing if existing clients that don't support locations continue to work as expected.
A few bugs are fixed regarding navigating multi page forms with this new component (see also #2955587: Could not proceed or go back to the previous page when there is no location to select.).
Comment #4
heine commentedThe patch currently appears to fetch all products, then the available locations per product. In "normal" municipalities, the number of products will exceed the number of locations.
To minimize the number of requests (and thus processing time and roundtrip latency) first asking for locations, then for available products / location would significantly speed up the initial product fetch. Eg; consider the time budget on the initial request product fetch. Assume 2 seconds per request regardless of the type including roundtrip latency, 60 products and two locations.
First products and then locations / product:
2 seconds for the full product list = 2 s
60*2 seconds for the location / product list = 120s
Total: 122 s
First locations and then products per location:
2 seconds for the full location list = 2 s
2*2 seconds for the product / location list: 4s
Total: 6s
Comment #5
joshahubbers commentedRerolled patch to make it apply in the Dvg 1.8 build
Comment #6
joshahubbers commentedHm. patch.txt is not the correct extension.
Comment #7
joshahubbers commentedA new patch, which includes all previous, but also the component.
Comment #8
paulvandenburg commentedLooks good, lets resolve this issue for now.
For further action a new issue can be opened.
Comment #10
paulvandenburg commented