Skip to content

Resolve "[Rdv en ligne] Check plus précis du CNFS id ainsi que des plages de rdv ouvertes"

What does this MR do and why?

Before binding an idCNFS to a structure, checks if the cnfs has meeting opened on rdvs.

Screenshots or screen recordings

How to set up and validate locally (or on alpha)

Reviewer should test several scenarios :

  • When a structure is created, it triggers the service and tries to bind a cnfs id.
  • When the cron is launched (weekly), it tries to bind a cnfs id.

You will need:

  • a cnfs with contact infos that leads to a cnfsId not exposed by rdvs -> 04 78 59 12 65, 60cc7cc5838083d339cc31b6
  • a cnfs with contact infos that leads to a cnfsId that is exposed by rdvs and ready to take meetings ->, 60461fc6871498b5cec20581

use those mail in cron execution, not structure creation (prefer phone just in case to not flood people).

Make sure that :

  1. Structure without idCNFS in database, with a correct contact info and no meeting opened.
  2. Structure without idCNFS in database, with a correct contact info and meeting opened.
  3. Structure with wrong contact infos


MR acceptance checklist

To be completed by the chosen reviewer.

Quality Bugs - Code Smells

  • For the code that this change impacts, I believe that the automated tests validate functionality that is highly important to users. If the existing automated tests do not cover this functionality, I have added the necessary additional tests or I have added an issue to describe the automation testing gap and linked it to this MR.
  • I have made sure that the sonar quality coverage is up to standards.
  • I have considered the impact of this change on the front-end, back-end, and database portions of the system where appropriate and applied.
  • I have tested this MR in all supported browsers or determined that this testing is not needed.
  • I have confirmed that this change is backwards compatible across updates (migrate up needs a migrate down), or I have decided that this does not apply.

Performance, reliability and availability

  • I am confident that this MR does not harm performance, or I have asked a reviewer to help assess the performance impact.
  • I have considered the scalability risk based on future predicted growth.


  • The MR is named after the desired squash commit to feed the changelog linked to the current milestone.
  • I have added/updated documentation (also updated if the changes feature a deprecation) or I have decided that documentation changes are not needed for this MR.

Security Security Rating

  • I have confirmed that if this MR does not contains any sensitive informations hidden in the changes.


  • When featured on a self-data project release, I have made sure my app version in the manifest and package.json is incremented and any relative changes to the permissions are clearly written and transmitted to Cozy.

Related to #23 (closed)

Edited by Hugo NOUTS

Merge request reports