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

187 lines
8.0 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 payment
set client_min_messages to warning;
create extension if not exists pgtap;
reset client_min_messages;
begin;
Add the admin page to see payments Had to do a couple of changes to the database: add the currency_code to the payment relation, to format the price according to the payment’s currency instead of the company’s; and the reference SQL function, to replace the equivalent golang function, so that i can use it to index payments. The rest is mostly the same as any other page, except that the individual payment’s page is not a form, but a regular info dump. I also moved the payment settings as a sub-route of payments, as i believe this makes more sense than an additional user menu item.
2024-02-14 03:54:42 +00:00
select plan(114);
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;
select has_table('payment');
select has_pk('payment');
select table_privs_are('payment', 'guest', array['SELECT', 'INSERT', 'UPDATE']);
select table_privs_are('payment', 'employee', array['SELECT', 'INSERT', 'UPDATE']);
select table_privs_are('payment', 'admin', array['SELECT', 'INSERT', 'UPDATE', 'DELETE']);
select table_privs_are('payment', 'authenticator', array[]::text[]);
select has_column('payment', 'payment_id');
select col_is_pk('payment', 'payment_id');
select col_type_is('payment', 'payment_id', 'integer');
select col_not_null('payment', 'payment_id');
select col_hasnt_default('payment', 'payment_id');
select has_column('payment', 'company_id');
select col_is_fk('payment', 'company_id');
select fk_ok('payment', 'company_id', 'company', 'company_id');
select col_type_is('payment', 'company_id', 'integer');
select col_not_null('payment', 'company_id');
select col_hasnt_default('payment', 'company_id');
select has_column('payment', 'slug');
select col_is_unique('payment', 'slug');
select col_type_is('payment', 'slug', 'uuid');
select col_not_null('payment', 'slug');
select col_has_default('payment', 'slug');
select col_default_is('payment', 'slug', 'gen_random_uuid()');
select has_column('payment', 'campsite_type_id');
select col_is_fk('payment', 'campsite_type_id');
select fk_ok('payment', 'campsite_type_id', 'campsite_type', 'campsite_type_id');
select col_type_is('payment', 'campsite_type_id', 'integer');
select col_not_null('payment', 'campsite_type_id');
select col_hasnt_default('payment', 'campsite_type_id');
select has_column('payment', 'arrival_date');
select col_type_is('payment', 'arrival_date', 'date');
select col_not_null('payment', 'arrival_date');
select col_hasnt_default('payment', 'arrival_date');
select has_column('payment', 'departure_date');
select col_type_is('payment', 'departure_date', 'date');
select col_not_null('payment', 'departure_date');
select col_hasnt_default('payment', 'departure_date');
select has_column('payment', 'subtotal_nights');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'subtotal_nights', 'nonnegative_integer');
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 col_not_null('payment', 'subtotal_nights');
select col_hasnt_default('payment', 'subtotal_nights');
select has_column('payment', 'number_adults');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'number_adults', 'positive_integer');
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 col_not_null('payment', 'number_adults');
select col_hasnt_default('payment', 'number_adults');
select has_column('payment', 'subtotal_adults');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'subtotal_adults', 'nonnegative_integer');
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 col_not_null('payment', 'subtotal_adults');
select col_hasnt_default('payment', 'subtotal_adults');
select has_column('payment', 'number_teenagers');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'number_teenagers', 'nonnegative_integer');
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 col_not_null('payment', 'number_teenagers');
select col_hasnt_default('payment', 'number_teenagers');
select has_column('payment', 'subtotal_teenagers');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'subtotal_teenagers', 'nonnegative_integer');
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 col_not_null('payment', 'subtotal_teenagers');
select col_hasnt_default('payment', 'subtotal_teenagers');
select has_column('payment', 'number_children');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'number_children', 'nonnegative_integer');
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 col_not_null('payment', 'number_children');
select col_hasnt_default('payment', 'number_children');
select has_column('payment', 'subtotal_children');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'subtotal_children', 'nonnegative_integer');
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 col_not_null('payment', 'subtotal_children');
select col_hasnt_default('payment', 'subtotal_children');
select has_column('payment', 'number_dogs');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'number_dogs', 'nonnegative_integer');
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 col_not_null('payment', 'number_dogs');
select col_hasnt_default('payment', 'number_dogs');
select has_column('payment', 'subtotal_dogs');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'subtotal_dogs', 'nonnegative_integer');
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 col_not_null('payment', 'subtotal_dogs');
select col_hasnt_default('payment', 'subtotal_dogs');
select has_column('payment', 'subtotal_tourist_tax');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'subtotal_tourist_tax', 'nonnegative_integer');
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 col_not_null('payment', 'subtotal_tourist_tax');
select col_hasnt_default('payment', 'subtotal_tourist_tax');
select has_column('payment', 'total');
Add positive_integer and nonnegative_integer domains This is easier to read and requires less unit tests, but i only used them in the new relations and fields for HEAD, because i do not see any point on creating migrations just for that.
2024-02-13 21:12:30 +00:00
select col_type_is('payment', 'total', 'nonnegative_integer');
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 col_not_null('payment', 'total');
select col_hasnt_default('payment', 'total');
Add the admin page to see payments Had to do a couple of changes to the database: add the currency_code to the payment relation, to format the price according to the payment’s currency instead of the company’s; and the reference SQL function, to replace the equivalent golang function, so that i can use it to index payments. The rest is mostly the same as any other page, except that the individual payment’s page is not a form, but a regular info dump. I also moved the payment settings as a sub-route of payments, as i believe this makes more sense than an additional user menu item.
2024-02-14 03:54:42 +00:00
select has_column('payment', 'currency_code');
select col_is_fk('payment', 'currency_code');
select fk_ok('payment', 'currency_code', 'currency', 'currency_code');
select col_type_is('payment', 'currency_code', 'currency_code');
select col_not_null('payment', 'currency_code');
select col_hasnt_default('payment', 'currency_code');
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 has_column('payment', 'down_payment_percent');
select col_type_is('payment', 'down_payment_percent', 'percentage');
select col_not_null('payment', 'down_payment_percent');
select col_has_default('payment', 'down_payment_percent');
select col_default_is('payment', 'down_payment_percent', '1.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
select has_column('payment', 'zone_preferences');
select col_type_is('payment', 'zone_preferences', 'text');
select col_not_null('payment', 'zone_preferences');
select col_hasnt_default('payment', 'zone_preferences');
select has_column('payment', 'payment_status');
select col_is_fk('payment', 'payment_status');
select fk_ok('payment', 'payment_status', 'payment_status', 'payment_status');
select col_type_is('payment', 'payment_status', 'text');
select col_not_null('payment', 'payment_status');
select col_has_default('payment', 'payment_status');
select col_default_is('payment', 'payment_status', 'draft');
select has_column('payment', 'created_at');
select col_type_is('payment', 'created_at', 'timestamp with time zone');
select col_not_null('payment', 'created_at');
select col_has_default('payment', 'created_at');
select col_default_is('payment', 'created_at', 'CURRENT_TIMESTAMP');
select has_column('payment', 'updated_at');
select col_type_is('payment', 'updated_at', 'timestamp with time zone');
select col_not_null('payment', 'updated_at');
select col_has_default('payment', 'updated_at');
select col_default_is('payment', 'updated_at', 'CURRENT_TIMESTAMP');
set client_min_messages to warning;
truncate payment cascade;
truncate campsite_type cascade;
truncate media cascade;
truncate media_content 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 (1, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', '', 60, 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 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 (2, 1, 'cover2.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
;
insert into campsite_type (campsite_type_id, company_id, media_id, name, description, max_campers, bookable_nights, active)
values (10, 1, 2, 'Type A', '<p>A</p>', 5, '[1, 7]', true)
;
select throws_ok(
Add the admin page to see payments Had to do a couple of changes to the database: add the currency_code to the payment relation, to format the price according to the payment’s currency instead of the company’s; and the reference SQL function, to replace the equivalent golang function, so that i can use it to index payments. The rest is mostly the same as any other page, except that the individual payment’s page is not a form, but a regular info dump. I also moved the payment settings as a sub-route of payments, as i believe this makes more sense than an additional user menu item.
2024-02-14 03:54:42 +00:00
$$ insert into payment (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) values (1, 10, '2024-07-07', '2024-07-07', 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 'EUR', '') $$,
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
'23514', 'new row for relation "payment" violates check constraint "departure_after_arrival"',
'Should not be able to insert a payment with a departure date equal or before the arrival date (i.e., at least one night)'
);
select *
from finish();
rollback;