* [ADD] Updated manifest and README
* [ADD] Version 10.0 template and api_version model
* [ADD] Updated license header, updated api call
* [FIX] Flake
* [FIX] Flake
* [FIX] Tests
* [FIX] Flake8
* [ADD] Extra test for changed method 'set_jinja_env'
* [FIX] Fixed 'Try me on runbot' button
[FIX] PEP8 errors
[FIX] Get default description
[IMP] README.rst
[IMP] Provide Jinja2 requirement
[IMP] Add license badge in description
[FIX] Formatting
[FIX] Version and typos
[FIX] Use human name and english category name for manifest
[IMP] multi line notes, unprefix names, pep8 py files
[IMP] whitespace cleanup in templates
[FIX] base models get _name, custom get _inherit
add missing spaces
[IMP] prototype: no more bug when no icon, commented no implemented page in the view.
[IMP] prototype: better management of special cases.
[IMP] prototype: prototype.py removed print statement and shadowing of "fields".
[IMP] prototype -> module_prototyper
[IMP] module_prototyper: gathered menuitems that is helpfull to create a prototype under the menu 'Module Prototypes'
[IMP] module_prototyper: more comment and docstrings.
[IMP] module_prototyper: translations.
[FIX] module_prototyper: pep8
[IMP] update module_prototyper:
* pump up the version of the module to 0.3
* replace ir.ui.model by ir.ui.view in generated xml views
* improve pep8 compatibility of generation of models
[IMP] update module_prototyper: update of README with versions.
[IMP] Add OCA as an author
[IMP] Add Bug Tracker section in description
[IMP] Update description template
[ADD] Initial version of prototype
[IMP] Add wizard for API version and templates. Update translation file
[ADD] Security template files
[ADD] Filters for data and demo data
[FIX] other licenses, return lines as well
[FIX] license not shown in __oe__
[FIX] unprefix more names, try to get _name/_inherit right [IMP] group by module in zip
[FIX] fix category and summary being on same line
[FIX] fix export test
[IMP] add tabs for reports/security/workflow/data + partial data/demo generation
unprefix model names in __init__
[FIX] fix data file names in __openerp__.py
[IMP] move Data&Demo after Interface in view
[FIX] unprefix view file names
[IMP] remove prefixes from field attrs in views
[FIX] encode files in zip to utf-8, remove trailing comma in menu groups
remove unused variable in tests
remove AGPL3 or later from license choices: not in base module choices
10 years ago
Maxime Chambreuil - http://www.savoirfairelinux.com
[FIX] Use human name and english category name for manifest
[IMP] multi line notes, unprefix names, pep8 py files
[IMP] whitespace cleanup in templates
[FIX] base models get _name, custom get _inherit
flake fix
add missing spaces
prevent crash on menus with no action
switch GPL-2 to LGPL-3
generate license headers with license name
fix pep/flake errors in generated files
add m2m and relation field options in fields
[IMP] prototype: no more bug when no icon, commented no implemented page in the view.
[IMP] prototype: better management of special cases.
[IMP] prototype: prototype.py removed print statement and shadowing of "fields".
[IMP] prototype -> module_prototyper
[IMP] module_prototyper: gathered menuitems that is helpfull to create a prototype under the menu 'Module Prototypes'
[IMP] module_prototyper: more comment and docstrings.
[IMP] module_prototyper: translations.
[FIX] module_prototyper: pep8
[FIX] module_prototyper: fix typo in tests.
[IMP] update module_prototyper:
* pump up the version of the module to 0.3
* replace ir.ui.model by ir.ui.view in generated xml views
* improve pep8 compatibility of generation of models
[IMP] update module_prototyper: update of README with versions.
* Add new module "mail_cleanup" in order to move/mark as read old messages
* Use correct Model + remove unnecessary conditions/assignments
* Add purging mechanism + cleanup is by default inactive
* Add new field + new info in README
* Correct type for purge_days + better checks
* Place expunge() call after parsing all messages
* Migration to 9.0 of mail_cleanup
* Fix README.rst
* Add __init__.py
* Fix error with multi mail servers
* Correct syntax for methods + use datetime.date.today
In normal tree view duplicate and archive can be done throught the
action menu. So we only need to show this button when this tree view
are included in a form using a o2m or m2m.
So this visibility can be activated by passing value in the context
Also make the copy consitent whatever way you do it
Because of the naming given to the external ID's, Odoo
interprets all this data as regular module data and when
you update the module and those external ID's are not present
in the module files, it tries to delete them.
- correct `directory_output` value
- mute logger for desired raise exception
- change how the "already imported files" are checked when
"check_duplicated_files = True" :
It occurs that a task o2m field `attachment_ids` returns an empty record
when checked during the `_file_to_import()` method... but only when
the module `autovacuum_message_attachment` is installed !
[WIP] use jinja to render new file name based on simple template
[FIX] bug move and rename file option
[ADD] add file type on task
[FIX] add file type in attachemnt create method
[WIP] test rename file
[WIP] inherit view from attachment_metadata
[FIX] bug of inherit view and menu from attachment_metadata
[IMP] add move & rename test to test_sftp
[IMP] move file location menu inside automation menu and rename it
[IMP] add ir.model.access manager rule
[FIX] typing mistake
[FIX] access file store without login/password
[IMP] reorganize task form view
[FIX] api.multi in task run method
[FIX] OCA guidelines
[FIX] add authors and contributors
[FIX] fix pylint
[FIX] add oca_dependencies & fixe oca version format
[FIX] fix pylint & oca_dependencies
[FIX] fix views path
[FIX] set application to False
When changing the custom info template, some recomputation triggers are launched
that can involve records that the user changing the template has not access to
(for example, a record of other company).
Putting this, we avoid the problem.
That model is intended only to set config and has no fields, so there is
no need for creating a DB table for it. This is achieved by switching
the model type from transient to abstract.
* [FIX] company_country: Don't fail if account is already installed
When `company_country` is installed, it performs the following:
- Look for the `COUNTRY` environment variable
- If not found, look for a `l10n_*` module that is about to be installed
- If not found, raise an exception
However, If the account module is installed, it shouldn't fail even if
the environment variable is not defined, because changing the
company's country will have no effect anyway, as the account hook was
already run and an `l10n` module was already been installed.
This commit fixes the above by skipping the process if the `account`
module is installed, and print an informative message to the log.
* Update __manifest__.py
Co-authored-by: Moises Lopez - https://www.vauxoo.com/ <moylop260@vauxoo.com>
- Put force_save=1 for allowing the web client to send readonly values to server
- Switch widget="selection" to "many2one" default with options because it's not
supported anymore in tree view
- Move value_id to parent view.
Set the implementation to "Standard" in all your current Sequences
(ir.sequence) and all new sequences are created as "Standard" by default
instead of "No Gap" implementation.
**What's the problem Sequences with "No Gap" Implementation?**
"No Gap" is the default value of sequences in Odoo. However, this kind of
sequences cause more locks and can turn a database slow.
Taking as example an invoice, if you assign an invoice number to one record,
but it sill not finish the process, this process must end in order to another
invoice could assign a new number and there was no gaps between the invoice
numbers. It seems to be good at first sight. But the problem start when there
is and chained process.
Imagine that there is one user that executes a process that produces 100
invoices and these at the same time produces 100 journal entries that also use
a consecutive (no gap) sequence. And also those invoices are sent to sign with
and external institution (that could take 2 seconds in giving a response
because of internet latency or server load), and maybe they made another
calculations that makes them to take 5 seconds more for each invoice, and all
this is chained to one single transaction. This means that for 8.5 minutes
anybody else could confirm invoices, neither journal entries of the involved
journals.
Now, think there is 20 users that have to execute a similar process. The
problem turns exponential. If another user comes to make an operation with the
same jornal it will thrown a concurrency failure.
You can mitigate it if you segment each transaction and don't chain them. It
means, making commit for each invoice or process. It reduces the
probability that there is a concurrency error or a lock wait. However, it still
not solve it completely.
**Why to use Sequences with "Standard" Implementation?**
If you use the standard sequence of PosgreSQL, it doesn't lock because at the
moment the request is done, the next sequence number it is changed in an
isolated transaction, and it have not to wait the other transaction to end.
However, if the transaction produces a rollback, this sequence isn't reverted,
it means, it's lost. It may be not not serious because when you cancel or
remove records that number is lost too.
**What this module does?**
To eliminate completely that concurrency/slowness problem, this module changes
all the sequences (ir.sequence) implementation from "No Gap" to "Standard" with
the awareness that it will skip numbers. In the majority of database models
and many users projects there is no problem with that jump occurs.
Also, all newly created sequences will be by default in "Standard"
implementation.
We must avoid to rely on the order in which computed fields (including related fields) and constrains methods are applied.
Due to a recent change into the ORM, the contrains on the model_id into CustomInfoTemplate is now called AFTER the recompute of the related model field into property_ids.info_value_ids
As side effect, when the constrains is called, the model on the info value is already updated with the new value and we no more know the old value....
* Now you can define properties types, and access rules are inherited from the model/record
linked to the custom info record.
* Simplified version of computed value.
* Implement for res.partner.
* Add tests and fix bugs discovered in the meantime.
* Allow to disable partner custom info tab, and custom info menu.
* All of it can be set within general settings.
* Now, by default, this module does not display custom info for partners unless in demo mode.
Better fit for a base module.
* You can disable the top menu entry too if it disturbs you, or enable it for everybody.
* Give a special form when editing in partner custom info tab.
* Sortable properties.
* Sort values at onchange time.
* Improve performance in onchange.
* Split in several model files.
Previously export is slow on large number of rows.
This fix ensure that sheet.insert_rows is called only once for all rows,
instead of insert 1 row for every rows
* [PORT] [9.0] configuration_helper
Port to API 8.0 and make it compatible with a config definition in API
8.0. Remove some hacks with onchange and write to get and set the
related values.
* Add a module to define classes in order to test configuration_helper
Fixing #1134.
Odoo stores values of computed fields at the end of the transaction
only, as such performing a 'read()' to make a data snapshot on the record
created in the current transaction doesn't return the expected result
regarding these fields.
Also as a side-effect 'read()' alters the environment cache and break the
values on the record inducing issues in the whole user
transaction/workflow.
This fix replaces the use of 'read()' to do the data snapshot directly
from the cache of the record (computed values are already there).
Trivial changes:
* Version in README changed
* Version in manifest changed
OCA Transbot updated translations from Transifex
OCA Transbot updated translations from Transifex
This module adds async processing capabilities to attachments by implementing a new model attachment.queue that wraps attachments and stores additional information so that it can be processed in an asynchronous way.
A use case of this module can be found in the attachment_synchronize module.
**Table of contents**
..contents::
:local:
Usage
=====
Go the menu Settings > Technical > Database Structure > Attachments Queue
You can create / see standard attachments with additional fields
Configure the batch limit for attachments that can be sync by the cron task at a go:
Settings > Technical > System parameters > attachment_queue_cron_batch_limit
image:: ../static/description/tree.png
This module can be used in combination with attachment_synchronize to control file processing workflow
image:: ../static/description/form.png
Bug Tracker
===========
Bugs are tracked on `GitHub Issues <https://github.com/OCA/server-tools/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
This module adds async processing capabilities to attachments by implementing a new model attachment.queue that wraps attachments and stores additional information so that it can be processed in an asynchronous way.
A use case of this module can be found in the attachment_synchronize module.
<p><aclass="reference external"href="https://odoo-community.org/page/development-status"><imgalt="Beta"src="https://img.shields.io/badge/maturity-Beta-yellow.png"/></a><aclass="reference external"href="http://www.gnu.org/licenses/agpl-3.0-standalone.html"><imgalt="License: AGPL-3"src="https://img.shields.io/badge/licence-AGPL--3-blue.png"/></a><aclass="reference external"href="https://github.com/OCA/server-tools/tree/12.0/attachment_queue"><imgalt="OCA/server-tools"src="https://img.shields.io/badge/github-OCA%2Fserver--tools-lightgray.png?logo=github"/></a><aclass="reference external"href="https://translation.odoo-community.org/projects/server-tools-12-0/server-tools-12-0-attachment_queue"><imgalt="Translate me on Weblate"src="https://img.shields.io/badge/weblate-Translate%20me-F47D42.png"/></a><aclass="reference external"href="https://runbot.odoo-community.org/runbot/149/12.0"><imgalt="Try me on Runbot"src="https://img.shields.io/badge/runbot-Try%20me-875A7B.png"/></a></p>
<p>This module adds async processing capabilities to attachments by implementing a new model attachment.queue that wraps attachments and stores additional information so that it can be processed in an asynchronous way.</p>
<p>A use case of this module can be found in the attachment_synchronize module.</p>
<aclass="reference external image-reference"href="https://odoo-community.org"><imgalt="Odoo Community Association"src="https://odoo-community.org/logo.png"/></a>
<p>OCA, or the Odoo Community Association, is a nonprofit organization whose
mission is to support the collaborative development of Odoo features and
<p>This module is part of the <aclass="reference external"href="https://github.com/OCA/server-tools/tree/12.0/attachment_queue">OCA/server-tools</a> project on GitHub.</p>
<p>You are welcome to contribute. To learn how please visit <aclass="reference external"href="https://odoo-community.org/page/Contribute">https://odoo-community.org/page/Contribute</a>.</p>
This module allows to **import/export files** from/to backend servers.
A backend server is defined by the basic `storage_backend <https://github.com/OCA/storage/tree/12.0/storage_backend>`_ OCA module, while it can be configured (amazon S3, sftp,...) with additional modules from the `storage <https://github.com/oca/storage>`_ repository.
The imported files (and the files to be exported) are stored in Odoo as ``attachment.queue`` objects, defined by the `attachment_queue <https://github.com/OCA/server-tools/tree/12.0/attachment_queue>`_ module while the importation itself (resp. exportation) is realized by **"Attachments Import Tasks"** (resp. "Attachments Export Tasks") defined by this current module.
**Table of contents**
..contents::
:local:
Usage
=====
As importation and exportation are different processes, they are triggered in different ways :
**To import files**, you need to create an *"Attachment Import Task"* (menu *Settings > Technical > Attachments Import Tasks*) which defines :
- where to find the files to import from the backend server (path to the files, selection pattern)
- what to do with the source files in the backend server (avoid duplicates, delete/rename after import...)
- how the files will be processed once imported (through the **File Type** field).
🔎 The **File Type** options are defined by other modules built to process the Attachments Queues with the same "File Type".
**To export files**, you need first to register them as *"Attachments Queues"* objects linked to an *"Attachment Export Task"* (which set automatically their **File Type** to *"Export File (External Location)"*).
Then, you can export one file at a time from the *Attachment Queue*'s form view, or export all the *Attachments Queues* in a pending state related to the same *Export Task* from the given *Export Task* form view (menu *Settings > Technical > Attachments Export Tasks*) :
This module allows to **import/export files** from/to backend servers.
A backend server is defined by the basic `storage_backend <https://github.com/OCA/storage/tree/12.0/storage_backend>`_ OCA module, while it can be configured (amazon S3, sftp,...) with additional modules from the `storage <https://github.com/oca/storage>`_ repository.
The imported files (and the files to be exported) are stored in Odoo as ``attachment.queue`` objects, defined by the `attachment_queue <https://github.com/OCA/server-tools/tree/12.0/attachment_queue>`_ module while the importation itself (resp. exportation) is realized by **"Attachments Import Tasks"** (resp. "Attachments Export Tasks") defined by this current module.
As importation and exportation are different processes, they are triggered in different ways :
**To import files**, you need to create an *"Attachment Import Task"* (menu *Settings > Technical > Attachments Import Tasks*) which defines :
- where to find the files to import from the backend server (path to the files, selection pattern)
- what to do with the source files in the backend server (avoid duplicates, delete/rename after import...)
- how the files will be processed once imported (through the **File Type** field).
..image:: ../static/description/import_task.png
..epigraph::
🔎 The **File Type** options are defined by other modules built to process the Attachments Queues with the same "File Type".
**To export files**, you need first to register them as *"Attachments Queues"* objects linked to an *"Attachment Export Task"* (which set automatically their **File Type** to *"Export File (External Location)"*).
Then, you can export one file at a time from the *Attachment Queue*'s form view, or export all the *Attachments Queues* in a pending state related to the same *Export Task* from the given *Export Task* form view (menu *Settings > Technical > Attachments Export Tasks*) :
<p><aclass="reference external"href="https://odoo-community.org/page/development-status"><imgalt="Beta"src="https://img.shields.io/badge/maturity-Beta-yellow.png"/></a><aclass="reference external"href="http://www.gnu.org/licenses/agpl-3.0-standalone.html"><imgalt="License: AGPL-3"src="https://img.shields.io/badge/licence-AGPL--3-blue.png"/></a><aclass="reference external"href="https://github.com/OCA/server-tools/tree/12.0/attachment_synchronize"><imgalt="OCA/server-tools"src="https://img.shields.io/badge/github-OCA%2Fserver--tools-lightgray.png?logo=github"/></a><aclass="reference external"href="https://translation.odoo-community.org/projects/server-tools-12-0/server-tools-12-0-attachment_synchronize"><imgalt="Translate me on Weblate"src="https://img.shields.io/badge/weblate-Translate%20me-F47D42.png"/></a><aclass="reference external"href="https://runbot.odoo-community.org/runbot/149/12.0"><imgalt="Try me on Runbot"src="https://img.shields.io/badge/runbot-Try%20me-875A7B.png"/></a></p>
<p>This module allows to <strong>import/export files</strong> from/to backend servers.</p>
<p>A backend server is defined by the basic <aclass="reference external"href="https://github.com/OCA/storage/tree/12.0/storage_backend">storage_backend</a> OCA module, while it can be configured (amazon S3, sftp,…) with additional modules from the <aclass="reference external"href="https://github.com/oca/storage">storage</a> repository.</p>
<p>The imported files (and the files to be exported) are stored in Odoo as <ttclass="docutils literal">attachment.queue</tt> objects, defined by the <aclass="reference external"href="https://github.com/OCA/server-tools/tree/12.0/attachment_queue">attachment_queue</a> module while the importation itself (resp. exportation) is realized by <strong>“Attachments Import Tasks”</strong> (resp. “Attachments Export Tasks”) defined by this current module.</p>
<p>As importation and exportation are different processes, they are triggered in different ways :</p>
<p><strong>To import files</strong>, you need to create an <em>“Attachment Import Task”</em> (menu <em>Settings > Technical > Attachments Import Tasks</em>) which defines :</p>
<ulclass="simple">
<li>where to find the files to import from the backend server (path to the files, selection pattern)</li>
<li>what to do with the source files in the backend server (avoid duplicates, delete/rename after import…)</li>
<li>how the files will be processed once imported (through the <strong>File Type</strong> field).</li>
🔎 The <strong>File Type</strong> options are defined by other modules built to process the Attachments Queues with the same “File Type”.</blockquote>
<p><strong>To export files</strong>, you need first to register them as <em>“Attachments Queues”</em> objects linked to an <em>“Attachment Export Task”</em> (which set automatically their <strong>File Type</strong> to <em>“Export File (External Location)”</em>).</p>
<p>Then, you can export one file at a time from the <em>Attachment Queue</em>’s form view, or export all the <em>Attachments Queues</em> in a pending state related to the same <em>Export Task</em> from the given <em>Export Task</em> form view (menu <em>Settings > Technical > Attachments Export Tasks</em>) :</p>
<aclass="reference external image-reference"href="https://odoo-community.org"><imgalt="Odoo Community Association"src="https://odoo-community.org/logo.png"/></a>
<p>OCA, or the Odoo Community Association, is a nonprofit organization whose
mission is to support the collaborative development of Odoo features and
<p>This module is part of the <aclass="reference external"href="https://github.com/OCA/server-tools/tree/12.0/attachment_synchronize">OCA/server-tools</a> project on GitHub.</p>
<p>You are welcome to contribute. To learn how please visit <aclass="reference external"href="https://odoo-community.org/page/Contribute">https://odoo-community.org/page/Contribute</a>.</p>