Add expiration helpers

[PolariTOON]

This extracts and reimplements many helpers from mespapiers that were initially implemented in cozy/mespapiers#329 and also add new ones.
The rationale behind this change is to be able to use these helpers in the viewer (cozy-ui and thus also mespapiers and cozy-drive) and also cozy-mespapiers-lib, instead of only be able to use them for mespapiers services.

[Crash--]

We should start coding differently, something more declarative instead of having those imperative if... We should only rely on a configuration file and the code will do the rest:

const config = [
'frenchNationalCard: {
'isExpiring': true, 
'expiringCondition': file => .... 
}
]

Like that there is no need to update the code if we want to add a new paper, change expiring condition or else. We just have to edit this config. If we think even further this config can be a json file served directly by the cozy. Like that even the PO will be able to edit by him/herself the content.

[PolariTOON]

The original approach was indeed to declare everything in a JSON (see paperDefinitions in the first commit, that is later removed), but we discussed extensively between devs and decided to move away from a declarative coding since the conditions to determine if a given paper expires and how to compute their expiration and notice dates are already very different.

For each relevant paper, the expiring condition is different because we use different attributes and not as many. Moreover the way we compute dates is also already different, with different fallback behavior and default delays. Making something purely declarative and thus generic would need many parameters and add noise in my opinion. As you first suggested it is easier to define dedicated methods for each paper anyway, so at this point i don't really see the benefit to define either a very complex JSON config that won't really be extensible in practice or methods instead of functions.

Note that we also discussed this with the PO and confirmed that were was no need for them to be able to edit themselves a config.

[JF-Cozy]

we discussed extensively between devs and decided to move away from a declarative coding

Attention à ne pas mélanger tous les sujets. A mon sens lors de nos échanges nous n'avons pas exclu spécifiquement le fait du faire du déclaratif de manière absolu. Là dessus, par défaut, perso je suis pas fermé.

Maintenant le fait que ce soit facile ou pas, et pertinent ou non (ce que tu évoques), et la modif via un PO (dont on a parlé aussi) sont d'autres points.

[Crash--]

we discussed extensively between devs and decided to move away from a declarative coding since the conditions to determine if a given paper expires and how to compute their expiration and notice dates are already very different.

I don't buy this argument. Each entry of the config has its own conditions and expiration methods. This is totally normal.
Since you discussed that extensively, do you have a written conclusion to share?

We have a few declarative instructions in Drive & Harvest for this kind of stuff and this is very powerful, useful and help us a lot with the maintenance and scalability.

Note that we also discussed this with the PO and confirmed that were was no need for them to be able to edit themselves a config.

As for today. Not in the future.

In my opinion this kind of development is much more better in a declarative form and the config is much more readable than having a lot of if / else condition. Also, creating this "magical function" is maybe a bit harder but not so much, and writing test for it it's pretty easy.

To go further, I really don't like the fact to publish a new Cozy Client version each time we add a qualification label and now every time we add an expiration to something. Having a declarative way of doing it will give us the opportunity to have a better solution for that.

I understand that this is not the path you chose, I'll not block this PR for that, but next time please add me in the thinking loop either by creating a SEC and putting other in the loop.

[Crash--]

Same here. Those code should be inside the config.

[JF-Cozy]

exemple de déclaratif :

import { national, passport } from 'identityLabels'
import { wedding } from 'familyLabels'

const papersExpirationConfig = {
  national_id_card: {
    expiration: {
      condition: file => national.condition(file),
      date: file => national.date(file)
    },
    notification: {
      sendingDate: () => {}
    },
    alert: {
      renewalLink: () => {}
    }
  },
  passport: {
    expiration: {
      condition: file => national.condition(file),
      date: file => passport.date(file)
    },
    notification: {
      sendingDate: () => {}
    },
    alert: {
      renewalLink: () => {}
    }
  }
}

export const cIsExpiring = file => {}
export const cExpirationDate = file => {
  if cIsExpiring(file)
  else
}
export const cSendingDate = file => {
  if cIsExpiring(file)
  else
}
export const cRenewalLink = file => {
  if cIsExpiring(file)
  else
}

[PolariTOON]

Some of the changes since the latest review:

• added date-fns to the direct dependencies and updated it
• moved the helpers to paper.js
• removed the link for the personal sporting license
• fixed how the country is retrieved
• removed the default notice period for the french national id card and the residence permit
• used optional chaining instead of lodash
• added missing types definition for attributes used in these helpers

I also opened an alternate PR with a final refactor at #1281 that could land instead of this one, or separately afterwards.
I think this is ready for another round of reviews. @Crash--, could you take another look ?

[Crash--]

String? Are-you sure?

[PolariTOON]

The expiration date is currently set by the user in an date field in Mes Papiers and stored as is in the metadata. So yes this is a string.

[Crash--]

So maybe we should update the doc? https://github.com/cozy/cozy-doctypes/blob/4c8913dfe8ccba9ab80fd5b656a389d828120127/docs/io.cozy.files_metadata.md?plain=1#L132

[PolariTOON]

I was not aware of this document. I have no strong opinion. I mean, this is a date, indeed, but formatted as a string. So for the purpose of type checking in JSDOC this is a string (unless we want to narrow it with template literal types), but conceptually this is a date, so that's not wrong to describe it like this in the documentation you pointed to.

[Crash--]

Same here?

[PolariTOON]

The reference date is also provided by the user as a string.

[Crash--]

Can you squash few commits please? I think it's not useful here to have the refactor between lodash.get and ? for instance.

I think having 3 commits can be great:

• one to add date-fns as dep
• one to add all the expiration stuff
• one to add the missing jsdoc

[PolariTOON]

I added a description for each helper to clarify what they do, and imported IOCozyFile and Qualification as JSDOC types instead of these "ghost" variables. I squashed the whole thing into 3 commits to eliminate the intermediate refactors as @Crash-- suggested. Can you take one (final?) look?

[Crash--]

nit: Vu qu'on l'ajoute en dep, aucune raison de la garder en devDep

[Crash--]

<3