Copied as much as i could from Numerus, and made as few modifications as
i could to adapt to this code base; it is, quite frankly, a piece of
shit.
We need to be able to create invoices from scratch “just in case”,
apparently, but it is not yet possible to create an invoice from a
booking.
This is actually only used for plots, but, of course, it means that
every booking now can potentially have many booked campsites, and have
to create a relation for it.
I now have a conundrum regarding stay dates: i need them to be in the
same table as the campsite_id, because constraints only work on a single
relation and without the dates i can not make sure that i am not
overbooking a given campsite; but, on the other hand, all campsites
under the same booking must be for the same dates.
Where does stay belong, then? In booking or booking_campsite? If in
booking then i can not have a constraint that most assuredly will bite
me in the back, but if in booking_campsite then each campsite could
potentially have different dates.
As far as i can see, i can not use a exclude constraint with <> for
dates in booking_campsite to ensure that all rows with the same
booking_id have the same stay (i.e., exclude those that have a different
stay for the same booking_id).
For now, the say is in **both** relations: in booking, because i need it
when it is a prebooking, at least, and in booking_campsite for the
aforementioned constraint requirements.
Will this come back and bite me? Yes, it will. But what can i do?
I need the campsite_id in booking to know what row to show the booking
at. Besides the need of knowing which actual campsite has been booked,
of course.
This field is nullable because we can not now it until an employee has
confirmed the booking; until that point we only know the campsite type
customer requested. I do not care much if the campsite_id is from a
different campsite_type, because maybe the customer requested the change
by phone or what have you, therefore the database can not be that
strict. It must have a value if the booking is confirmed.
It helps me if the arrival_date and departure_date is a single
daterange, because then i can use `&&` and other range operators to work
with these dates. For instance, i have to intersect it with the range
displayed on the screen in order to know which day i have to put it.
But then i have to know whether the booking begins and ends in the
display range, because i only have to show arrival and departure (i.e.,
the box half-way within the first or last boxes) on these days only.
Since this address is used to send notifications when a new payment is
received, is quite important not to use the same address as in
production, or there is a non-trivial chance of confusion.
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.
Customer told us that there are some options, such as towels, that have
a fixed price for the whole stay, not a per night price. Thus, had to
add a boolean to know whether to use sum or max when computing the
cart’s total for each option.
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
Customer told us that the minimum number of nights is per campsite type,
not per season. And he wants this, along with the maximum number of
nights, in order to limit the range of departure dates that guests can
choose when booking.
There are many installations on the map that are drawn with rect
instead of path. I could transform them with Inkscape, but i finally
found out about DOMMatrix, that helps me a lot to convert points, as
it can parse the values of the `transform` attribute.
I also saw that SVGGraphicElements has getCTM() and getScreenCTM(), but
neither of them worked for me: the resulting transformation was “shrunk”
on the map (i.e., like it was scaled down).
The “overflow” is for when people want to book plots for more guests
than is permitted, which the system would need to add a new plot to the
“shopping cart”, as it were; not implemented yet.
The ask zone preferences is to whether show the corresponding input on
the booking form, that it was done implicitly when the campsite type had
options, because up until now it was only for plots, but it is no longer
the case, thus i need to know when to show it; now it is explicit.
This is more or less the same as the campsites, as public information
goes, but for buildings and other amenities that the camping provides
that are not campsites.
A small page with a brief description, carousel, and feature list of
each individual accommodation.
Most of the relations and functions for carousel and features are like
the ones for campsite types, but i had to use the accommodation’s label
to find them, because they do not have slugs; i did not even though
these would be public, and they already have a label, although not
unique for all companies, like UUID slugs are.
We were using what was very clearly a campfire as the icon for the
barbecue service, when we first replaced it with a Font Awesome icon
we chose an icon that was neither campfire nor barbecue (flame-curved),
but now Oriol wanted one that left no doubt it was a barbecue.
Instead of replacing the campfire SVG with that of the barbecue, i have
chosen a campfire image from Font Awesome for our icon, and added a
separate icon for that service.
Apparently, each campsite type could have different check-in and
check-out times, thus i need them in the database.
I thought about using an integer or a datetime field, but customer seems
to want a text field to maybe add “before” and “after” there as well.
Translatable text it is.
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
Customer does not want the new “masonry-like” design of the surroundings
page, and wants the same style they already had: a regular list with
text and photo, alternating the photo’s side.
And, of course, they want to be able to add and edit them themselves. It
is like another carousel, but with an additional rich-text description.
The photos that we had in that page are no longer of use.
Customer does not want a contact page, but a page where they can write
the direction on how to reach the campground, with a Google map embed
instead of using Leaflet, because Google Maps shows the reviews right
in the map.
That means i had to replace the GPS locations with XML fields for the
customer to write. In all four languages.
This time i tried a translation approach inspired by PrestaShop: instead
of opening a new page for each language, i have all languages in the
same page and use AlpineJS to show just a single language. It is far
easier to write the translations, even though you do not have the source
text visible, specially in this section that there is no place for me
to put the language links.
Every company need to have its own merchant code and encryption key,
thus it is not possible to use environment variables to keep that data,
and i have to store it in the database.
I do not want to give SELECT permission on the encryption key to guest,
because i am going to fuck it up sooner or later, and everyone would be
able to read that secret; i know it would. Therefore, i need a security
definer function that takes the data to encrypt, use the key to encrypt
it, and returns the result; nobody else should have access to that key,
not even admins!
By the way, i found out that every merchant receives the same key, thus
it is not a problem to keep it in the repository.
Since i need that SQL function to encrypt the data, i thought that i may
go the whole nine yards and sign the request in PostgreSQL too, after
all the data to sign comes from there, and it has JSON functions to
create and base64-code an object.
Fortunately, pg_crypto has all the functions that i need, but i can no
longer keep that extension inside the auth schema, because it is used
from others, and the public schema, like every other extensions, seems
more appropriate.
Instead of having the list of currency and language codes that Redsys
uses as constants in the code, i moved that as field to the currency
and language relations, so i can simply pass the lang_tag to the
function and it can transform that tag to the correct code; the currency
is from the company’s relation, since it is the only currency used in
the whole application (for now).
As a consequence, i had to grant execute to currency and the parse_price
functions to guest, too.
To generate the test data used in the unit tests, i used a third-party
PHP implementation[0], but i only got from that the resulting base64-coded
JSON object and signature, using the same that as in the unit test, and
did not use any code from there.
PostgreSQL formats the JSON as text differently than most
implementations i have seen: it adds spaces between the key name and
the colons, and space between the value and the separating comma. The
first implementation used replace() to format the JSON as exactly as
the PHP implementation, so that the result matches, and then tried to do
generate the form by hand using the output from PostgreSQL without the
replace(), to verify that Redsys would still accept my input. Finally,
i adjusted the unit test to whatever pg_prove said it was getting from
the function.
I still have the form’s action hard-codded to the test environment, but
the idea is that administrators should be able to switch from test to
live themselves. That means that i need that info in the redsys
relation as well. I think this is one of the few use cases for SQL’s
types, because it is unlikely to change anytime soon, and i do not need
the actual labels.
Unfortunately, i could not use enumerations for the request’s
transaction type because i can not attach an arbitrary number to the
enum’s values. Having a relation is overkill, because i would need
a constant in Go to refer to its primary key anyway, thus i kept the
same constant i had before for that. Language and currency constant
went out, as this is in the corresponding relations.
In setup_redsys i must have a separate update if the encrypt_key is null
because PostgreSQL checks constraints before key conflict, and i do
not want to give a default value to the key if the row is not there yet.
The problem is that i want to use null to mean “keep the same password”,
because it is what i intend to do with the user-facing form: leave the
input empty to keep the same password.
As now Go needs to pass composite types back and forth with PostgreSQL,
i need to register these types, and i have to do it every time because
the only moment i have access to the non-pooled connection is in the
AfterConnect function, but at that point i have no idea whether the
user is going to request a payment. I do not know how much the
performance degrades because of this.
[0]: https://github.com/ssheduardo/sermepa/blob/master/src/Sermepa/Tpv/Tpv.php
This is the text that introduces the carousel; it is not a spiel, but
this is what i call it.
It turns out that this text needs to have paragraphs and headings, much
like home’s slider, rather than the one in services page, thus no need
to change its font size or to align all items in the carousel in the
middle.
I can not reuse the carousel package because these carousels need the
campsite site’s slug as a first parameters: i can not have a relation
per campsite type, as i do in home and services pages, because the
campsite types are added by administration types; even if i had a
single relation for slides of home and services pages, these would go
in a different relation due to the foreign key to campsite type.
What i could reuse, however, is the Slide and SlideEntry types from
that package, although i had to export carousel.Translation to be usable
from the types package. I should change that to use locale.Translation,
but this was the easier option, or i would need to change the queries
and templates for carousel package too.
Besides that, they work exactly like the slides in home and services
pages.
I was not sure whether to use PostGIS to store the GPS location of the
company, as i am sure i will only use that point just to show the map.
However, just in case, it is not a big deal.
There is no way to change that from the administration pages for now,
because of time constraints, and it is very unlikely that they will
change the campgrounds’ location in the near future.
The location is in a separate table because i did not want to have to
change every test file, to be honest, but this also makes the map
“optional” without the need for NULL values.
I added the contact address to every public page because the new design
adds it to the footer, so i will be needing it everywhere, just like the
menu.
Since i have my browser in English, the automatically detected language
is also set in English, making it harder for me to see if i added all
the translations; when the language is Catalan, i can see the
untranslated strings.
This calendar is supposed to be edited by admin users, but do not yet
have the complete JavaScript code to do so, thus for now i have made it
read-only.
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
I intend to use the same SVG file for customers and employees, so i had
to change Oriol’s design to add a class to layers that are supposed to
be only for customers, like trees. These are hidden in the admin area.
I understood that customers and employees have to click on a campsite to
select it, and then they can book or whatever they need to do to them.
Since customers and employees most certainly will need to have different
listeners on campsites, i decided to add the link with JavaScript. To
do so, i need a custom XML attribute with the campsite’s identifier.
Since i have seen that all campsites have a label, i changed the
“identifier” to the unique combination (company_id, label). The
company_id is there because different companies could have the same
label; i left the campsite_id primary key for foreign constraints.
In this case, as a test, i add an <a> element to the campsite with a
link to edit it; we’ll discuss with Oriol what exactly it needs to do.
However, the original design had the labels in a different layer, that
interfered with the link, as the numbers must be above the path and
the link must wrap the path in order to “inherit” its shape. I had no
other recourse than to move the labels in the same layer as the paths’.
It made no sense to have a file upload in each form that needs a media,
because to reuse an existing media users would need to upload the exact
same file again; this is very unusual and unfriendly.
A better option is to have a “centralized” media section, where people
can upload files there, and then have a picker to select from there.
Ideally, there would be an upload option in the picker, but i did not
add it yet.
I’ve split the content from the media because i want users to have the
option to update a media, for instance when they need to upload a
reduced or cropped version of the same photo, without an edit they would
need to upload the file as a new media and then update all places where
the old version was used. And i did not want to trouble people that
uploads the same photo twice: without the separate relation, doing so
would throw a constraint error.
I do not believe there is any security problem to have all companies
link their media to the same file, as they were already readable by
everyone and could upload the data from a different company to their
own; in other words, it is not worse than it was now.
jordi fita mas