2023-02-12 20:06:48 +00:00
|
|
|
{{ define "title" -}}
|
|
|
|
{{( pgettext "Add Products to Invoice" "title" )}}
|
|
|
|
{{- end }}
|
|
|
|
|
2023-03-20 12:09:52 +00:00
|
|
|
{{ define "breadcrumbs" -}}
|
2023-02-12 20:06:48 +00:00
|
|
|
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.newInvoiceProductsPage*/ -}}
|
|
|
|
<nav>
|
|
|
|
<p>
|
|
|
|
<a href="{{ companyURI "/" }}">{{( pgettext "Home" "title" )}}</a> /
|
|
|
|
<a href="{{ companyURI "/invoices"}}">{{( pgettext "Invoices" "title" )}}</a> /
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
{{ if eq .Form.Number "" }}
|
2023-03-13 14:00:35 +00:00
|
|
|
<a>{{( pgettext "New Invoice" "title" )}}</a>
|
|
|
|
{{ else }}
|
|
|
|
<a>{{ .Form.Number }}</a>
|
|
|
|
{{ end }}
|
2023-02-12 20:06:48 +00:00
|
|
|
</p>
|
|
|
|
</nav>
|
2023-03-20 12:09:52 +00:00
|
|
|
{{- end }}
|
|
|
|
|
|
|
|
{{ define "content" }}
|
|
|
|
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.newInvoiceProductsPage*/ -}}
|
2023-03-31 11:01:26 +00:00
|
|
|
<section class="dialog-content" id="invoice-dialog-content" data-hx-target="this">
|
2023-02-12 20:06:48 +00:00
|
|
|
<h2>{{(pgettext "Add Products to Invoice" "title")}}</h2>
|
2023-03-31 11:01:26 +00:00
|
|
|
<form method="POST" action="{{ .Action }}" data-hx-boost="true" data-hx-select="#invoice-dialog-content">
|
2023-02-12 20:06:48 +00:00
|
|
|
{{ csrfToken }}
|
|
|
|
|
|
|
|
{{- with .Form }}
|
|
|
|
{{ template "hidden-select-field" .Customer }}
|
|
|
|
{{ template "hidden-field" .Date }}
|
|
|
|
{{ template "hidden-field" .Notes }}
|
2023-03-10 13:02:55 +00:00
|
|
|
{{ template "hidden-field" .Tags }}
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
|
|
{{- range $product := .Products }}
|
2023-04-01 13:58:50 +00:00
|
|
|
{{ template "hidden-field" .InvoiceProductId }}
|
|
|
|
{{ template "hidden-field" .ProductId }}
|
|
|
|
{{ template "hidden-field" .Name }}
|
|
|
|
{{ template "hidden-field" .Description }}
|
|
|
|
{{ template "hidden-field" .Price }}
|
|
|
|
{{ template "hidden-field" .Quantity }}
|
|
|
|
{{ template "hidden-field" .Discount }}
|
|
|
|
{{ template "hidden-select-field" .Tax }}
|
2023-02-12 20:06:48 +00:00
|
|
|
{{- end }}
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
|
<table>
|
|
|
|
<thead>
|
|
|
|
<tr>
|
|
|
|
<th>{{( pgettext "All" "product" )}}</th>
|
|
|
|
<th>{{( pgettext "Name" "title" )}}</th>
|
|
|
|
<th>{{( pgettext "Price" "title" )}}</th>
|
|
|
|
</tr>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
{{ with .Products }}
|
|
|
|
{{- range $product, $key := . }}
|
|
|
|
<tr>
|
|
|
|
<td><input type="checkbox" name="id" id="new-product-id-{{$key}}" value="{{.Id}}"></td>
|
|
|
|
<td><label for="new-product-id-{{$key}}">{{ .Name }}</label></td>
|
Add currency_pattern to language relation
The design calls for rendering all amounts with their currency symbol,
but golang.org/x/text’s currency package always render the symbol in
front, which is wrong in Catalan and Spanish, and a lot of other
languages.
Consulting the Internet, the most popular package for that is
accounting[0], which is almost as useless because they confuse locale
with the currency’s country of origin’s “usual locale” (e.g., en-US for
USD), which is also wrong: in Catalan i need to write USD prices as
"1.234,56 $" regardless of what Americans do.
With accounting i have the recourse of initializing the struct that
holds all the “locale” information, which is also wrong because i have
to define the decimal and thousands separators, something that depends
only on the locale, next to the currency’s precision, that is
locale-independent. But, since all CLDR data from golang.org/x/text
is inside an internal package, i can not access it and would need to
define all that information myself, which defeats the purpose of using
an external package.
Since for now i only need the format pattern for currency, i just saved
it into the database of available languages, that i do not expect to
grow too much.
[0]: https://github.com/leekchan/accounting
2023-02-23 11:12:33 +00:00
|
|
|
<td class="numeric">{{ .Price | formatPrice }}</td>
|
2023-02-12 20:06:48 +00:00
|
|
|
</tr>
|
|
|
|
{{- end }}
|
|
|
|
{{ else }}
|
|
|
|
<tr>
|
|
|
|
<td colspan="4">{{( gettext "No products added yet." )}}</td>
|
|
|
|
</tr>
|
|
|
|
{{ end }}
|
|
|
|
</tbody>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
<fieldset>
|
2023-02-27 12:13:28 +00:00
|
|
|
<button class="primary" type="submit"
|
|
|
|
name="action" value="add-products">{{( pgettext "Add products" "action" )}}</button>
|
2023-02-12 20:06:48 +00:00
|
|
|
</fieldset>
|
|
|
|
</form>
|
|
|
|
</section>
|
|
|
|
{{- end }}
|