2023-01-13 19:43:42 +00:00
|
|
|
<!doctype html>
|
2023-01-31 14:45:51 +00:00
|
|
|
<html lang="{{ currentLocale }}">
|
2023-01-13 19:43:42 +00:00
|
|
|
<head>
|
|
|
|
<meta charset="utf-8">
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
2024-09-05 12:37:30 +00:00
|
|
|
<meta name="application-name" content="Numerus">
|
|
|
|
<meta name="generator" content="Numerus {{ numerusVersion }}">
|
2023-01-31 12:07:17 +00:00
|
|
|
<title>{{ template "title" . }} — Numerus</title>
|
2024-01-19 22:09:25 +00:00
|
|
|
<link rel="stylesheet" type="text/css" media="screen" href="/static/numerus.css?v={{ numerusVersion }}">
|
2023-04-29 14:20:13 +00:00
|
|
|
<script src="/static/htmx@1.9.2.min.js"></script>
|
Add custom elements polyfill
I use customized built-in components, extended from any HTML elements
(e.g., HTMLDivElement), for product search, multiselect, and tags input
fields. The idea is that people that without JavaScript could still use
the regular, non-customized, inputs.
It turns out, this does not work so well: the CSS assumes that
JavaScript is enabled, and web components supported by the browser. If
one of these fails, then the controls are unusable—the multiselect is
too short, and the tags field accepts invalid characters that the
backend does not validate until it fails with a database error.
We discovered this because Apple does not implement customized built-in
components[0], hence it does not use my JavaScript code and forms,
the expenses forms in particular, are almost useless.
The way to fix this is to replace the regular inputs with autonomous
web components, extended from HTMLElement, using JavaScript, because
it would only do so with JavaScript enabled, and the CSS style would
only apply to these components, not the regular input fields.
However, currently i do not have time to do the proper fix, and have
to use a polyfill for Safari to support customized built-in components.
Shame.
[0]: https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0801.html
2023-11-11 02:32:03 +00:00
|
|
|
<script type="module" src="/static/custom-elements@1.3.0.min.js"></script>
|
2024-01-19 22:09:25 +00:00
|
|
|
<script type="module" src="/static/numerus.js?v={{ numerusVersion }}"></script>
|
2023-03-25 00:56:26 +00:00
|
|
|
<script defer src="/static/alpinejs@3.12.0.min.js"></script>
|
2023-01-13 19:43:42 +00:00
|
|
|
</head>
|
2023-07-14 08:25:39 +00:00
|
|
|
<body class="filters-visible">
|
2023-01-17 21:28:47 +00:00
|
|
|
<header>
|
2024-09-05 12:23:22 +00:00
|
|
|
<h1><img src="/static/numerus.svg" alt="Numerus" width="168" height="21"></h1>
|
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 aria-label="{{( pgettext "Main" "title" )}}">
|
2024-09-04 10:38:37 +00:00
|
|
|
<ul>
|
|
|
|
<li><a{{if requestURIMatches (companyURI "/") }} aria-current="page"{{ end }} href="{{ companyURI "/" }}">{{( pgettext "Dashboard" "nav" )}}</a></li>
|
|
|
|
<li><a{{if requestURIHasPrefix (companyURI "/quotes") }} aria-current="page"{{ end }} href="{{ companyURI "/quotes" }}">{{( pgettext "Quotations" "nav" )}}</a></li>
|
|
|
|
<li><a{{if requestURIHasPrefix (companyURI "/invoices") }} aria-current="page"{{ end }} href="{{ companyURI "/invoices" }}">{{( pgettext "Invoices" "nav" )}}</a></li>
|
|
|
|
<li><a{{if requestURIHasPrefix (companyURI "/expenses") }} aria-current="page"{{ end }} href="{{ companyURI "/expenses" }}">{{( pgettext "Expenses" "nav" )}}</a></li>
|
|
|
|
<li><a{{if requestURIHasPrefix (companyURI "/payments") }} aria-current="page"{{ end }} href="{{ companyURI "/payments" }}">{{( pgettext "Payments" "nav" )}}</a></li>
|
|
|
|
<li><a{{if requestURIHasPrefix (companyURI "/products") }} aria-current="page"{{ end }} href="{{ companyURI "/products" }}">{{( pgettext "Products" "nav" )}}</a></li>
|
|
|
|
<li><a{{if requestURIHasPrefix (companyURI "/contacts") }} aria-current="page"{{ end }} href="{{ companyURI "/contacts" }}">{{( pgettext "Contacts" "nav" )}}</a></li>
|
|
|
|
</ul>
|
|
|
|
</nav>
|
2023-03-07 10:52:09 +00:00
|
|
|
<details id="profile-menu" class="menu">
|
2023-07-06 09:49:36 +00:00
|
|
|
<summary aria-label="{{( gettext "Profile menu" )}}">
|
2024-09-05 12:23:22 +00:00
|
|
|
<i class="ri-user-6-line ri-2x"></i>
|
2023-01-23 17:52:18 +00:00
|
|
|
</summary>
|
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
|
|
|
<ul role="menu" class="action-menu">
|
2023-01-22 21:30:15 +00:00
|
|
|
<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="{{ companyURI "/profile" }}"
|
|
|
|
data-hx-push-url="false" data-hx-swap="beforeend" data-hx-boost="true">
|
2023-07-02 17:49:03 +00:00
|
|
|
<i class="ri-user-6-line"></i>
|
Add the company relation and read-only form to edit
I do not have more time to update the update to the company today, but i
believe this is already a good amount of work for a commit.
The company is going to be used for row level security, as users will
only have access to the data from companies they are granted access, by
virtue of being in the company_user relation.
I did not know how add a row level security policy to the company_user
because i needed the to select on the same relation and this is not
allowed, because it would create an infinite loop.
Had to add the vat, pg_libphonenumber, and uri extensions in order to
validate VAT identification numbers, phone numbers, and URIs,
repectively. These libraries are not in Debian, but i created packages
for them all in https://dev.tandem.ws/tandem.
2023-01-24 20:46:07 +00:00
|
|
|
{{( pgettext "Account" "menu" )}}
|
|
|
|
</a>
|
|
|
|
</li>
|
|
|
|
<li role="presentation">
|
Split the tax details “mega dialog” into separate pages
I needed to place the payment accounts section somewhere, and the most
logical place seemed to be that dialog, where users can set up company
parameters.
However, that dialog was already saturated with related, but ultimately
independent forms, and adding the account section would make things
even worse, specially given that we need to be able to edit those
accounts in a separate page.
We agreed to separate that dialog into tabs, which means separate pages.
When i had everything in a separated page, then i did not know how to
actually share the code for the tabs, and decided that, for now, these
“tabs” would be items from the profile menu. Same function, different
presentation.
2024-08-14 02:08:13 +00:00
|
|
|
<a role="menuitem" href="{{ companyURI "/tax-details" }}">
|
Add the company relation and read-only form to edit
I do not have more time to update the update to the company today, but i
believe this is already a good amount of work for a commit.
The company is going to be used for row level security, as users will
only have access to the data from companies they are granted access, by
virtue of being in the company_user relation.
I did not know how add a row level security policy to the company_user
because i needed the to select on the same relation and this is not
allowed, because it would create an infinite loop.
Had to add the vat, pg_libphonenumber, and uri extensions in order to
validate VAT identification numbers, phone numbers, and URIs,
repectively. These libraries are not in Debian, but i created packages
for them all in https://dev.tandem.ws/tandem.
2023-01-24 20:46:07 +00:00
|
|
|
<i class="ri-vip-diamond-line"></i>
|
|
|
|
{{( pgettext "Tax Details" "menu" )}}
|
2023-01-23 17:52:18 +00:00
|
|
|
</a>
|
2023-01-22 21:30:15 +00:00
|
|
|
</li>
|
Split the tax details “mega dialog” into separate pages
I needed to place the payment accounts section somewhere, and the most
logical place seemed to be that dialog, where users can set up company
parameters.
However, that dialog was already saturated with related, but ultimately
independent forms, and adding the account section would make things
even worse, specially given that we need to be able to edit those
accounts in a separate page.
We agreed to separate that dialog into tabs, which means separate pages.
When i had everything in a separated page, then i did not know how to
actually share the code for the tabs, and decided that, for now, these
“tabs” would be items from the profile menu. Same function, different
presentation.
2024-08-14 02:08:13 +00:00
|
|
|
<li role="presentation">
|
|
|
|
<a role="menuitem" href="{{ companyURI "/invoicing"}}">
|
|
|
|
<i class="ri-file-paper-2-line"></i>
|
|
|
|
{{( pgettext "Invoicing and Quoting" "title" )}}
|
|
|
|
</a>
|
|
|
|
</li>
|
|
|
|
<li role="presentation">
|
|
|
|
<a role="menuitem" href="{{ companyURI "/taxes"}}">
|
|
|
|
<i class="ri-government-line"></i>
|
|
|
|
{{( pgettext "Taxes" "title" )}}
|
|
|
|
</a>
|
|
|
|
</li>
|
|
|
|
<li role="presentation">
|
|
|
|
<a role="menuitem" href="{{ companyURI "/payment-methods"}}">
|
|
|
|
<i class="ri-money-euro-circle-line"></i>
|
2024-09-06 10:13:27 +00:00
|
|
|
{{( pgettext "Invoicing Methods" "title" )}}
|
Split the tax details “mega dialog” into separate pages
I needed to place the payment accounts section somewhere, and the most
logical place seemed to be that dialog, where users can set up company
parameters.
However, that dialog was already saturated with related, but ultimately
independent forms, and adding the account section would make things
even worse, specially given that we need to be able to edit those
accounts in a separate page.
We agreed to separate that dialog into tabs, which means separate pages.
When i had everything in a separated page, then i did not know how to
actually share the code for the tabs, and decided that, for now, these
“tabs” would be items from the profile menu. Same function, different
presentation.
2024-08-14 02:08:13 +00:00
|
|
|
</a>
|
|
|
|
</li>
|
|
|
|
<li role="presentation">
|
|
|
|
<a role="menuitem" href="{{ companyURI "/payment-accounts"}}">
|
|
|
|
<i class="ri-bank-card-2-line"></i>
|
|
|
|
{{( pgettext "Payment Accounts" "title" )}}
|
|
|
|
</a>
|
|
|
|
</li>
|
2023-11-06 12:52:34 +00:00
|
|
|
<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="{{ companyURI "/switch-company" }}"
|
|
|
|
data-hx-push-url="false" data-hx-swap="beforeend" data-hx-boost="true">
|
2023-11-06 12:52:34 +00:00
|
|
|
<i class="ri-briefcase-line"></i>
|
|
|
|
{{( pgettext "Switch Company" "menu" )}}
|
|
|
|
</a>
|
|
|
|
</li>
|
2023-01-22 21:30:15 +00:00
|
|
|
<li role="presentation">
|
2023-01-23 17:52:18 +00:00
|
|
|
<form method="POST" action="/logout">
|
2023-02-02 10:39:34 +00:00
|
|
|
{{ csrfToken }}
|
2023-01-23 17:52:18 +00:00
|
|
|
<button type="submit" role="menuitem">
|
|
|
|
<i class="ri-logout-circle-line"></i>
|
|
|
|
{{( pgettext "Logout" "action" )}}
|
|
|
|
</button>
|
|
|
|
</form>
|
2023-01-22 21:30:15 +00:00
|
|
|
</li>
|
2023-01-17 21:28:47 +00:00
|
|
|
</ul>
|
2023-01-23 17:52:18 +00:00
|
|
|
</details>
|
2023-01-17 21:28:47 +00:00
|
|
|
</header>
|
|
|
|
<main>
|
2023-03-20 12:09:52 +00:00
|
|
|
{{- template "breadcrumbs" . }}
|
2023-01-22 20:41:50 +00:00
|
|
|
{{- template "content" . }}
|
2023-01-17 21:28:47 +00:00
|
|
|
</main>
|
2023-01-13 19:43:42 +00:00
|
|
|
</body>
|
2023-03-25 00:56:26 +00:00
|
|
|
<div x-data="snackbar">
|
|
|
|
<div x-show="show"
|
|
|
|
@click="dismiss"
|
|
|
|
x-cloak
|
|
|
|
x-transition:enter="enter"
|
|
|
|
x-transition:enter-start="start"
|
|
|
|
x-transition:enter-end="end"
|
|
|
|
x-transition:leave="leave"
|
|
|
|
x-transition:leave-start="start"
|
|
|
|
x-transition:leave-end="end"
|
|
|
|
role="alert">
|
|
|
|
<p x-text="toast"></p>
|
|
|
|
</div>
|
|
|
|
</div>
|
2023-01-13 19:43:42 +00:00
|
|
|
</html>
|