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

140 lines
6.4 KiB
Plaintext
Raw Normal View History

Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
{{ define "title" -}}
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.PaymentIndexPage*/ -}}
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{- if .Invoice -}}
{{( pgettext "Collections" "title" )}}
{{- else -}}
{{( pgettext "Payments" "title" )}}
{{- end -}}
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
{{- end }}
{{ define "breadcrumbs" -}}
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.PaymentIndexPage*/ -}}
Remove almost all data-hx-boost attributes Since 16e80b5ae, <body> no longer has overflow, thus no scroll. As a consequence, htmx no longer is able to scroll up <main> when it changes due to the default, implicit `show:true` applied to the request: is calls <main>’s scrollIntoView, however there is nothing to scroll to. I probably could fix it by changing the target of `show`, or even add a `scroll` directive to all boosted links, but at this point i think it is better no not boost links at all, as they do what i want—show the new page from the top—with less markup, plus the browser now show a loading animation, and it is not that slower, too.
2024-09-07 23:29:30 +00:00
<nav>
<p>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
<a href="{{ companyURI "/" }}">{{( pgettext "Home" "title" )}}</a> /
Add a new payments “subsection” for expenses With Oriol we agreed that to add new payments to expenses we should direct users to a separate payments section, much like the general payments but centered around the payments of the given expense. In fact, the only thing i had to do is extract the expense from the URL, and then adjust the base URI to keep things always within the correct section; the rest of the code is shared with the general section.
2024-08-17 03:31:01 +00:00
{{ if .Expense }}
<a href="{{ companyURI "/expenses" }}">{{( pgettext "Expenses" "title" )}}</a> /
<a href="{{ companyURI "/expenses/" }}{{ .Expense.Slug }}">{{ .Expense.InvoiceNumber }}</a> /
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{ else if .Invoice }}
<a href="{{ companyURI "/invoices" }}">{{( pgettext "Invoices" "title" )}}</a> /
<a href="{{ companyURI "/invoices/" }}{{ .Invoice.Slug }}">{{ .Invoice.InvoiceNumber }}</a> /
Add a new payments “subsection” for expenses With Oriol we agreed that to add new payments to expenses we should direct users to a separate payments section, much like the general payments but centered around the payments of the given expense. In fact, the only thing i had to do is extract the expense from the URL, and then adjust the base URI to keep things always within the correct section; the rest of the code is shared with the general section.
2024-08-17 03:31:01 +00:00
{{ end }}
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
<a>{{ template "title" . }}</a>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
</p>
Remove almost all data-hx-boost attributes Since 16e80b5ae, <body> no longer has overflow, thus no scroll. As a consequence, htmx no longer is able to scroll up <main> when it changes due to the default, implicit `show:true` applied to the request: is calls <main>’s scrollIntoView, however there is nothing to scroll to. I probably could fix it by changing the target of `show`, or even add a `scroll` directive to all boosted links, but at this point i think it is better no not boost links at all, as they do what i want—show the new page from the top—with less markup, plus the browser now show a loading animation, and it is not that slower, too.
2024-09-07 23:29:30 +00:00
<a class="primary button" href="{{ .BaseURI }}/new">
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{- if .Invoice -}}
{{( pgettext "New collection" "action" )}}
{{- else -}}
{{( pgettext "New payment" "action" )}}
{{- end -}}
</a>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
</nav>
{{- end }}
{{ define "content" }}
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.PaymentIndexPage*/ -}}
<table>
<thead>
<tr>
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
<th>
{{- if .Invoice -}}
{{( pgettext "Collection Date" "title" )}}
{{- else -}}
{{( pgettext "Payment Date" "title" )}}
{{- end -}}
</th>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
<th>{{( pgettext "Description" "title" )}}</th>
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{ if not (or .Invoice .Expense)}}
<th>{{( pgettext "Document" "title" )}}</th>
{{ end }}
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
<th>{{( pgettext "Status" "title" )}}</th>
<th>{{( pgettext "Tags" "title" )}}</th>
<th class="numeric">{{( pgettext "Total" "title" )}}</th>
Add attachments to payments
2024-08-11 22:08:18 +00:00
<th>{{( pgettext "Download" "title" )}}</th>
Allow removal of payments I am using an htmx-infused button to remove the payment, but that button can not have the CSRF token as value, thus i have to send it in a header. The removal of payments warrants a functions, instead of just DELETE (and CASCADE) as i do for payment methods, because i have to adjust the status of expenses too. Since i already have functions for everything, it is not worth using triggers just for that.
2024-08-11 01:22:37 +00:00
<th>{{( pgettext "Actions" "title" )}}</th>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
</tr>
</thead>
<tbody>
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{ $confirm := or (and .Invoice (gettext "Are you sure you wish to delete this collection?")) (gettext "Are you sure you wish to delete this payment?") }}
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
{{ with .Payments }}
{{- range $payment := . }}
<tr>
<td>{{ .PaymentDate|formatDate }}</td>
Add a new payments “subsection” for expenses With Oriol we agreed that to add new payments to expenses we should direct users to a separate payments section, much like the general payments but centered around the payments of the given expense. In fact, the only thing i had to do is extract the expense from the URL, and then adjust the base URI to keep things always within the correct section; the rest of the code is shared with the general section.
2024-08-17 03:31:01 +00:00
<td><a href="{{ $.BaseURI }}/{{ .Slug }}">{{ .Description }}</a></td>
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{ if not (or $.Invoice $.Expense)}}
<td>
{{- if .InvoiceNumber -}}
{{- if eq .Type "P" -}}
<a href="{{ companyURI "/expenses/"}}{{ .DocumentSlug }}">{{ .InvoiceNumber }}</a>
{{- else -}}
Fix the URL to invoices from payment index
2024-08-21 09:23:55 +00:00
<a href="{{ companyURI "/invoices/"}}{{ .DocumentSlug }}">{{ .InvoiceNumber }}</a>
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
{{- end -}}
Add payment collection This is the same as a payment, but the user is the payee instead of the payer. I used a different relation than payment because i do not know any other way to encode the constraint that only invoices can have a collection, while expenses have only payments. Besides the name and the fact that they are related to invoices, a collection is pretty much the same as a payment.
2024-08-21 01:36:12 +00:00
{{- end -}}
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
</td>
{{ end }}
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
<td class="payment-status-{{ .Status }}">{{ .StatusLabel }}</td>
<td
Add a new payments “subsection” for expenses With Oriol we agreed that to add new payments to expenses we should direct users to a separate payments section, much like the general payments but centered around the payments of the given expense. In fact, the only thing i had to do is extract the expense from the URL, and then adjust the base URI to keep things always within the correct section; the rest of the code is shared with the general section.
2024-08-17 03:31:01 +00:00
data-hx-get="{{ companyURI "/payments/" }}{{ .Slug }}/tags/edit"
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
data-hx-target="this"
data-hx-swap="outerHTML"
>
{{- range $index, $tag := .Tags }}
{{- if gt $index 0 }}, {{ end -}}
{{ . }}
{{- end }}
</td>
Show payments in negative in the index
2024-08-21 09:34:26 +00:00
<td class="numeric">{{- if eq .Type "P" -}}-{{ end }}{{ .Total | formatPrice }}</td>
Add attachments to payments
2024-08-11 22:08:18 +00:00
<td class="invoice-download">
{{ if .OriginalFileName }}
<a href="{{ companyURI "/payments/"}}{{ .Slug }}/download/{{.OriginalFileName}}"
title="{{( pgettext "Download payment attachment" "action" )}}"
aria-label="{{( pgettext "Download payment attachment" "action" )}}"><i
class="ri-download-line"></i></a>
{{ end }}
</td>
Allow removal of payments I am using an htmx-infused button to remove the payment, but that button can not have the CSRF token as value, thus i have to send it in a header. The removal of payments warrants a functions, instead of just DELETE (and CASCADE) as i do for payment methods, because i have to adjust the status of expenses too. Since i already have functions for everything, it is not worth using triggers just for that.
2024-08-11 01:22:37 +00:00
<td class="actions">
<details class="menu">
{{- $label := .Description | printf (gettext "Actions for payment %s") -}}
<summary aria-label="{{ $label }}"><i class="ri-more-line"></i></summary>
<ul role="menu" class="action-menu">
<li role="presentation">
Remove almost all data-hx-boost attributes Since 16e80b5ae, <body> no longer has overflow, thus no scroll. As a consequence, htmx no longer is able to scroll up <main> when it changes due to the default, implicit `show:true` applied to the request: is calls <main>’s scrollIntoView, however there is nothing to scroll to. I probably could fix it by changing the target of `show`, or even add a `scroll` directive to all boosted links, but at this point i think it is better no not boost links at all, as they do what i want—show the new page from the top—with less markup, plus the browser now show a loading animation, and it is not that slower, too.
2024-09-07 23:29:30 +00:00
<a role="menuitem" href="{{ $.BaseURI }}/{{ .Slug }}">
Allow removal of payments I am using an htmx-infused button to remove the payment, but that button can not have the CSRF token as value, thus i have to send it in a header. The removal of payments warrants a functions, instead of just DELETE (and CASCADE) as i do for payment methods, because i have to adjust the status of expenses too. Since i already have functions for everything, it is not worth using triggers just for that.
2024-08-11 01:22:37 +00:00
<i class="ri-edit-line"></i>
{{( pgettext "Edit" "action" )}}
</a>
</li>
<li role="presentation">
Replace the htmx-only delete button for payments with a form This way, it also works without JavaScript, that is not that important, maybe, but i like that it does.
2024-09-09 09:33:10 +00:00
<form method="POST" action="{{ $.BaseURI }}/{{ .Slug }}"
data-hx-boost="true"
data-hx-target="main"
data-hx-confirm="{{ $confirm }}"
Allow removal of payments I am using an htmx-infused button to remove the payment, but that button can not have the CSRF token as value, thus i have to send it in a header. The removal of payments warrants a functions, instead of just DELETE (and CASCADE) as i do for payment methods, because i have to adjust the status of expenses too. Since i already have functions for everything, it is not worth using triggers just for that.
2024-08-11 01:22:37 +00:00
>
Replace the htmx-only delete button for payments with a form This way, it also works without JavaScript, that is not that important, maybe, but i like that it does.
2024-09-09 09:33:10 +00:00
{{ csrfToken }}
{{ deleteMethod }}
<button class="icon" role="menuitem">
<i class="ri-delete-back-2-line"></i>
{{( pgettext "Remove" "action" )}}
</button>
</form>
Allow removal of payments I am using an htmx-infused button to remove the payment, but that button can not have the CSRF token as value, thus i have to send it in a header. The removal of payments warrants a functions, instead of just DELETE (and CASCADE) as i do for payment methods, because i have to adjust the status of expenses too. Since i already have functions for everything, it is not worth using triggers just for that.
2024-08-11 01:22:37 +00:00
</li>
</ul>
</details>
</td>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
</tr>
{{- end }}
{{ else }}
<tr>
Add a new collection “subsection” for invoices This is mostly the same subsection as payments is for expense, added in 4f646e35d. In this case i call it “collections”, but it is actually the same payments section.
2024-08-21 09:22:53 +00:00
<td colspan="8">
{{- if .Invoice -}}
{{( gettext "No collections added yet." )}}
{{- else -}}
{{( gettext "No payments added yet." )}}
{{- end -}}
</td>
Add the payments section This actually should be the “payments and receivables” section, however this is quite a mouthful; a “receivable” is a payment made **to** you, therefore “payments” is ok. In fact, there is still no receivables in there, as they should be in a separate relation, to constraint them to invoices instead of expenses. It will be done in a separate commit. Since this section will be, in a sense, sort of simplified accounting, i needed to introduce the “payment account” concept. There is no way, yet, for users to add them, because i have to revamp the “tax details” section, but this commit started to grow too big already. The same reasoning for the attachment payment slips as PDF to payment: something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
</tr>
{{ end }}
</tbody>
</table>
{{- end }}