Introduce a new attachment field (access_token) to allow external
unauthenticated access. This will be an opaque unique number
(typically a UUID) that should be provided via an appropriate
controller, for unauthenticated display.
The field is intended to be NULL unless unauthenticated access has been
allowed, in which case a value will be set for the access_token.
This could be used e.g. for allowing access to images within mailings,
even when the recipient is not logged in (which is sometimes entirely
impossible, when email providers use restricted proxy servers to
load images)
Note 1: this is still a work-in-progress, but serves to freeze the API.
The implementation of the access check and provisioning of the new
field will be added later.
Note 2: namimg collisions with the file download token prevent the use
of a shorter 'token' parameter for download routes.
Apologies for the late (and incomplete) addition in saas-18 :-/
After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
The command does not need to remove existing relations, as there is no relation
yet on new records. This saves one query per many2many field with that command
in a `create`.
Before this commit, and since the combination of new views + datepicker
library update, the datepicker opened at the top left of the window
when using it in a domain selector. It also could not be used at all.
This was because the current scenario occured:
1) Click on the datepicker
2) The datepicker triggers that it has changed on opening
3) The whole domain selector is rerendered
4) The datepicker computes where it should open... on basis of the
old destroyed domain selector
As the main cause of the problem here was the (2), this commit changes
the datepicker odoo widget to only notifies that it has changed when it
has really changed.
Purpose
=======
Steps :
- Blank DB (without demo)
- Install inventory, Sales
- Create some products + update qty + activate serial number from setting and create some products (I tried this step and faced traceback)
- Now try to install Purchase app
It gives traceback..
Specification
=============
As the field po_lock is defined on the res_company and a related field is defined on the res_config_settings.py file, modify the import order.
change the position of res.company file, so that fields of po_lock will define first and then it will not generate field's error in res.config.settings file.
Before this commit, the web client did not properly destroy field
widgets when updating a one2many after an onchange. This is rarely an
issue, because in general, there are no other field widgets besides the
row currently in edition. However, if we specify explicitely a widget,
or if we use a custom widget, it may be a problem.
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
When you open the produce wizard, see all the move lines for a product
to consume with a serial number, we should only see the ones that have
not been already process.
When you are processing a MO or WO, you can set two times the same serial
number for the same product.
To avoid this behavior, we created a onchange on the stock move line to
warn the user when he enter two times the same SN. We also create a
constraint on stock move line to avoid having two times same SN in a
picking.
When you are processing a picking, you can set two times the same serial
number for the same product.
To avoid this behavior, we created a onchange on the stock move line to
warn the user when he enter two times the same SN. We also create a
constraint on stock move line to avoid having two times same SN in a
picking.
When processing picking containing moves without
quantity done and without initial demand. These moves
were moving automatically to a new backorder.
It was also possible to validate picking without
quantity done for all moves.
This commit raise an error if the user try to valiate
a picking with all moves without quantity done and without
initial demand. Or cancel all these moves if the picking
is validate with correct moves.
before this commit, when retrieving the price for a variant for the shop, a floor division was operated, giving out the wrong result.
Now, a standard division is operated