In odoo/documentation-user#945, the developer documentation is merged with the user documentation in a single repository and build config. This commit then removes source files for the developer documentation from the odoo/odoo repository. DOC PR: https://github.com/odoo/documentation-user/pull/945 task-2351938 task-2352371 task-2205684 task-2352544 Co-authored-by: Victor Feyens <vfe@odoo.com> Co-authored-by: Antoine Vandevenne <anv@odoo.com>
This commit updates the documentation surrounding compute and inverse methods for fields, explicitly warning API consumers that grouping multiple compute fields under a single inverse method is error-prone and could not work at all (it can still work under specific conditions but henceforth it shall be considered bad practice). This case was found at https://github.com/odoo/enterprise/pull/13815/commits/a651413df915f166697d26a83084582207405858 closes odoo/odoo#60103 X-original-commit: 1d21924c1da0bed59cd105a3d9bf9b60fa2d7bc4 Signed-off-by: Raphael Collet (rco) <rco@openerp.com> Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
The behavior isn't exactly undefined: it will appear to work if the relation refers to only 1 instance. If there are multiple it will give results for 1 instance and ignore the others. This behavior should not be relied upon, hence I'm documenting it as undefined. I confirmed this with mat from the ORM team. Even better would be to raise an error or warning if `related` is used in this context. closes odoo/odoo#57270 closes odoo/odoo#57797 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com> Signed-off-by: Raf Geens <raf-odoo@users.noreply.github.com> Co-authored-by: Raf Geens <raf@odoo.com>
* fix link from backend tutorial to log_access section * flesh out log access documentation * add documentation for log_access itself & improve doc for a few other model-level attributes
The delegation inheritance is very useful in some cases, but its usage shouldn't be encouraged. Furthermore, chained _inherits may result in unexpected behavior/results, and really shouldn't be used. closes odoo/odoo#54864 X-original-commit: 4a06a4c79e962906832f98147fe87a2c19efaa75 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The ir.autovacuum model purpose is to run several garbage collecting operations like removing files from the filestore when no attachment references them anymore. The precedent strategy to register new garbage collection tasks was to override the `power_on` method and to imperatively execute a vacuum cleaning method on a given model. All calls were executed in a single SQL transaction without any error handling, meaning a single fail during any call resulted in a complete failure of the entire vacuum cleaning chain. We introduce a new `@autovacuum` api decorator, its purpose it to register garbage collecting methods that will be safely executed in their own transaction by the vacuum cleaner. In order to ensure this new strategy is used, we deprecate `power_on` extensions. By the way, garbage-collecting methods can be quite heavy and we don't want users to directly call them. We now ensure they are private. closes odoo/odoo#47842 Task: 2154079 Signed-off-by: Raphael Collet (rco) <rco@openerp.com> Co-authored-by: Raphael Collet <rco@odoo.com> Co-authored-by: Olivier Dony <odo@odoo.com>
closes odoo/odoo#49135 X-original-commit: cc653d3f1a49e2b7b2cc0ec833097bd7cf3528a1 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
X-original-commit: efa3a148cb178693b73af054cd6e19870d068454
* Some fields types were missing * Add information on multi-record field access * UI finetuning
closes odoo/odoo#41038 X-original-commit: eaabad20516a73a97b23343a22357659c29945f7 Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com> Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>