- Set a google analytic key with the admin user (in the settings for
module website admin)
- Give the right to demo user for website as 'Editor and designer'
- Give the right to demo user for administration as 'settings'
- Login as demo user
- Modify the google analytic key in the settings.
Security restrictions error on (Document type: ir.values, Operation: unlink)
This is a complement of commit 6c89b2bdd2
opw-727807
Before the migration, send_mail() used to be called with an untainted
context but after the API migration it inherited the altered context
with active_test=False which caused subsequent calls to
ir.mail_server#connect() to fetch inactive records.
Partially an incorrect forward port of 27b6451. Moreover, the shortcuts
"exp. closing" and "overdue" use the action
`crm_lead_action_activities`, which filters by default
`activity_date_deadline != False`. This should be used as well when
counting.
opw-725666
This is needed in order to clear the 'unreconciled payments' in the bank statement reconciliation report when you wrongly encoded a bank statement and reversed it.
This patch goes along with the modification of the bank reconciliation report in enterprise to exclude such 'reconciled' lines.
The call of the name_get on records with falsy ids was unnecessary
as it wasn't used afterwards and could lead to errors if a name_get
doesn't handle falsy records.
solves https://github.com/odoo/odoo/pull/16244
When posting journal entries for an hr.expense.sheet with several expense lines
(by clicking on the button "Post journal entries"), all the account move lines
created for the same sheet must be linked to the same account move because
the model hr.expense.sheet has just a field "account_move_id" to access all the entries
(by clicking on button "Accounting Entries")
opw:715523,709930,725798,716239
Since ee2c76a431, a new field 'statement_line_id' has been added on account.move.line object and the field 'statement_id' became a related... but this statement_line_id on the bank account aml was, by mistake, not set. That created aml that were wrongly appearing in blue in the reconciliation widget.
If this error occured in a DB, the following SQL query can fix it:
$ UPDATE account_move_line l SET statement_line_id = s.id FROM account_bank_statement_line s
WHERE l.statement_line_id IS NULL
AND l.statement_id = s.statement_id
AND l.name = s.name
AND coalesce(s.partner_id, 0) = coalesce(l.partner_id, 0);
When posting journal entries for an hr.expense.sheet with several expense lines
(by clicking on the button "Post journal entries"), all the account move lines
created for the same sheet must be linked to the same account move because
the model hr.expense.sheet has just a field "account_move_id" to access all the entries
(by clicking on button "Accounting Entries")
This commit reverts f97eb0ac2b
opw:715523,709930,725798,716239
The domain field needs space to be rendered. Even with its "in_dialog"
option activated, the readonly representation can take some space.
If there is not enough space, it will be a mess to read it and the
"-> x records" button can also overflow the "Add filter" button.
This commit makes the field to be rendered as a "block", which fixes
the problem in all current cases.
When there is a lot of texts to display in a tooltip, it will overflow
the viewport vertically as the max-width of the tooltip is set at 200px
(bootstrap default). This commit increases the max-width to the
viewport full-width.
opw-725804
Before this patch, #15920 was happening. The problem was that calling `render_cell` produced a call to [`record.set(column.id + '__display', value)`][1], which triggers the `change` event, which called `render_record` the first time, which called again `render_cell` and produced the 2nd data fetch.
After this patch, `render_record` is only called if there is some place where to put the result, which does not happen in those situations.
There is still the problem that there is one call to name_get for each many2many widget found in a list view (instead of one per full view rendering), but at least they are not two calls!
[1]: https://github.com/odoo/odoo/blob/5d17749ff47c02294d5ff2ae56bbcef9d082562e/addons/web/static/src/js/view_list.js#L1125
- Activate the MTO route on SO lines
- Activate the route "Buy" on a Product A without quantity on hand, add
a supplier
- Create a SO with 2 lines. First line is Product A, second line is
Product A with route MTO
- Confirm the SO, run the procurement if necessary
- Confirm the PO, receive the products
- On the picking generated from the SO, you should have one line
"Waiting Availability" (the line not MTO) and one line "Available"
(the line MTO).
- Click "Recheck Availability". One reserved quant from line 2 is moved
to line 1.
A trick is to assign first the move with ancestors, so we don't "steal"
the reservation on the other move.
Fixes#15950
opw-725373
In maintenance.equipment form view, the field owner_user_id has been replaced
by equipment_assign_to, employee_id and department_id. But in the kanban view,
this field was still displayed even though the image was replaced by the image
of the employee. So now, the kanban view follows the same behavior as the form view.
opw:724378
- Create a PO with a product "Control Purchase Bills" set to "On
received quantities".
- Validate the PO.
The invoice status is "Waiting Bills", while it should be "Bills
Received".
opw-726245
If you had a price with a tax included and the user has fiscal position.
The tax included in the unit price was not substract before the mapping.
Eg: product $115 with tin 15% included in price.
Once in the cart with a fiscal position intracom (0% tva), the unit price
should be 100$ and not 115$.
This commit closes#16022
The mass-mailing App suffered from severe issues due to its inability
to detect and handle duplicates "at the email level", and the absence
of any global blacklist system, leading to lack of user trust.
Mailing-lists typically include multiple records with the same email,
and it is critical to avoid sending them the same email several times.
A related problem is the unsubscription of an email that is present
in other records (duplicates). Opting out the first email should
automatically blacklist it for other records as well.
Ideally we should have a global blacklist table in order to
share the unsubscription requests globally across models (Leads,
Partners, Mailing-list contacts). It would also allow importing
it from other blacklist systems. (TODO for master)
This commit introduces a partial solution, made of several
small changes:
- In mail.mail: double-check that an outgoing email has the
correct status (`outgoing`) before sending it. This allows
adding emails in the queue and cancelling them before they
actually get sent.
- In crm.lead: force predictable recipients for mass-mailing,
by always using the email of the lead rather than the email
of the linked partner when there is one. This simplifies the
computation of the blacklist and seen list. Other areas in
the codebase already assume as much.
- In mass.mailing:
+ Before sending out a mailing-list batch, compute the
blacklist (all opted-out emails) and the seen_list
(emails who previously received this mail) to make
sure we only ever target valid recipients.
+ While delivering the mass-mailing, any email targeting
an address that is in the blacklist or "seen list" is
canceled before being sent. The corresponding statistics
entry is considered "not delivered".
Also updates the "seen list" continuously.
+ When a mass-mail belongs to a campaign with the
"unique AB/B testing" flag, the "seen list" is
common to the whole campaign, as an extra safety.
+ Auto-delete mass-mailing test messages sent with the
test wizard, to avoid polluting the mail_mail table
Note: this fix uses a simple regex for efficiently extracting
the blacklist in pure SQL from different models, and doing so,
assumes that each record only holds a single email
(no comma-separated adresses). This should be sufficient for
most cases. The regex:
([^ ,;<@]+@[^> ,;]+)
We generally consider this a low priority issue
as it is social-engineering based and many easier
options exist for targeting gullible users.
Nevertheless, protecting a couple of obvious pages
does not hurt.
- Create a product with unique SN, create a BOM for this product
- Create a MO to produce 2 units
- Produce the first unit, create a lot number
- Produce the second unit, use the previously created lot number
Nothing prevents the user to do this. However, the user won't be able to
set the MO as "Done", but it is better to prevent the issue as soon as
possible.
opw-724944
When you have multiplle global push rules with the same source location,
a traceback is raised because the '_apply' method of
"stock.location.path" is called with more than one record, and doesn't
handle multiple record.
To fix this, we limit the number of records returned when a global rule
is searched to 1 (as for other 'search' of push rules in this file).
This bug has been introduced during migration in rev: https://github.com/odoo/odoo/commit/cb486d7eb6353a66eea2cb3610141b4f3a778791
opw-725874
When the groups are loaded in the kanban view, a `read` is done on the
relation model to load extra fields.
This `read` was done regardless if there really were extra fields to
read.
This is a priori not a big issue, except if the user has no read
access to the relation model and can only perform a `name_get`.
Martin Trigaux