tandem/camper
tandem
/
camper
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity
camper/test/draft_payment.sql

225 lines
12 KiB
MySQL
Raw Normal View History

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 04:21:00 +00:00
-- Test draft_payment
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
select plan(20);
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 04:21:00 +00:00
set search_path to camper, public;
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 21:08:01 +00:00
select has_function('camper', 'draft_payment', array['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]']);
select function_lang_is('camper', 'draft_payment', array['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'plpgsql');
select function_returns('camper', 'draft_payment', array['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'payment');
select isnt_definer('camper', 'draft_payment', array['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]']);
select volatility_is('camper', 'draft_payment', array['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'volatile');
select function_privs_are('camper', 'draft_payment', array ['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'guest', array['EXECUTE']);
select function_privs_are('camper', 'draft_payment', array ['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'employee', array['EXECUTE']);
select function_privs_are('camper', 'draft_payment', array ['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'admin', array['EXECUTE']);
select function_privs_are('camper', 'draft_payment', array ['uuid', 'date', 'date', 'uuid', 'integer', 'integer', 'integer', 'integer', 'text', 'boolean', 'option_units[]'], 'authenticator', array[]::text[]);
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 04:21:00 +00:00
set client_min_messages to warning;
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 21:08:01 +00:00
truncate acsi_option cascade;
truncate acsi_calendar cascade;
truncate acsi cascade;
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 04:21:00 +00:00
truncate payment_option cascade;
truncate payment cascade;
truncate campsite_type_option_cost cascade;
truncate campsite_type_option cascade;
truncate campsite_type_pet_cost cascade;
truncate campsite_type_cost cascade;
truncate campsite_type cascade;
truncate media cascade;
truncate media_content cascade;
truncate season_calendar cascade;
truncate season cascade;
truncate company cascade;
reset client_min_messages;
Add the number of maximum nights that tourist tax applies This is required by law. I do not know why i have this value and the tax amount in the database, but the payment percent and the number of days are hardcoded. I guess i am such an inconsistent mess.
2024-02-27 18:45:47 +00:00
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, rtc_number, tourist_tax, tourist_tax_max_days, country_code, currency_code, default_lang_tag)
values (2, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', '', 350, 7, 'ES', 'EUR', 'ca')
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 04:21:00 +00:00
;
insert into season (season_id, company_id, name)
values (4, 2, 'High')
, (6, 2, 'Shoulder')
, (8, 2, 'Offseason')
;
insert into season_calendar (season_id, season_range)
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 22:45:25 +00:00
values (4, daterange(current_date, current_date + 60))
, (6, daterange(current_date + 60, current_date + 64))
, (8, daterange(current_date + 64, current_date + 69))
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 04:21:00 +00:00
;
insert into media_content (media_type, bytes)
values ('image/x-xpixmap', 'static char *s[]={"1 1 1 1","a c #ffffff","a"};')
;
insert into media (media_id, company_id, original_filename, content_hash)
values (10, 2, 'cover2.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
;
insert into campsite_type (campsite_type_id, slug, company_id, name, media_id, max_campers, bookable_nights, overflow_allowed)
values (12, 'c1b6f4fc-32c1-4cd5-b796-0c5059152a52', 2, 'Plots', 10, 6, '[1, 7]', true)
, (14, 'b065f4e3-2cc8-491d-a413-d015d7d00183', 2, 'Bungalow', 10, 6, '[1, 7]', false)
;
insert into campsite_type_cost (campsite_type_id, season_id, cost_per_night, cost_per_adult, cost_per_teenager, cost_per_child)
values (12, 4, 400, 795, 795, 640)
, (12, 6, 200, 740, 740, 590)
, (12, 8, 0, 660, 660, 540)
, (14, 4, 17000, 0, 0, 0)
, (14, 6, 13500, 0, 0, 0)
, (14, 8, 10500, 0, 0, 0)
;
insert into campsite_type_pet_cost (campsite_type_id, cost_per_night)
values (12, 350)
;
insert into campsite_type_option (campsite_type_option_id, campsite_type_id, name, range, per_night)
values (16, 12, 'Big tent', '[0, 4)', true)
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
, (18, 12, 'Small tent', '[0, 4)', true)
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 04:21:00 +00:00
, (20, 12, 'Electricity', '[0, 5)', false)
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
, (22, 12, 'Car', '[0, 4)', true)
, (24, 12, 'Autocaravan', '[0, 4)', true)
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 04:21:00 +00:00
;
insert into campsite_type_option_cost (campsite_type_option_id, season_id, cost)
values (16, 4, 800)
, (16, 6, 720)
, (16, 8, 620)
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
, (18, 4, 620)
, (18, 6, 550)
, (18, 8, 500)
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 04:21:00 +00:00
, (20, 4, 690)
, (20, 6, 610)
, (20, 8, 590)
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
, (22, 4, 700)
, (22, 6, 630)
, (22, 8, 530)
, (24, 4, 900)
, (24, 6, 750)
, (24, 8, 650)
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 04:21:00 +00:00
;
Take only into account the more expensive option when computing ACSI Apparently, this is how it is done, now.
2024-03-25 16:47:43 +00:00
alter table payment alter column payment_id restart with 26;
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 21:08:01 +00:00
insert into payment (payment_id, slug, company_id, campsite_type_id, arrival_date, departure_date, subtotal_nights, number_adults, subtotal_adults, number_teenagers, subtotal_teenagers, number_children, subtotal_children, number_dogs, subtotal_dogs, subtotal_tourist_tax, total, currency_code, zone_preferences, acsi_card, payment_status, created_at, updated_at)
values (22, '7cccfe16-695e-486d-a6a5-1162fb85cafb', 2, 12, current_date + 60, current_date + 62, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 'USD', '', false, 'draft', '2024-01-01 01:01:01', '2024-01-01 01:01:01')
, (24, '6eeae04c-2fea-4d67-97dc-a4b8a83df99f', 2, 12, current_date + 61, current_date + 62, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 'USD', '', false, 'pending', '2024-01-01 02:02:02', '2024-01-01 02:02:02')
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 04:21:00 +00:00
;
insert into payment_option (payment_id, campsite_type_option_id, units, subtotal)
values (22, 16, 1, 0)
, (22, 18, 1, 0)
Create new drafts if trying to modify an already pending payment This can happen when the customer reaches the payment page, but then returns back to the booking form via the back button: the browser remembers the URI with the cart slug, trying to make it ready, and then it fails because it is already pending. I did not like the idea of modifying a payment that is already not a draft, because it seems to me that can lead to errors if we receive Redsys notifications of payments that are being changed back to draft. In fact, i believe that draft payments maybe should go to a different relation altogether, so that i can prevent UPDATE on payment by guests, but maybe i am going overboard now.
2024-02-13 19:16:12 +00:00
, (24, 16, 2, 0)
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 04:21:00 +00:00
;
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 21:08:01 +00:00
insert into acsi (campsite_type_id, number_adults, number_teenagers, number_children, number_dogs, cost_per_night)
values (12, 2, 0, 0, 1, 2300);
insert into acsi_calendar (campsite_type_id, acsi_range)
values (12, daterange(current_date + 60, current_date + 61))
, (12, daterange(current_date + 64, current_date + 65))
;
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
insert into acsi_option (campsite_type_id, campsite_type_option_id, option_group, units)
values (12, 22, 0, 1)
, (12, 24, 0, 1)
, (12, 16, 1, 1)
, (12, 18, 1, 1)
, (12, 24, 1, 1)
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 21:08:01 +00:00
;
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 04:21:00 +00:00
select lives_ok(
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 21:08:01 +00:00
$$ select draft_payment(null, current_date + 59, current_date + 64, 'b065f4e3-2cc8-491d-a413-d015d7d00183', 1, 2, 3, 0, null, true, null) $$,
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 04:21:00 +00:00
'Should be able to create a new draft for Bungalows'
);
select lives_ok(
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 21:08:01 +00:00
$$ select draft_payment(null, current_date + 6, current_date + 11, 'b065f4e3-2cc8-491d-a413-d015d7d00183', 1, 2, 3, 0, null, true, null) $$,
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 22:45:25 +00:00
'A payment for a reservation in less than a week has a 100 % of downpayment'
);
Add the number of maximum nights that tourist tax applies This is required by law. I do not know why i have this value and the tax amount in the database, but the payment percent and the number of days are hardcoded. I guess i am such an inconsistent mess.
2024-02-27 18:45:47 +00:00
select lives_ok(
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 21:08:01 +00:00
$$ select draft_payment(null, current_date + 10, current_date + 58, 'b065f4e3-2cc8-491d-a413-d015d7d00183', 2, 3, 4, 0, null, true, null) $$,
Add the number of maximum nights that tourist tax applies This is required by law. I do not know why i have this value and the tax amount in the database, but the payment percent and the number of days are hardcoded. I guess i am such an inconsistent mess.
2024-02-27 18:45:47 +00:00
'All reservations incur a tourist tax for the first tourist_tax_max_days days'
);
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 22:45:25 +00:00
select lives_ok(
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 21:08:01 +00:00
$$ select draft_payment('7cccfe16-695e-486d-a6a5-1162fb85cafb', current_date + 58, current_date + 65, 'c1b6f4fc-32c1-4cd5-b796-0c5059152a52', 2, 4, 6, 3, 'pref I before E', false, array[(16, 2), (20, 3)]::option_units[]) $$,
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 04:21:00 +00:00
'Should be able to update the draft for Plots'
);
Create new drafts if trying to modify an already pending payment This can happen when the customer reaches the payment page, but then returns back to the booking form via the back button: the browser remembers the URI with the cart slug, trying to make it ready, and then it fails because it is already pending. I did not like the idea of modifying a payment that is already not a draft, because it seems to me that can lead to errors if we receive Redsys notifications of payments that are being changed back to draft. In fact, i believe that draft payments maybe should go to a different relation altogether, so that i can prevent UPDATE on payment by guests, but maybe i am going overboard now.
2024-02-13 19:16:12 +00:00
select results_ne(
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 21:08:01 +00:00
$$ select slug::text from draft_payment('6eeae04c-2fea-4d67-97dc-a4b8a83df99f', current_date + 31, current_date + 36, 'b065f4e3-2cc8-491d-a413-d015d7d00183', 2, 1, 1, 1, 'under a tree', true, array[(16, 1), (18, 1)]::option_units[]) $$,
Create new drafts if trying to modify an already pending payment This can happen when the customer reaches the payment page, but then returns back to the booking form via the back button: the browser remembers the URI with the cart slug, trying to make it ready, and then it fails because it is already pending. I did not like the idea of modifying a payment that is already not a draft, because it seems to me that can lead to errors if we receive Redsys notifications of payments that are being changed back to draft. In fact, i believe that draft payments maybe should go to a different relation altogether, so that i can prevent UPDATE on payment by guests, but maybe i am going overboard now.
2024-02-13 19:16:12 +00:00
$$ values ('6eeae04c-2fea-4d67-97dc-a4b8a83df99f') $$,
'When trying to draft a payment already pending, completed, failed, or refunded, create a new instead'
);
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 21:08:01 +00:00
select lives_ok(
$$ select draft_payment(null, current_date + 58, current_date + 65, 'c1b6f4fc-32c1-4cd5-b796-0c5059152a52', 3, 1, 1, 1, '', true, array[(16, 2), (18, 3), (20, 4)]::option_units[]) $$,
'Should be able to draft a payment for plots with ACSI discount during the days that is valid'
);
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
select lives_ok(
$$ select draft_payment(null, current_date + 60, current_date + 61, 'c1b6f4fc-32c1-4cd5-b796-0c5059152a52', 2, 0, 0, 1, '', true, array[(16, 1), (22, 1)]::option_units[]) $$,
'Should be able to draft a payment for plots that everything is under ACSI discount'
);
select lives_ok(
$$ select draft_payment(null, current_date + 60, current_date + 61, 'c1b6f4fc-32c1-4cd5-b796-0c5059152a52', 2, 0, 0, 1, '', true, array[(16, 1), (24, 1)]::option_units[]) $$,
'Should be able to draft a payment for plots that everything except big tent is under ACSI discount'
);
select lives_ok(
$$ select draft_payment(null, current_date + 60, current_date + 61, 'c1b6f4fc-32c1-4cd5-b796-0c5059152a52', 2, 0, 0, 1, '', true, array[(16, 1), (22, 1), (24, 1)]::option_units[]) $$,
'Should be able to draft a payment for plots that everything except car is under ACSI discount'
);
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 21:08:01 +00:00
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 04:21:00 +00:00
select bag_eq(
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
$$ select payment_id, company_id, campsite_type_id, arrival_date, departure_date, subtotal_nights, number_adults, subtotal_adults, number_teenagers, subtotal_teenagers, number_children, subtotal_children, number_dogs, subtotal_dogs, subtotal_tourist_tax, total, currency_code, down_payment_percent, zone_preferences, payment_status, created_at, updated_at from payment $$,
$$ values (22, 2, 12, current_date + 58, current_date + 65, 3200, 2, 10420, 4, 20840, 6, 25080, 3, 7350, 4900, 84060, 'EUR', 0.3, 'pref I before E', 'draft', '2024-01-01 01:01:01', current_timestamp)
, (24, 2, 12, current_date + 61, current_date + 62, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 'USD', 1.0, '', 'pending', '2024-01-01 02:02:02', '2024-01-01 02:02:02')
, (26, 2, 14, current_date + 59, current_date + 64, 71000, 1, 0, 2, 0, 3, 0, 0, 0, 1750, 72750, 'EUR', 0.3, '', 'draft', current_timestamp, current_timestamp)
, (27, 2, 14, current_date + 6, current_date + 11, 85000, 1, 0, 2, 0, 3, 0, 0, 0, 1750, 86750, 'EUR', 1.0, '', 'draft', current_timestamp, current_timestamp)
, (28, 2, 14, current_date + 10, current_date + 58, 1632000, 2, 0, 3, 0, 4, 0, 0, 0, 4900, 1636900, 'EUR', 0.3, '', 'draft', current_timestamp, current_timestamp)
, (30, 2, 14, current_date + 31, current_date + 36, 85000, 2, 0, 1, 0, 1, 0, 1, 0, 3500, 95600, 'EUR', 0.3, 'under a tree', 'draft', current_timestamp, current_timestamp)
, (31, 2, 12, current_date + 58, current_date + 65, 6000, 3, 12830, 1, 5210, 1, 4180, 1, 1750, 7350, 60760, 'EUR', 0.3, '', 'draft', current_timestamp, current_timestamp)
, (32, 2, 12, current_date + 60, current_date + 61, 2300, 2, 0, 0, 0, 0, 0, 1, 0, 700, 3000, 'EUR', 0.3, '', 'draft', current_timestamp, current_timestamp)
, (33, 2, 12, current_date + 60, current_date + 61, 2300, 2, 0, 0, 0, 0, 0, 1, 0, 700, 3720, 'EUR', 0.3, '', 'draft', current_timestamp, current_timestamp)
, (34, 2, 12, current_date + 60, current_date + 61, 2300, 2, 0, 0, 0, 0, 0, 1, 0, 700, 3630, 'EUR', 0.3, '', 'draft', current_timestamp, current_timestamp)
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 04:21:00 +00:00
$$,
'Should have added and updated payments'
);
select bag_eq(
Group ACSI options and allow for usage in different groups It turns out that, **this time**, at least, the way to compute the discount is not by “the more expensive”, but “the more expensive _in a given group_”. However, there are a couple of options, such as motorhome, that can be in different groups but only must be used once.
2024-04-03 10:18:54 +00:00
$$ select payment_id, campsite_type_option_id, units, subtotal from payment_option $$,
$$ values (22, 16, 2, 10200)
, (22, 20, 3, 2070)
, (24, 16, 2, 0)
, (30, 16, 1, 4000)
, (30, 18, 1, 3100)
, (31, 16, 2, 8860) -- This is the most expensive, thus the only discounted
, (31, 18, 3, 11820) -- No discount
, (31, 20, 4, 2760) -- This is not even in ACSI
, (32, 16, 1, 0) -- ACSI discount
, (32, 22, 1, 0) -- ACSI discount
, (33, 16, 1, 720) -- No discount because already discounted in option 24
, (33, 24, 1, 0) -- ACSI discount
, (34, 16, 1, 0) -- Discount because opiont 24 was already “resolved” against 22
, (34, 24, 1, 0) -- ACSI discount
, (34, 22, 1, 630) -- No discount because it is cheaper than option 24
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 04:21:00 +00:00
$$,
'Should have added, updated, and removed payment options'
);
select *
from finish();
rollback;