Commit Graph

13 Commits

Author SHA1 Message Date
jordi fita mas fdf9502c8b “Finish” the new booking form
Had to bring the same fields that i have for a payment to booking,
except that some of those should be nullable, because it is unreasonable
to ask front desk to gather all customer data when they have a booking
via phone, for instance.

Therefore, i can not take advantage of the validation for customer data
that i use in the public-facing form, but, fortunately, most of the
validations where in separated functions, thus only had to rewrite that
one for this case.

I already have to create a booking from a payment, when receiving a
payment from the public instance, thus i made that function and reused
it here.  Then i “overwrite” the newly created pre-booking with the
customer data from the form, and set is as confirmed, as we do not see
any point of allowing pre-bookings from employees.
2024-04-24 20:19:13 +02:00
jordi fita mas 598354e8b7 Add missing autocomplete attribute to town or village 2024-04-22 18:44:48 +02:00
jordi fita mas dab19bbc4d Fix attributes of country select in public booking page 2024-04-22 18:44:22 +02:00
jordi fita mas 0412ffca05 Compute ACSI discount
After months of keeping what does the ACSI checkbox mean, now customer
told us that we should add a discount based on a series of
arbitrary conditions that, and need to be done NOW!

There is no UI to edit the conditions due to lack of time.
2024-03-14 22:08:01 +01:00
jordi fita mas 62d15970bf Reduce booking’s change delay to 500 ms 2024-02-28 13:36:14 +01:00
jordi fita mas 80835256cc Use idiomorph and a delay in the booking form
This is specially for the departure date: Firefox triggers a change each
time the user writes something, but since the date may be outside the
allowed range while the user is typing, the form replaces the input with
the “corrected” one.  The idiomorph thing is to keep the focus in the
“same” field, from the point of view of the user.

It still happens if one is slow enough, but i guess people that want to
write instead of picking the date are usually fast typist. Let’s hope.
2024-02-27 20:06:28 +01:00
jordi fita mas 950bae16e1 Make address, postcode, and city require for booking
Customer changed their mind.
2024-02-24 20:03:11 +01:00
jordi fita mas a159bc75f0 Show a disclaimer on top of book button that it is in fact a prebooking 2024-02-15 15:54:22 +01:00
jordi fita mas bd84df8169 Add down payment
Customer wants to require a down payment of 30 % for bookings made
one week or more before the actual date, and to make the full payment
otherwise.

This would require yet another relation to keep these values. Fuck it;
i added them to the function, as they are very unlikely to change.

That forced me to change the test for draft_payment to use relative
dates, otherwise there is no way i can have stable results in the
future.
2024-02-13 23:45:25 +01:00
jordi fita mas 0f76351ae9 Move down HTMx attributes for booking form
Otherwise, it reloads the form while customers are writing their
details, removing the focus from the form; **very** annoying.

On the plus side, there is nothing to compute when entering these
fields, thus no redundant work is done now.
2024-02-13 05:59:07 +01:00
jordi fita mas e4636592c5 Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance.  There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.

To compute the total for that payment i had to do the same as was doing
until now for the cart.  To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.

Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values.  Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation.  It still allows payment without customer, but at least there
are no NULL values.

Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.

To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug.  A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 05:21:00 +01:00
jordi fita mas d22fe39c80 Add a small note to the booking form when there is overflow
Customer wants to warn customers that plots are not guaranteed to be
next to each other.
2024-02-11 22:06:00 +01:00
jordi fita mas e5023a2a41 Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.

I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment.  Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.

However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.

One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values.  Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx.  I think this is a good
tradeoff, in fact.
2024-02-10 03:49:44 +01:00