tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/web/template/contacts/edit.gohtml

58 lines
2.3 KiB
Plaintext
Raw Normal View History

Add the edit contact page
2023-02-03 12:29:10 +00:00
{{ define "title" -}}
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.editContactPage*/ -}}
{{printf (pgettext "Edit Contact “%s”" "title") .ContactName }}
Add the edit contact page
2023-02-03 12:29:10 +00:00
{{- end }}
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
{{ define "breadcrumbs" -}}
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.editContactPage*/ -}}
Add breadcrumbs
2023-02-03 12:58:10 +00:00
<nav>
Boost all breadcbrumb links
2023-04-02 14:10:13 +00:00
<p data-hx-target="main" data-hx-boost="true">
Add breadcrumbs
2023-02-03 12:58:10 +00:00
<a href="{{ companyURI "/" }}">{{( pgettext "Home" "title" )}}</a> /
<a href="{{ companyURI "/contacts"}}">{{( pgettext "Contacts" "title" )}}</a> /
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
<a>{{ .ContactName }}</a>
Add breadcrumbs
2023-02-03 12:58:10 +00:00
</p>
</nav>
Show the profile form in a dialog using HTMx Had to split the actual page content and the breadcrumbs because they do not belong in a dialog. However, i had to change all templates to do that.
2023-03-20 12:09:52 +00:00
{{- end }}
{{ define "content" }}
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.editContactPage*/ -}}
Improve the CSS and general design
2023-05-23 21:13:21 +00:00
<section id="edit-contact-dialog-content" data-hx-target="main">
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
<h2>{{printf (pgettext "Edit Contact “%s”" "title") .ContactName }}</h2>
Move back most dialogs to regular (but still boosted) pages With Oriol agreed that adding or editing invoices, products, and contacts is not just a “user interruption” but the main flow of the program, and, as such, it is not correct to use dialogs for these. More importantly, it was harder to concentrate, specially with the more involved form of invoices, because of all the “noise” behind the dialog.
2023-04-25 13:28:55 +00:00
<form method="POST" action="{{ companyURI "/contacts/" }}{{ .Slug }}" data-hx-boost="true">
Add the edit contact page
2023-02-03 12:29:10 +00:00
{{ csrfToken }}
{{ putMethod }}
Add breadcrumbs
2023-02-03 12:58:10 +00:00
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
{{ with .Form }}
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
<fieldset class="contact-data">
{{ template "input-field" .Name }}
{{ template "input-field" .Phone }}
{{ template "input-field" .Email }}
{{ template "input-field" .Web }}
{{ template "tags-field" .Tags }}
</fieldset>
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
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
<fieldset class="contact-data">
{{ template "input-field" .IBAN }}
{{ template "input-field" .BIC }}
</fieldset>
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
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
{{ template "check-field" .HasTaxDetails }}
<fieldset class="contact-data contact-tax-details">
{{ template "input-field" .BusinessName }}
{{ template "input-field" .VATIN }}
{{ template "input-field" .Address }}
{{ template "input-field" .City }}
{{ template "input-field" .Province }}
{{ template "input-field" .PostalCode }}
{{ template "select-field" .Country }}
</fieldset>
Put the edit contact form into a dialog with HTMx Had to change the data context for that template to include the Slug, so that the <form> element can set the correct `action` instead of using the current URI, as it is no longer “correct” (form-wise) when using HTMx.
2023-03-23 09:46:14 +00:00
{{ end }}
Add the edit contact page
2023-02-03 12:29:10 +00:00
<fieldset>
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
<button formnovalidate class="primary" type="submit">{{( pgettext "Save" "action" )}}</button>
Add the edit contact page
2023-02-03 12:29:10 +00:00
</fieldset>
</form>
</section>
{{- end }}