tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/revert/edit_contact.sql

56 lines
1.8 KiB
MySQL
Raw Normal View History

Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
-- Deploy numerus:edit_contact to pg
-- requires: schema_numerus
-- requires: email
-- requires: extension_uri
-- requires: country_code
-- requires: tag_name
-- requires: contact
-- requires: extension_vat
-- requires: extension_pg_libphonenumber
Add tags for contacts too With Oriol we agreed that contacts should have tags, too, and that the “tag pool”, as it were, should be shared with the one for invoices (and all future tags we might add). I added the contact_tag relation and tag_contact function, just like with invoices, and then realized that the SQL queries that Go had to execute were becoming “complex” enough: i had to get not only the slug, but the contact id to call tag_contact, and all inside a transaction. Therefore, i opted to create the add_contact and edit_contact functions, that mirror those for invoice and products, so now each “major” section has these functions. They also simplified a bit the handling of the VATIN and phone numbers, because it is now encapsuled inside the PL/pgSQL function and Go does not know how to assemble the parts.
2023-03-26 00:32:53 +00:00
begin;
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
set search_path to numerus, public;
create or replace function edit_contact(contact_slug uuid, business_name text, vatin text, trade_name text, phone text, email email, web uri, address text, city text, province text, postal_code text, country_code country_code, tags tag_name[]) returns uuid as
$$
declare
cid integer;
company integer;
begin
update contact
set business_name = edit_contact.business_name
, vatin = (edit_contact.country_code || edit_contact.vatin)::vatin
, trade_name = edit_contact.trade_name
, phone = parse_packed_phone_number( edit_contact.phone, edit_contact.country_code)
, email = edit_contact.email
, web = edit_contact.web
, address = edit_contact.address
, city = edit_contact.city
, province = edit_contact.province
, postal_code = edit_contact.postal_code
, country_code = edit_contact.country_code
, tags = edit_contact.tags
where slug = contact_slug
returning contact_id, company_id
into cid, company
;
if cid is null then
return null;
end if;
return contact_slug;
end
$$
language plpgsql
;
revoke execute on function edit_contact(uuid, text, text, text, text, email, uri, text, text, text, text, country_code, tag_name[]) from public;
grant execute on function edit_contact(uuid, text, text, text, text, email, uri, text, text, text, text, country_code, tag_name[]) to invoicer;
grant execute on function edit_contact(uuid, text, text, text, text, email, uri, text, text, text, text, country_code, tag_name[]) to admin;
Add IBAN and BIC fields to contacts These two fields are just for information purposes, as Numerus does not have any way to wire transfer using these, but people might want to keep these in the contact’s info as a convenience. Since not every contact should have an IBAN, e.g., customers, and inside SEPA (European Union and some more countries) the BIC is not required, they are in two different relations in order to be optional without using NULL. For the IBAN i found an already made PostgreSQL module, but for BIC i had to write a regular expression based on the information i gathered from Wikipedia, because the ISO standard is not free. These two parameters for the add_contact and edit_contact functions are TEXT because i realized that these functions are intended to be used from the web application, that only deals with texts, so the ValueOrNil() function was unnecessarily complex and PostreSQL’s functions were better suited to “convert” from TEXT to IBAN or BIC. The same is true for EMAIL and URI domains, so i changed their parameter types to TEXT too. Closes #54.
2023-07-02 00:08:45 +00:00
drop function if exists edit_contact(uuid, text, text, text, text, tax_details, text, text, tag_name[]);
Add tags for contacts too With Oriol we agreed that contacts should have tags, too, and that the “tag pool”, as it were, should be shared with the one for invoices (and all future tags we might add). I added the contact_tag relation and tag_contact function, just like with invoices, and then realized that the SQL queries that Go had to execute were becoming “complex” enough: i had to get not only the slug, but the contact id to call tag_contact, and all inside a transaction. Therefore, i opted to create the add_contact and edit_contact functions, that mirror those for invoice and products, so now each “major” section has these functions. They also simplified a bit the handling of the VATIN and phone numbers, because it is now encapsuled inside the PL/pgSQL function and Go does not know how to assemble the parts.
2023-03-26 00:32:53 +00:00
commit;