CRM LEAD DMS CATEGORY
This module lets a crm.lead be marked with the dms.category records it requires documentation for, and tracks whether that documentation has actually been uploaded.
Required categories
The dms_category_ids many2many field on crm.lead holds the dms.category records required for that lead. It is shown on the lead form, next to the tags.
The dms_category_ids field is editable on the lead form, inside the “documentation” tab. Also within the tab, the categories are shown as tags, and the field has_all_required_documentation is shown as a toggle button.
Required documentation tracking
The has_all_required_documentation computed field (store=True) on crm.lead is True when every category in dms_category_ids has a matching dms.file uploaded on the lead itself.
Because dms.file only references its record through a generic res_model/res_id pair (like ir.attachment), the field cannot be expressed with a plain @api.depends. It is instead kept up to date through a listener on dms.file creation, and through an unlink override - both scoped to files whose res_model is crm.lead.
Extension points
This module only looks at documents uploaded directly on the lead. Other modules can extend where documents are looked up, or react once the required documentation is complete, by overriding:
_get_uploaded_document_categories: which categories already have an uploaded document. crm_lead_personal_file_data overrides it to also count documents uploaded on the lead’s partner.
_update_documentation_from_upload: computes the already uploaded categories to check if the lead has all required documentation. It can be overridden to react to the documentation being complete
Table of contents
Configuration
No specific configuration is required.
Usage
Assign the required categories to a lead through the dms_category_ids field on its form view. From then on, has_all_required_documentation is kept up to date automatically as documents are uploaded to or removed from the lead.
Known issues / Roadmap
Documentation is not created directly on the partner for now, so uploads or deletions scoped to res.partner do not refresh the flag by themselves; see crm_lead_personal_file_data for the partner extension.
Bug Tracker
Bugs are tracked on GitLab Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smashing it by providing a detailed and welcomed feedback.
Do not contact contributors directly about support or help with technical issues.
Credits
Contributors
-
Álvaro García <alvaro.garcia@somit.coop>
José Robles <jose.robles@somit.coop>
Juan Manuel Regalado <juanmanuel.regalado@somit.coop>
-
Gerard Funosas <gerard.funosas@somconnexio.coop>
Maintainers
This module is maintained by the OCA.
OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.
You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.
Metadata
Release files for odoo-addon-crm-lead-dms-category 16.0.1.2.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 | |
|---|---|---|---|---|
| odoo_addon_crm_lead_dms_category-16.0.1.2.0.tar.gz | 21.7 kB | Without provenance | Details |
Release files / odoo_addon_crm_lead_dms_category-16.0.1.2.0.tar.gz
| Download URL | odoo_addon_crm_lead_dms_category-16.0.1.2.0.tar.gz |
|---|---|
| Size | 21.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
772d3f0b3a5877c871d9d5233fb6e1259dfc1956c6e1b3f2931ba3db86bebf39
|
|
BLAKE2b-256 checksum How to use checksums |
e1a93347c85f763b94c4a60f1cb317dd10254389249b99091c907acaa0088ea6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.10.12
|
Security for odoo-addon-crm-lead-dms-category 16.0.1.2.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.