• To have a dedicated URL is not as useful as it seems
• A popover could be a better UX here and behave similarly to other flows

Implement a disabled button whenever sumbit is already ongoing

When you use a single account, there could be ways to skip the auth panel and do a silent login there?

Probably linked to the fact that there's no encompassing polygon to build, so no bounding box, so no zoom.

• Observateurs associés
• Météos

• Map could be longer - as long as the form?
• Submit button to take the full width?

By looking at some Grafana logs, it looks that jobs can get removed.
A previous fix on infra side showed that redis was set without persistence and could lose jobs. This has been fixed.
However now, I suspect this could be a combination of RollingUpdate + the way we destroy jobs when shutting down. If the first pod is terminated after, I guess that it cleans the job just created.
Need to look at the docs to check if we can be less brutal on destruction while making sure that jobs can get updated or deleted properly if needed.
If not possible, maybe we'll have to switch to rolling updates just for that.

De la même couleur que les valeurs des autres champs

Est-ce que la distance peut vraiment être 0 ?

This is due to missing error handling w/ the new kysely queries.
We need to add a proper mechanism for that.

Basically the error thrown is a DatabaseError that is straight from pg here: https://github.com/brianc/node-postgres/blob/9c3ecdca6953b8cde01fcb6ab6042e8274dc2e9b/packages/pg-protocol/src/messages.ts#L97

So we need to wrap these raw errors to own errors that are:

• driver agnostics possibly
• similar to the ones from slonik?
• Check if they should be part of the domain. Probably not as we may wish to hide this undelying logic and retuen a proper outcome pattern.

Open questions:

• Should we need to define our own errors, or are we interested to know whick kind of errors happened? e.g. in the case here, we might want to handle the outcome, but reject otherwise. No need to bubble up the specific error
• How to make sure that error handling is not forgotten most of the time? Because at first it looks like we we need to catch executions everywhere. Check if there's something smarter to be done w/ kysely

More on GlitchTip-79

Il faudrait :

• soit afficher une erreur plus parlante côté UI
• soit ne pas le permettre au niveau UI
• soit filtrer les doublons avant insert en DB
• soit l'autoriser au niveau de la DB

{statusCode: 500, error: "Internal Server Error",…}
error
:
"Internal Server Error"
message
:
"Query violates a unique integrity constraint. duplicate key value violates unique constraint "idx_16490_primary""
statusCode
:
500

Find a way to show which input has the focus.

• Champ durée différent du champ heure ?
• Autoriser à ne pas mettre les deux points sur la durée à la saisie ou mettre un champ heure ?
• Peut-être que plutôt que durée on pourrait avoir un champ heure de fin

E.g. quand il y a des données (foreign key)

The requests that contain a body are currently sent with text/plain MIME type.

This is why we parse all inputs before zod.

We should:

• Check and fix the frontend
• Make sure that only application/json is accepted on API routes.
• Remove the unnecessary parsing.

• A la base j’ai une température sur l’inventaire, je vais sur modifier l’inventaire, j’enlève la température, j’ai une erreur

• même problème pour l’heure, la durée, la modification des coordonnées (de custom vers non custom)

Behavior should be similar to the current inventory panel.

Looks related to the introduction of "after" layer that seems to trigger issues whenever the related layer is not present yet

Seems like an obvious feature but UI/UX to be discussed.

For example, since the migration to infinite query, there are cases where whenever one deletes an entity, the UI is not refreshed.
That's not always like this and I haven't found no pattern.

When opening a popover, the difference between popover and background content is not that obvious.

If we could do somthing like blurring the background or similar, it would help.

I already has a look earlier and did not seem obvious between daisyui and headlessui

• Modifier une estimation du nombre -> inverser la valeur de indénombrable

• Sauvegarder

• Cliquer sur modifier -> la valeur d'indénombrable affichée est toujours l'ancienne valeur

• Modifier le nom d'un estimation du nombre (ou autre entité)

• Sauvegarder

• Cliquer sur modifier -> l'ancienne valeur apparait dans le formulaire et on ne peut pas sauvegarder le formulaire. Par contre si on remet la valeur actuelle on peut sauvegarder.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update node.js to v20

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Found while working on #1218

We should remove coercion to number or check that the number is valid.
In DB this is currently a number.
Keep in mind that we should move that to a string someday.

In the old app, it was possible to create a new inventory from an existing one.

This was done at entry level.
Whenever the inventory was updated and save, the user could either update the inventory, or create a new inventory only for this entry.
This was not necessarily easy to understand

Here the UI is different, so this is an opportunity the rework the flow to be easier to understand.

• One can create empty inventories now
• Entries of a given inventory can be displayed
• Creating a new inventory from an existing one as template is already possible.

So the way this could be implemented would be to allow selection on UI side of entries, and provide an action to assign them to another existing inventory.
The minor drawback for now is that the new inventory would need to be created beforehand.

API part has to be implemented too.
A good solution would be to design a "bulk" update API on /entries that does not currently exists.

Pour tous les types d'entité du référentiel

Problème 1

• Créer une commune avec le nom "a"
• Trier les communes par nom par ordre alphabétique du nom
  -> la commune a n'apparait pas.

Par contre si on scroll jusqu'en bas de la table elle apparait.

Même problème quand on modifie la commune.

Problème 2

• Modifier une commune
• Scroller tout en bas de la table jusqu'à la commune
• Cliquer sur modifier
• Les anciennes valeurs apparaissent dans le formulaire

Problème 3

• Créer une classe espèce "test"
• Filtrer les classes espèces par "test"
  -> la classe créée n'apparait pas

Looks related to a recent change, but when loading the app after login, looks like there's a full page reload

When retrieving observations from search, it may be useful to display the total count of matching values somewhere in the UI.

To be done for observations, as it makes less sense for species.

To investigate:

• Go to settings
• Change some settings so that a snackbar is displayed
• Before the snackbar is dismissed, come back to creation page

Looks like the page gets "reloaded" whenever the snackbar gets dismissed

Mieux gérer l'erreur pour qu'elle soit claire pour l'utilisateur

This is basically implementing the feature present in the legacy version.

When using search filters (e.g. by observer), the species tab can be sorted by observations count.

However, the number of observations displayed is the total number from any observer - which is not consistent with the sort that is filtered.

My guess is that the filter is ignored when querying the count.
We should either fix that, or deal with it to avoid confusion (remove the sort, hide the count?)