Project eSIM SomConnexió
Manage the eSIM and SIM change workflows on top of the Project app:
deliver the eSIM activation code to the customer,
handle SIM/eSIM change requests, from the customer signature (with sign_oca) to the MM Proxy call that applies the change,
keep the mobile contract up to date with the new SIM.
Table of contents
Configuration
The module ships, as non-updatable data, three projects:
eSIM Provisioning (project_esim_provisioning): delivery of the eSIM activation code of new mobile lines.
SIM to eSIM (project_esim_change): changes from a physical SIM to an eSIM.
Canvi SIM (project_sim_change): changes of physical SIM card.
Every task stores its data in task properties. All projects have an icc property, filled externally, with the ICC of the new SIM. The SIM change projects also have sim_type and reason, and the eSIM projects activation_code, pin and puk.
Stages:
Stage |
Provisioning |
SIM to eSIM |
Canvi SIM |
|---|---|---|---|
Waiting for activation code |
✓ |
||
SIM request from API with document ID to validate |
✓ |
✓ |
|
SIM request document sent to sign |
✓ |
✓ |
|
Request document signed |
✓ |
✓ |
|
Email with activation code sent |
✓ |
✓ |
|
SIM to deliver |
✓ |
||
SIM delivered |
✓ |
Email templates (project.task, translated to Catalan and Spanish following the partner language):
eSIM Activation Code (project_esim_somconnexio.mail_template_esim_activation_code): activation code, QR, PIN and PUK of the eSIM. Sent by the Email with activation code sent stage.
SIM Change Sign Request (project_esim_somconnexio.mail_template_sim_change_sign): link for the customer to sign the SIM change request.
Usage
eSIM provisioning
Create a project.task on the eSIM Provisioning project for each eSIM activation request, setting partner_phone to the phone number being activated.
When a mobile contract is created with sim_type set to eSIM (see contract_api_somconnexio), the system looks for a pending task (stage Waiting for activation code) whose partner_phone matches the contract’s phone number and, if found and not already linked, sets the task’s contract_id to the new contract.
Moving the task to the Email with activation code sent stage sends the customer the eSIM Activation Code email.
SIM/eSIM change requests
Requesting the change
The Request SIM Change button on a mobile contract opens the contract.sim.change.wizard. It creates a task on the SIM to eSIM or the Canvi SIM project, depending on the new SIM type, and attaches the customer’s identity document to it. For a physical SIM, the wizard New ICC field is stored in the task icc property. The identity document is only kept on the task; it is not sent to MM Proxy.
Signing the request
When the task reaches SIM request document sent to sign, a sign.oca.request is created and linked to the task through its record_ref. Its document is the SIM change request QWeb report (project_esim_somconnexio.action_report_sim_change_sign_request), prefilled with the customer, the mobile line and the new SIM data.
sign.oca.request.action_send is overridden for these requests: the customer receives the SIM Change Sign Request email, posted from the task so it is kept in the task chatter, instead of the generic sign_oca email. Requests not linked to a SIM change task keep the sign_oca email.
Applying the change
Once the customer signs it, the task moves to Request document signed and a job calls MM Proxy to apply the change, sending the signed request’s data (the signed PDF) as the signed_form.
Updating the contract
When a SIM change task is done (Email with activation code sent for SIM to eSIM, SIM delivered for Canvi SIM), the task icc property is stored in the contract (the task cannot reach these stages without it). For SIM to eSIM tasks, the contract sim_type is also set to eSIM.
Contributors
Som Connexió SCCL <https://somconnexio.coop/>
Gerard Funonsas gerard.funosas@somconnexio.coop
Borja Gimeno borja.gimeno@somconnexio.coop
Coopdevs Treball SCCL <https://coopdevs.coop/>
Daniel Palomar daniel.palomar@coopdevs.org
1 maintainer
Metadata
1 maintainer
Release files for odoo-addon-project-esim-somconnexio 16.0.1.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| odoo_addon_project_esim_somconnexio-16.0.1.0.0.tar.gz | 33.6 kB | Without provenance | Details for odoo_addon_project_esim_somconnexio-16.0.1.0.0.tar.gz |
Release files / odoo_addon_project_esim_somconnexio-16.0.1.0.0.tar.gz
| Download URL | odoo_addon_project_esim_somconnexio-16.0.1.0.0.tar.gz |
|---|---|
| Size | 33.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f468433c7a0a7d40b68114b5047a629ed9eb4b148556af1bfdf112f179936539
|
|
BLAKE2b-256 checksum How to use checksums |
b20977c020941a481a5d8965de8240cf5d1a398289689609595a5da38149a11f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.10.12
|
Security for odoo-addon-project-esim-somconnexio 16.0.1.0.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
