tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/pkg/contacts.go

600 lines
17 KiB
Go
Raw Normal View History

Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
package pkg
import (
"context"
Add the contact filter form
2023-05-10 16:56:07 +00:00
"fmt"
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
"github.com/julienschmidt/httprouter"
Allow importing contacts from Holded This allows to import an Excel file exported from Holded, because it is our own user case. When we have more customers, we will give out an Excel template file to fill out. Why XLSX files instead of CSV, for instance? First, because this is the output from Holded, but even then we would have more trouble with CSV than with XLSX because of Microsoft: they royally fucked up interoperability when decided that CSV files, the files that only other applications or programmers see, should be “localized”, and use a comma or a **semicolon** to separate a **comma** separated file depending on the locale’s decimal separator. This is ridiculous because it means that CSV files created with an Excel in USA uses comma while the same Excel but with a French locale expects the fields to be separated by semicolon. And for no good reason, either. Since they fucked up so bad, decided to add a non-standard “meta” field to specify the separator, writing a `sep=,` in the first line, but this only works for reading, because saving the same file changes the separator back to the locale-dependent character and removes the “meta” field. And since everyone expects to open spreadsheet with Excel, i can not use CSV if i do not want a bunch of support tickets telling me that the template is all in a single line. I use an extremely old version of a xlsx reading library for golang[0] because it is already available in Debian repositories, and the only thing i want from it is to convert the convoluted XML file into a string array. Go is only responsible to read the file and dump its contents into a temporary table, so that it can execute the PL/pgSQL function that will actually move that data to the correct relations, much like add_contact does but in batch. In PostgreSQL version 16 they added a pg_input_is_valid function that i would use to test whether input values really conform to domains, but i will have to wait for Debian to pick up the new version. Meanwhile, i use a couple of temporary functions, in lieu of nested functions support in PostgreSQL. Part of #45 [0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
"github.com/tealeg/xlsx"
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
"html/template"
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
"net/http"
Add the contact filter form
2023-05-10 16:56:07 +00:00
"strings"
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
)
type ContactEntry struct {
Add the edit contact page
2023-02-03 12:29:10 +00:00
Slug string
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
Name string
Email string
Phone string
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
Tags []string
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
}
type ContactsIndexPage struct {
Contacts []*ContactEntry
Add the contact filter form
2023-05-10 16:56:07 +00:00
Filters *contactFilterForm
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
}
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
func IndexContacts(w http.ResponseWriter, r *http.Request, _ httprouter.Params) {
conn := getConn(r)
Add companyURI for Go code too, not just templates
2023-02-04 09:43:42 +00:00
company := mustGetCompany(r)
Add the contact filter form
2023-05-10 16:56:07 +00:00
locale := getLocale(r)
filters := newContactFilterForm(locale)
if err := filters.Parse(r); err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
page := &ContactsIndexPage{
Add the contact filter form
2023-05-10 16:56:07 +00:00
Contacts: mustCollectContactEntries(r.Context(), conn, company, filters),
Filters: filters,
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
}
Boost the main navigation links with HTMx I am not sure if, at the end, all pages that now use mustRenderAppTemplate will be replaced with mustRenderMainTemplate, but for now i keep them separate to know which routes are already “boosted”.
2023-03-23 09:55:02 +00:00
mustRenderMainTemplate(w, r, "contacts/index.gohtml", page)
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
}
Add the edit contact page
2023-02-03 12:29:10 +00:00
func GetContactForm(w http.ResponseWriter, r *http.Request, params httprouter.Params) {
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
locale := getLocale(r)
conn := getConn(r)
Add the edit contact page
2023-02-03 12:29:10 +00:00
slug := params[0].Value
Allow importing contacts from Holded This allows to import an Excel file exported from Holded, because it is our own user case. When we have more customers, we will give out an Excel template file to fill out. Why XLSX files instead of CSV, for instance? First, because this is the output from Holded, but even then we would have more trouble with CSV than with XLSX because of Microsoft: they royally fucked up interoperability when decided that CSV files, the files that only other applications or programmers see, should be “localized”, and use a comma or a **semicolon** to separate a **comma** separated file depending on the locale’s decimal separator. This is ridiculous because it means that CSV files created with an Excel in USA uses comma while the same Excel but with a French locale expects the fields to be separated by semicolon. And for no good reason, either. Since they fucked up so bad, decided to add a non-standard “meta” field to specify the separator, writing a `sep=,` in the first line, but this only works for reading, because saving the same file changes the separator back to the locale-dependent character and removes the “meta” field. And since everyone expects to open spreadsheet with Excel, i can not use CSV if i do not want a bunch of support tickets telling me that the template is all in a single line. I use an extremely old version of a xlsx reading library for golang[0] because it is already available in Debian repositories, and the only thing i want from it is to convert the convoluted XML file into a string array. Go is only responsible to read the file and dump its contents into a temporary table, so that it can execute the PL/pgSQL function that will actually move that data to the correct relations, much like add_contact does but in batch. In PostgreSQL version 16 they added a pg_input_is_valid function that i would use to test whether input values really conform to domains, but i will have to wait for Debian to pick up the new version. Meanwhile, i use a couple of temporary functions, in lieu of nested functions support in PostgreSQL. Part of #45 [0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
if slug == "import" {
ServeImportPage(w, r, params)
return
}
form := newContactForm(r.Context(), conn, locale)
Add the edit contact page
2023-02-03 12:29:10 +00:00
if slug == "new" {
w.WriteHeader(http.StatusOK)
mustRenderNewContactForm(w, r, form)
return
}
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
if !form.MustFillFromDatabase(r.Context(), conn, slug) {
Refactor checking for pgx.ErrNoRows in a function
2023-02-14 11:46:11 +00:00
http.NotFound(w, r)
return
Add the edit contact page
2023-02-03 12:29:10 +00:00
}
w.WriteHeader(http.StatusOK)
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
mustRenderEditContactForm(w, r, slug, form)
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
}
Add the edit contact page
2023-02-03 12:29:10 +00:00
func mustRenderNewContactForm(w http.ResponseWriter, r *http.Request, form *contactForm) {
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
mustRenderMainTemplate(w, r, "contacts/new.gohtml", form)
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +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
type editContactPage struct {
Slug string
ContactName string
Form *contactForm
}
func mustRenderEditContactForm(w http.ResponseWriter, r *http.Request, slug string, form *contactForm) {
page := &editContactPage{
Slug: slug,
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
ContactName: form.Name.String(),
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
Form: form,
}
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
mustRenderMainTemplate(w, r, "contacts/edit.gohtml", page)
Add the edit contact page
2023-02-03 12:29:10 +00:00
}
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
func HandleAddContact(w http.ResponseWriter, r *http.Request, _ httprouter.Params) {
conn := getConn(r)
locale := getLocale(r)
form := newContactForm(r.Context(), conn, locale)
if err := form.Parse(r); err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
if err := verifyCsrfTokenValid(r); err != nil {
http.Error(w, err.Error(), http.StatusForbidden)
return
}
if !form.Validate(r.Context(), conn) {
Show the add contact form in a modal dialog
2023-03-22 13:59:54 +00:00
if !IsHTMxRequest(r) {
w.WriteHeader(http.StatusUnprocessableEntity)
}
Add the edit contact page
2023-02-03 12:29:10 +00:00
mustRenderNewContactForm(w, r, form)
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
return
}
Add companyURI for Go code too, not just templates
2023-02-04 09:43:42 +00:00
company := mustGetCompany(r)
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
conn.MustExec(r.Context(), "select add_contact($1, $2, $3, $4, $5, $6, $7, $8, $9)", company.Id, form.Name, form.Phone, form.Email, form.Web, form.TaxDetails(), form.IBAN, form.BIC, form.Tags)
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
htmxRedirect(w, r, companyURI(company, "/contacts"))
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
}
Add the edit contact page
2023-02-03 12:29:10 +00:00
func HandleUpdateContact(w http.ResponseWriter, r *http.Request, params httprouter.Params) {
conn := getConn(r)
locale := getLocale(r)
form := newContactForm(r.Context(), conn, locale)
if err := form.Parse(r); err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
if err := verifyCsrfTokenValid(r); err != nil {
http.Error(w, err.Error(), http.StatusForbidden)
return
}
if !form.Validate(r.Context(), conn) {
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
mustRenderEditContactForm(w, r, params[0].Value, form)
Add the edit contact page
2023-02-03 12:29:10 +00:00
return
}
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
slug := conn.MustGetText(r.Context(), "", "select edit_contact($1, $2, $3, $4, $5, $6, $7, $8, $9)", params[0].Value, form.Name, form.Phone, form.Email, form.Web, form.TaxDetails(), form.IBAN, form.BIC, form.Tags)
Add the edit contact page
2023-02-03 12:29:10 +00:00
if slug == "" {
http.NotFound(w, r)
}
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
htmxRedirect(w, r, companyURI(mustGetCompany(r), "/contacts"))
Add the edit contact page
2023-02-03 12:29:10 +00:00
}
Add the contact filter form
2023-05-10 16:56:07 +00:00
type contactFilterForm struct {
Name *InputField
Tags *TagsField
TagsCondition *ToggleField
}
func newContactFilterForm(locale *Locale) *contactFilterForm {
return &contactFilterForm{
Name: &InputField{
Name: "number",
Label: pgettext("input", "Name", locale),
Type: "search",
},
Tags: &TagsField{
Name: "tags",
Label: pgettext("input", "Tags", locale),
},
TagsCondition: &ToggleField{
Name: "tags_condition",
Label: pgettext("input", "Tags Condition", locale),
Selected: "and",
FirstOption: &ToggleOption{
Value: "and",
Label: pgettext("tag condition", "All", locale),
Description: gettext("Invoices must have all the specified labels.", locale),
},
SecondOption: &ToggleOption{
Value: "or",
Label: pgettext("tag condition", "Any", locale),
Description: gettext("Invoices must have at least one of the specified labels.", locale),
},
},
}
}
func (form *contactFilterForm) Parse(r *http.Request) error {
if err := r.ParseForm(); err != nil {
return err
}
form.Name.FillValue(r)
form.Tags.FillValue(r)
form.TagsCondition.FillValue(r)
return nil
}
func mustCollectContactEntries(ctx context.Context, conn *Conn, company *Company, filters *contactFilterForm) []*ContactEntry {
args := []interface{}{company.Id}
where := []string{"contact.company_id = $1"}
appendWhere := func(expression string, value interface{}) {
args = append(args, value)
where = append(where, fmt.Sprintf(expression, len(args)))
}
if filters != nil {
name := strings.TrimSpace(filters.Name.String())
if name != "" {
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
appendWhere("contact.name ilike $%d", "%"+name+"%")
Add the contact filter form
2023-05-10 16:56:07 +00:00
}
if len(filters.Tags.Tags) > 0 {
if filters.TagsCondition.Selected == "and" {
appendWhere("contact.tags @> $%d", filters.Tags)
} else {
appendWhere("contact.tags && $%d", filters.Tags)
}
}
}
rows := conn.MustQuery(ctx, fmt.Sprintf(`
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
select slug
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
, name
, coalesce(email::text, '')
, coalesce(phone::text, '')
Replace tag relations with array attributes It all started when i wanted to try to filter invoices by multiple tags using an “AND”, instead of “OR” as it was doing until now. But something felt off and seemed to me that i was doing thing much more complex than needed, all to be able to list the tags as a suggestion in the input field—which i am not doing yet. I found this article series[0] exploring different approaches for tagging, which includes the one i was using, and comparing their performance. I have not actually tested it, but it seems that i have chosen the worst option, in both query time and storage. I attempted to try using an array attribute to each table, which is more or less the same they did in the articles but without using a separate relation for tags, and i found out that all the queries were way easier to write, and needed two joins less, so it was a no-brainer. [0]: http://www.databasesoup.com/2015/01/tag-all-things.html
2023-04-07 19:31:35 +00:00
, tags
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
from contact
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
left join contact_email using (contact_id)
left join contact_phone using (contact_id)
Add the contact filter form
2023-05-10 16:56:07 +00:00
where (%s)
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
order by name
Add the contact filter form
2023-05-10 16:56:07 +00:00
`, strings.Join(where, ") AND (")), args...)
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
defer rows.Close()
var entries []*ContactEntry
for rows.Next() {
entry := &ContactEntry{}
Add the contact filter form
2023-05-10 16:56:07 +00:00
if err := rows.Scan(&entry.Slug, &entry.Name, &entry.Email, &entry.Phone, &entry.Tags); err != nil {
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
panic(err)
}
entries = append(entries, entry)
}
if rows.Err() != nil {
panic(rows.Err())
}
return entries
}
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
type contactForm struct {
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
locale *Locale
Name *InputField
HasTaxDetails *CheckField
BusinessName *InputField
VATIN *InputField
Phone *InputField
Email *InputField
Web *InputField
Address *InputField
City *InputField
Province *InputField
PostalCode *InputField
Country *SelectField
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
IBAN *InputField
BIC *InputField
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
Tags *TagsField
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
}
func newContactForm(ctx context.Context, conn *Conn, locale *Locale) *contactForm {
return &contactForm{
locale: locale,
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
Name: &InputField{
Name: "name",
Label: pgettext("input", "Name", locale),
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
Type: "text",
Required: true,
},
Phone: &InputField{
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
Name: "phone",
Label: pgettext("input", "Phone", locale),
Type: "tel",
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
Attributes: []template.HTMLAttr{
`autocomplete="tel"`,
},
},
Email: &InputField{
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
Name: "email",
Label: pgettext("input", "Email", locale),
Type: "email",
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
Attributes: []template.HTMLAttr{
`autocomplete="email"`,
},
},
Web: &InputField{
Name: "web",
Label: pgettext("input", "Web", locale),
Type: "url",
Attributes: []template.HTMLAttr{
`autocomplete="url"`,
},
},
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
HasTaxDetails: &CheckField{
Name: "has_tax_details",
Label: pgettext("input", "Need to input tax details", locale),
},
BusinessName: &InputField{
Name: "business_name",
Label: pgettext("input", "Business name", locale),
Type: "text",
Required: true,
Attributes: []template.HTMLAttr{
`autocomplete="organization"`,
`minlength="2"`,
},
},
VATIN: &InputField{
Name: "vatin",
Label: pgettext("input", "VAT number", locale),
Type: "text",
Required: true,
},
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
Address: &InputField{
Name: "address",
Label: pgettext("input", "Address", locale),
Type: "text",
Required: true,
Attributes: []template.HTMLAttr{
`autocomplete="address-line1"`,
},
},
City: &InputField{
Name: "city",
Label: pgettext("input", "City", locale),
Type: "text",
Required: true,
},
Province: &InputField{
Name: "province",
Label: pgettext("input", "Province", locale),
Type: "text",
Required: true,
},
PostalCode: &InputField{
Name: "postal_code",
Label: pgettext("input", "Postal code", locale),
Type: "text",
Required: true,
Attributes: []template.HTMLAttr{
`autocomplete="postal-code"`,
},
},
Country: &SelectField{
Name: "country",
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
Label: pgettext("input", "Country", locale),
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
Options: mustGetCountryOptions(ctx, conn, locale),
Allow optional select with empty label This is not yet necessary, but the empty label is because i do not want to select a default tax for products—at least, not without a setting for it. Since i need to add the required attribute now to select, because otherwise the browser would allow sending that empty value, i did not want to do it unconditionally, just in case.
2023-02-05 13:06:33 +00:00
Required: true,
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
Selected: []string{"ES"},
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
Attributes: []template.HTMLAttr{
`autocomplete="country"`,
},
},
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
IBAN: &InputField{
Name: "iban",
Label: pgettext("input", "IBAN", locale),
Type: "text",
},
BIC: &InputField{
Name: "bic",
Label: pgettext("bic", "BIC", locale),
Type: "text",
},
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
Tags: &TagsField{
Name: "tags",
Label: pgettext("input", "Tags", locale),
},
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
}
}
func (form *contactForm) Parse(r *http.Request) error {
if err := r.ParseForm(); err != nil {
return err
}
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
form.Name.FillValue(r)
form.HasTaxDetails.FillValue(r)
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
form.BusinessName.FillValue(r)
form.VATIN.FillValue(r)
form.Phone.FillValue(r)
form.Email.FillValue(r)
form.Web.FillValue(r)
form.Address.FillValue(r)
form.City.FillValue(r)
form.Province.FillValue(r)
form.PostalCode.FillValue(r)
form.Country.FillValue(r)
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
form.IBAN.FillValue(r)
form.BIC.FillValue(r)
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
form.Tags.FillValue(r)
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
return nil
}
func (form *contactForm) Validate(ctx context.Context, conn *Conn) bool {
validator := newFormValidator()
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
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
country := "ES"
if form.HasTaxDetails.Checked {
if validator.CheckValidSelectOption(form.Country, gettext("Selected country is not valid.", form.locale)) {
country = form.Country.Selected[0]
}
Create validation function for SQL domains and for phones When i wrote the functions to import contact, i already created a couple of “temporary” functions to validate whether the input given from the Excel files was correct according to the various domains used in the relations, so i can know whether i can import that data. I realized that i could do exactly the same when validating forms: check that the value conforms to the domain, in the exact same way, so i can make sure that the value will be accepted without duplicating the logic, at the expense of a call to the database. In an ideal world, i would use pg_input_is_valid, but this function is only available in PostgreSQL 16 and Debian 12 uses PostgreSQL 15. These functions are in the public schema because initially i wanted to use them to also validate email, which is needed in the login form, but then i recanted and kept the same email validation in Go, because something felt off about using the database for that particular form, but i do not know why.
2023-07-03 09:31:59 +00:00
if validator.CheckRequiredInput(form.BusinessName, gettext("Business name can not be empty.", form.locale)) {
validator.CheckInputMinLength(form.BusinessName, 2, gettext("Business name must have at least two letters.", form.locale))
}
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
if validator.CheckRequiredInput(form.VATIN, gettext("VAT number can not be empty.", form.locale)) {
Create validation function for SQL domains and for phones When i wrote the functions to import contact, i already created a couple of “temporary” functions to validate whether the input given from the Excel files was correct according to the various domains used in the relations, so i can know whether i can import that data. I realized that i could do exactly the same when validating forms: check that the value conforms to the domain, in the exact same way, so i can make sure that the value will be accepted without duplicating the logic, at the expense of a call to the database. In an ideal world, i would use pg_input_is_valid, but this function is only available in PostgreSQL 16 and Debian 12 uses PostgreSQL 15. These functions are in the public schema because initially i wanted to use them to also validate email, which is needed in the login form, but then i recanted and kept the same email validation in Go, because something felt off about using the database for that particular form, but i do not know why.
2023-07-03 09:31:59 +00:00
validator.CheckValidVATINInput(ctx, conn, form.VATIN, country, gettext("This value is not a valid VAT number.", form.locale))
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
}
validator.CheckRequiredInput(form.Address, gettext("Address can not be empty.", form.locale))
validator.CheckRequiredInput(form.City, gettext("City can not be empty.", form.locale))
validator.CheckRequiredInput(form.Province, gettext("Province can not be empty.", form.locale))
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
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
if validator.CheckRequiredInput(form.PostalCode, gettext("Postal code can not be empty.", form.locale)) {
validator.CheckValidPostalCode(ctx, conn, form.PostalCode, country, gettext("This value is not a valid postal code.", form.locale))
}
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
}
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
Create validation function for SQL domains and for phones When i wrote the functions to import contact, i already created a couple of “temporary” functions to validate whether the input given from the Excel files was correct according to the various domains used in the relations, so i can know whether i can import that data. I realized that i could do exactly the same when validating forms: check that the value conforms to the domain, in the exact same way, so i can make sure that the value will be accepted without duplicating the logic, at the expense of a call to the database. In an ideal world, i would use pg_input_is_valid, but this function is only available in PostgreSQL 16 and Debian 12 uses PostgreSQL 15. These functions are in the public schema because initially i wanted to use them to also validate email, which is needed in the login form, but then i recanted and kept the same email validation in Go, because something felt off about using the database for that particular form, but i do not know why.
2023-07-03 09:31:59 +00:00
if validator.CheckRequiredInput(form.Name, gettext("Name can not be empty.", form.locale)) {
validator.CheckInputMinLength(form.Name, 2, gettext("Name must have at least two letters.", form.locale))
}
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
if form.Phone.Val != "" {
Create validation function for SQL domains and for phones When i wrote the functions to import contact, i already created a couple of “temporary” functions to validate whether the input given from the Excel files was correct according to the various domains used in the relations, so i can know whether i can import that data. I realized that i could do exactly the same when validating forms: check that the value conforms to the domain, in the exact same way, so i can make sure that the value will be accepted without duplicating the logic, at the expense of a call to the database. In an ideal world, i would use pg_input_is_valid, but this function is only available in PostgreSQL 16 and Debian 12 uses PostgreSQL 15. These functions are in the public schema because initially i wanted to use them to also validate email, which is needed in the login form, but then i recanted and kept the same email validation in Go, because something felt off about using the database for that particular form, but i do not know why.
2023-07-03 09:31:59 +00:00
validator.CheckValidPhoneInput(ctx, conn, form.Phone, country, gettext("This value is not a valid phone number.", form.locale))
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
}
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
if form.Email.Val != "" {
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
validator.CheckValidEmailInput(form.Email, gettext("This value is not a valid email. It should be like name@domain.com.", form.locale))
}
if form.Web.Val != "" {
Make FormValidator.CheckValidDate method public
2023-02-12 20:01:20 +00:00
validator.CheckValidURL(form.Web, gettext("This value is not a valid web address. It should be like https://domain.com/.", form.locale))
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +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
if form.IBAN.Val != "" {
Create validation function for SQL domains and for phones When i wrote the functions to import contact, i already created a couple of “temporary” functions to validate whether the input given from the Excel files was correct according to the various domains used in the relations, so i can know whether i can import that data. I realized that i could do exactly the same when validating forms: check that the value conforms to the domain, in the exact same way, so i can make sure that the value will be accepted without duplicating the logic, at the expense of a call to the database. In an ideal world, i would use pg_input_is_valid, but this function is only available in PostgreSQL 16 and Debian 12 uses PostgreSQL 15. These functions are in the public schema because initially i wanted to use them to also validate email, which is needed in the login form, but then i recanted and kept the same email validation in Go, because something felt off about using the database for that particular form, but i do not know why.
2023-07-03 09:31:59 +00:00
validator.CheckValidIBANInput(ctx, conn, form.IBAN, gettext("This values is not a valid IBAN.", form.locale))
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
}
if form.BIC.Val != "" {
Create validation function for SQL domains and for phones When i wrote the functions to import contact, i already created a couple of “temporary” functions to validate whether the input given from the Excel files was correct according to the various domains used in the relations, so i can know whether i can import that data. I realized that i could do exactly the same when validating forms: check that the value conforms to the domain, in the exact same way, so i can make sure that the value will be accepted without duplicating the logic, at the expense of a call to the database. In an ideal world, i would use pg_input_is_valid, but this function is only available in PostgreSQL 16 and Debian 12 uses PostgreSQL 15. These functions are in the public schema because initially i wanted to use them to also validate email, which is needed in the login form, but then i recanted and kept the same email validation in Go, because something felt off about using the database for that particular form, but i do not know why.
2023-07-03 09:31:59 +00:00
validator.CheckValidBICInput(ctx, conn, form.BIC, gettext("This values is not a valid BIC.", form.locale))
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
}
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
Use a proper struct for the contact’s form Our company is a kind-of contact, although it does not appear in the contact section, thus i could embed the contact form inside the tax details form to reuse all the common fields.
2023-02-01 13:34:40 +00:00
return validator.AllOK()
Add the contact relation and a rough first form
2023-01-29 14:14:31 +00:00
}
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
func (form *contactForm) MustFillFromDatabase(ctx context.Context, conn *Conn, slug string) bool {
return !notFoundErrorOrPanic(conn.QueryRow(ctx, `
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
select name
, vatin is not null
, business_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
, substr(vatin::text, 3)
, phone
, email
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
, uri
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
, address
, city
, province
, postal_code
, country_code
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
, iban
, bic
There is no need for array_to_string() in tags
2023-05-27 19:36:10 +00:00
, tags
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
from contact
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
left join contact_email using (contact_id)
left join contact_phone using (contact_id)
left join contact_web using (contact_id)
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
left join contact_iban using (contact_id)
left join contact_swift using (contact_id)
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
left join contact_tax_details using (contact_id)
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
where slug = $1
`, slug).Scan(
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
form.Name,
form.HasTaxDetails,
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
form.BusinessName,
form.VATIN,
form.Phone,
form.Email,
form.Web,
form.Address,
form.City,
form.Province,
form.PostalCode,
form.Country,
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
form.IBAN,
form.BIC,
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
form.Tags))
}
Add contact’s inline form for tags
2023-05-12 09:32:39 +00:00
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
func (form *contactForm) TaxDetails() *CustomerTaxDetails {
if !form.HasTaxDetails.Checked {
return nil
}
return &CustomerTaxDetails{
BusinessName: form.BusinessName.String(),
VATIN: form.VATIN.String(),
Address: form.Address.String(),
City: form.City.String(),
Province: form.Province.String(),
PostalCode: form.PostalCode.String(),
CountryCode: form.Country.String(),
}
}
Add contact’s inline form for tags
2023-05-12 09:32:39 +00:00
func ServeEditContactTags(w http.ResponseWriter, r *http.Request, params httprouter.Params) {
conn := getConn(r)
locale := getLocale(r)
company := getCompany(r)
slug := params[0].Value
form := newTagsForm(companyURI(company, "/contacts/"+slug+"/tags"), slug, locale)
There is no need for array_to_string() in tags
2023-05-27 19:36:10 +00:00
if notFoundErrorOrPanic(conn.QueryRow(r.Context(), `select tags from contact where slug = $1`, form.Slug).Scan(form.Tags)) {
Add contact’s inline form for tags
2023-05-12 09:32:39 +00:00
http.NotFound(w, r)
return
}
mustRenderStandaloneTemplate(w, r, "tags/edit.gohtml", form)
}
func HandleUpdateContactTags(w http.ResponseWriter, r *http.Request, params httprouter.Params) {
locale := getLocale(r)
conn := getConn(r)
company := getCompany(r)
slug := params[0].Value
form := newTagsForm(companyURI(company, "/contacts/"+slug+"/tags/edit"), slug, locale)
if err := form.Parse(r); err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
if err := verifyCsrfTokenValid(r); err != nil {
http.Error(w, err.Error(), http.StatusForbidden)
return
}
if conn.MustGetText(r.Context(), "", "update contact set tags = $1 where slug = $2 returning slug", form.Tags, form.Slug) == "" {
http.NotFound(w, r)
}
mustRenderStandaloneTemplate(w, r, "tags/view.gohtml", form)
}
Allow importing contacts from Holded This allows to import an Excel file exported from Holded, because it is our own user case. When we have more customers, we will give out an Excel template file to fill out. Why XLSX files instead of CSV, for instance? First, because this is the output from Holded, but even then we would have more trouble with CSV than with XLSX because of Microsoft: they royally fucked up interoperability when decided that CSV files, the files that only other applications or programmers see, should be “localized”, and use a comma or a **semicolon** to separate a **comma** separated file depending on the locale’s decimal separator. This is ridiculous because it means that CSV files created with an Excel in USA uses comma while the same Excel but with a French locale expects the fields to be separated by semicolon. And for no good reason, either. Since they fucked up so bad, decided to add a non-standard “meta” field to specify the separator, writing a `sep=,` in the first line, but this only works for reading, because saving the same file changes the separator back to the locale-dependent character and removes the “meta” field. And since everyone expects to open spreadsheet with Excel, i can not use CSV if i do not want a bunch of support tickets telling me that the template is all in a single line. I use an extremely old version of a xlsx reading library for golang[0] because it is already available in Debian repositories, and the only thing i want from it is to convert the convoluted XML file into a string array. Go is only responsible to read the file and dump its contents into a temporary table, so that it can execute the PL/pgSQL function that will actually move that data to the correct relations, much like add_contact does but in batch. In PostgreSQL version 16 they added a pg_input_is_valid function that i would use to test whether input values really conform to domains, but i will have to wait for Debian to pick up the new version. Meanwhile, i use a couple of temporary functions, in lieu of nested functions support in PostgreSQL. Part of #45 [0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
func ServeImportPage(w http.ResponseWriter, r *http.Request, _ httprouter.Params) {
form := newContactImportForm(getLocale(r), getCompany(r))
mustRenderMainTemplate(w, r, "contacts/import.gohtml", form)
}
type contactImportForm struct {
locale *Locale
company *Company
File *FileField
}
func newContactImportForm(locale *Locale, company *Company) *contactImportForm {
return &contactImportForm{
locale: locale,
company: company,
File: &FileField{
Name: "file",
Label: pgettext("input", "Holded Excel file", locale),
MaxSize: 1 << 20,
Required: true,
},
}
}
func (form *contactImportForm) Parse(r *http.Request) error {
if err := r.ParseMultipartForm(form.File.MaxSize); err != nil {
return err
}
if err := form.File.FillValue(r); err != nil {
return err
}
return nil
}
func HandleImportContacts(w http.ResponseWriter, r *http.Request, _ httprouter.Params) {
locale := getLocale(r)
company := mustGetCompany(r)
form := newContactImportForm(locale, company)
if err := form.Parse(r); err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
if err := verifyCsrfTokenValid(r); err != nil {
http.Error(w, err.Error(), http.StatusForbidden)
return
}
workbook, err := xlsx.OpenBinary(form.File.Content)
if err != nil {
panic(err)
}
conn := getConn(r)
tx := conn.MustBegin(r.Context())
defer tx.MustRollback(r.Context())
relation := tx.MustGetText(r.Context(), "select begin_import_contacts()")
columns := []string{"name", "vatin", "email", "phone", "address", "city", "postal_code", "province", "country_code", "iban", "bic", "tags"}
for _, sheet := range workbook.Sheets {
tx.MustCopyFrom(r.Context(), relation, columns, len(sheet.Rows)-4, func(idx int) ([]interface{}, error) {
row := sheet.Rows[idx+4]
var values []interface{}
if len(row.Cells) < 23 {
values = []interface{}{"", "", "", "", "", "", "", "", "", "", "", ""}
} else {
phone := row.Cells[5].String() // mobile
if phone == "" {
phone = row.Cells[4].String() // landline
}
values = []interface{}{
row.Cells[1].String(),
row.Cells[2].String(),
row.Cells[3].String(),
phone,
row.Cells[6].String(),
row.Cells[7].String(),
row.Cells[8].String(),
row.Cells[9].String(),
row.Cells[11].String(),
row.Cells[19].String(),
row.Cells[20].String(),
row.Cells[22].String(),
}
}
return values, nil
})
}
tx.MustExec(r.Context(), "select end_import_contacts($1)", company.Id)
tx.MustCommit(r.Context())
htmxRedirect(w, r, companyURI(company, "/contacts"))
}