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

410 lines
12 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"
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)
form := newContactForm(r.Context(), conn, locale)
Add the edit contact page
2023-02-03 12:29:10 +00:00
slug := params[0].Value
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,
ContactName: form.BusinessName.Val,
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 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
conn.MustExec(r.Context(), "select add_contact($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13)", company.Id, form.BusinessName, form.VATIN, form.TradeName, form.Phone, form.Email, form.Web, form.Address, form.City, form.Province, form.PostalCode, form.Country, 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 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
slug := conn.MustGetText(r.Context(), "", "select edit_contact($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13)", params[0].Value, form.BusinessName, form.VATIN, form.TradeName, form.Phone, form.Email, form.Web, form.Address, form.City, form.Province, form.PostalCode, form.Country, 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 != "" {
appendWhere("contact.business_name ilike $%d", "%"+name+"%")
}
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
, business_name
, email
, phone
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
Add the contact filter form
2023-05-10 16:56:07 +00:00
where (%s)
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
order by business_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 {
locale *Locale
BusinessName *InputField
VATIN *InputField
TradeName *InputField
Phone *InputField
Email *InputField
Web *InputField
Address *InputField
City *InputField
Province *InputField
PostalCode *InputField
Country *SelectField
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
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,
BusinessName: &InputField{
Name: "business_name",
Label: pgettext("input", "Business name", locale),
Type: "text",
Required: true,
Attributes: []template.HTMLAttr{
`autocomplete="organization"`,
Add validation for minimum length of contact’s name
2023-04-18 19:01:29 +00:00
`minlength="2"`,
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
},
},
VATIN: &InputField{
Name: "vatin",
Label: pgettext("input", "VAT number", locale),
Type: "text",
Required: true,
},
TradeName: &InputField{
Name: "trade_name",
Label: pgettext("input", "Trade name", locale),
Type: "text",
},
Phone: &InputField{
Name: "phone",
Label: pgettext("input", "Phone", locale),
Type: "tel",
Required: true,
Attributes: []template.HTMLAttr{
`autocomplete="tel"`,
},
},
Email: &InputField{
Name: "email",
Label: pgettext("input", "Email", locale),
Type: "email",
Required: true,
Attributes: []template.HTMLAttr{
`autocomplete="email"`,
},
},
Web: &InputField{
Name: "web",
Label: pgettext("input", "Web", locale),
Type: "url",
Attributes: []template.HTMLAttr{
`autocomplete="url"`,
},
},
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 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
}
form.BusinessName.FillValue(r)
form.VATIN.FillValue(r)
form.TradeName.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 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
country := ""
if validator.CheckValidSelectOption(form.Country, gettext("Selected country is not valid.", form.locale)) {
country = form.Country.Selected[0]
}
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.CheckRequiredInput(form.BusinessName, gettext("Business name can not be empty.", form.locale))
Add validation for minimum length of contact’s name
2023-04-18 19:01:29 +00:00
validator.CheckInputMinLength(form.BusinessName, 2, gettext("Business name must have at least two letters.", 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
if validator.CheckRequiredInput(form.VATIN, gettext("VAT number 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
validator.CheckValidVATINInput(form.VATIN, country, gettext("This value is not a valid VAT 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
}
if validator.CheckRequiredInput(form.Phone, gettext("Phone 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
validator.CheckValidPhoneInput(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
}
if validator.CheckRequiredInput(form.Email, gettext("Email can not be empty.", form.locale)) {
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
}
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))
if validator.CheckRequiredInput(form.PostalCode, gettext("Postal code 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
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
}
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, `
select business_name
, substr(vatin::text, 3)
, trade_name
, phone
, email
, web
, address
, city
, province
, postal_code
, country_code
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
, array_to_string(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
where slug = $1
`, slug).Scan(
form.BusinessName,
form.VATIN,
form.TradeName,
form.Phone,
form.Email,
form.Web,
form.Address,
form.City,
form.Province,
form.PostalCode,
form.Country,
form.Tags))
}