AWS_BUCKETNAME is only needed in order to write on the bucket, but
read-only access should be allowed for other environments.
Fixes bug introduced by 6c3b610610
When users customize .less files using the 'web_editor', the controller
creates a new ir.attachment for the customized file [0].
The attachment will be stored in S3 by default, which is unfortunate
since it will slow down the generation of the assets. Force storage
in the database for .less files.
Note: beware when porting this to upper versions, check the code of
web_editor, because it changed (notably less files are now scss).
[0] https://github.com/odoo/odoo/blob/11.0/addons/web_editor/controllers/main.py#L370
The labs env can be anything starting by 'labs', such as
'labs-logistics', 'labs-finance', ...
* At install, s3/swift is set as default storage
* However, unlike prod/integration, the storage is not forced to be an
object storage
* Redis is required
* When the storage is set on s3/swift, then the bucket name is mandatory
(otherwise, there is no place where to create the files...)
The redis prefix regex match is relaxed: anything starting by a project
name, then '-odoo-', then any combination of letters, digits, and dashes
is accepted (so a prefix my-project9-odoo-labs-web3 is valid).
The name of the libs and python packages are different, Odoo expects
the inner python package in the manifest, but setuptools cannot find the
libs in pypi, overrides them with the libs names.
OVH's Swift applies a rate limit on the authentication.
attachment_swift authenticates again each time it has to read/write an
attachment. When running upgrades on upgrades of files or installing a
new DB, at some point, we get rejected with HTTP 429.
This commit introduces a shared storage for Swift Session. All
connections will reuses the same authentication token created the first
time a connection needs a Session.
Note: needs python-swiftclient>=3.7.0 to have
https://github.com/openstack/python-swiftclient/commit/1971ef880ff225379d4a91f00f89f323a1605eeb
Some attachments (e.g. image_small, image_medium) are stored in DB
instead of the object storage for faster access.
In some situations, we may have pushed all these files on the Object
Storage (migration from a filesystem to object storage) and want to
bring back these attachments from the object storage to the database.
This method is not called anywhere but can be called by RPC or scripts.
Assume the following situation:
* We have installed addons base, sale and attachment_s3 (hence
base_attachment_object_storage as dependency)
* All attachments are in S3 already
* We run an upgrade of the 'base' addon, 'sale' is upgraded before
attachment_s3 in the order of loading.
* Sale updates the icon of the Sale menu
* As attachment_s3 is not loaded yet, the attachment is created in the
filestore
Now if we don't persist the filestore or use different servers, we'll
lose the images of the menus (or any attachment loaded by the
install/upgrade of an addon).
The implemented solution is to move the attachments from the filestore
to the object storage at the loading of the module. However, this
operation can take time and it shouldn't be run by 2 processes at the
same time, so we want to detect if the module is loaded during a normal odoo
startup or when some addons have been upgraded. There is nothing anymore
at this point which allow us to know that modules just have been
upgraded except... in the caller frame (load_modules). We have to rely
on the inpect module and get the caller frame, which is not recommended,
but seems the only way, besides, it's not called often and if
_register_hook was called from another place, it would have no effect
(unless the other place has a variable 'update_module' too).
When moving attachments from the filestore to an object storage, the
filesystem files will be deleted only after the commit, so if the
transaction is rollbacked, we still have the local files for another
try.
Andreas Perhab
Akim JuilleratandPatrick Tombez
Patrick TombezandGitHub
Mussie SirakandPatrick Tombez
Simone Orsi
Nicolas Bessi (nbessi)andGitHub
Guewen Baconnier
Yannick VaucherandGitHub
Denis Leemann
Simone OrsiandGitHub
Alexandre Fayolle
Jordi Riera
Timon Tschanz