Purpose of this commit is to avoid errors for some performance tests that
have a slightly variable number of queries. Indeed some tests in test_mail
module vary of 1 or 2 queries due to a behavior still not found that does
not seem deterministic.
This should not be considered as a real error, but should not be considered
as completely valid. This is why a margin is accepted in some tests that
will raise a warning instead of an error. This warning tells people to
check if they have increased the query counter or if it is due to a random
effect in query count.
This is a manual forward-port of saas-11.2 commit 3fe0ee5ae6 .
Remove the support to replace emojis by images. Most browser
now support colored emoji or at least black and white emojis.
The emojis list have been updated to ensure a correct support
for most os/browser.
Users have the possibility to install fonts localy if their os does not
have one of the default emoji font installed.
After default os emoji font, one of twemoji, emojione or noto color
will be selected.
The emoji list is now hardcoded in js in order to reduce the number of
records in shortcodes.
Also include a small fix for livechat to display message field when rating
is bad.
Task #36898
PR #23689
The preprocess method checked if the project_id value
was given to determine if it was a timesheet or a normal
analytic line (since a timesheet is an AAL with project_id).
The problem came in the write, when changing only the project
value, the preprocess use the timesheet case, but since the
employee field was not changed, no value was passed, and it
compute the default one. So changing the project of an existing
timesheet reset the employee to the current one.
Query count for some mail tests is not always the same for a given test.
This leads notably to runbot being randomly red although there is no real
error. This commit lessen the issue of having red runbot or wrongly
incremented tests by using the recently-introduced margin parameter on
performance tests.
Some work is still ongoing to find why some tests are not completely
reproducible. In the meantime let us have some warnings instead of errors.
Purpose of this commit is to avoid errors for some performance tests that
have a slightly variable number of queries. Indeed some tests in test_mail
module vary of 1 or 2 queries due to a behavior still not found that does
not seem deterministic.
This should not be considered as a real error, but should not be considered
as completely valid. This is why a margin is accepted in some tests that
will raise a warning instead of an error. This warning tells people to
check if they have increased the query counter or if it is due to a random
effect in query count.
This reverts commit d565596868. Indeed whole purpose of having tests
based on query counters is to fail every time query count is greater than
expected. Query count could be greater than expected because
* either it is required by a bug fix or a feature and tests should be
updated accordingly in the same commit;
* either implementation can be improved to avoid or lessen query count
impact and code should be updated accordingly;
* either we have some random queries due to nondeterministic behavior;
It seems purpose of the commit was to solve the third case. However we think
hiding first two cases can be dangerous compared to solving third case.
Moreover having a threshold of 10% does not make sense. It means some complex
test case could take 30 queries more without being noticed. Some tests could
fail after several commits adding queries and finding them afterwards could
be complicated.
Another solution based on flagging some tests that have a small random
behavior will come soon.
Before this commit, the first thumbnail from the multi image carousel was
always disabled since there are no atribute data-slide-to.
Now we force a '0' string instead of 0 falsy value to have explicitely
data-slide-to="0" after the qweb rendering.
- Display correct bom count for product, before this commit it was
not displaying the bom count when we have bom for template without variant.
task-39561
- Tested the flow and verify computation made in hierarchical order
- Tested with different Unit of Measurements
- Tested with 3 level of componets and sub-componets
- Tested with Work Operations
- Tested with Inventory Valuation
task-39561
Purpose
=======
Compute cost of product(s) based on it's BoM
Specification
=============
real_time: not with FIFO otherwise open the
wizard with the bom price as default new value
periodic: directly set the cost on the form view
Add a server action in order to directly set the price
on selected product.
When getting price from a bom with a sub-bom it will take the
cost of the sub bom except if the sub-bom is set with the bom
itself in the server action (in this case the sub bom cost will
be used).
Capacity is not used for this functionality
task-39561
Purpose of this merge is to link reminders to notes. The whole feature is
therefore moved to node module that extends activities and systray.
See sub-commits for more details.
This merge is related to task ID 1833628. Closes#24129.
Steps to reproduce the bug:
-Let's consider a multicompany environment with company A and B
-Let's consider a shared product P for A and B
-P has a deferred revenue type D set on it
-D is defined in A
-Let's consider a user U in company B
-U creates a SO with P and try to generate the invoice
Bug:
A access error was raised because U is not allowed to see D and
D is needed to genrate the invoice.
opw:1825944
This commit refactors f488dc58c3 that added reminder feature in activities.
After merging it was suggested specifications were not correct and it has
been decided to move the whole reminder feature in note.
Reminders are now notes instead of activities. Now when having note appµ
systray proposes to create a note / reminder. A note.note record is created
with info given by the user. If a date is given in the systray quick create
then an activity is scheduled on this note.
This means user can create records in activity systray that are not
activities but notes used as reminders. Those will use the first availableµ
note column for the user.
As reminders are now notes the support of activities not linked to any
document is removed, as well as archiving activities and tests linked to
that behavior.
This commit has been not carefully tested nor in-depth reviewied. It is
considered as too important for the upcoming freeze. This closes task ID
1833628. Closes#24129 . Many thanks to @dpr-odoo for its quick development
and good work on this task.
When validating a statement with old posted moves, the lock date
was checked by function, _check_lock_date and then it was impossible
to validate the statement even if all the moves were already posted.
Backport of this commit: 86a0d31251
opw:1830804
Purpose is to have first column holding all todos and reminders. We then
add a few columns for today / tomorrow / later to help people organize
themselves.
- We show the completion date of a picking when it's done
- We add the filter that show canceled picking
- We remove the filter that show confirmed picking as it doesn't exist
anymore
TASK-38741
- Delivery slip of a picking not done will show the initial demands
- Delivery slip of a picking done will show details of what have been processed
- Remove the shipment backorder message
- Remove the Weight and show the Shipping Weight
TASK-38741
- Remove 'Production Order #'
- Don't diplay source field if empty
- Change subtittle
- If MO not done, only shown reserved products
- If MO done, show what has been really consumed
- Show product barcode
- Show reserved product location
- Show reserved product tracking data
TASK-38741
Users can configure multiple references in a same
category. This might cause problems during conversion
and does not make sense.
Since this is a "late" constraint, we define it in
python to avoid conflict with existing data.
We allow user to have multiple unactive reference, but
force to have exactly one active. So when a new UoM
category is created, user have to encode the reference
unit first, and then the bigger/smaller ones.
This commit also update stock tests, since they were
redefining new reference UoM in the same category, and
finally, this commit provides some tests for this
uniqueness and custom UoM behavior.
Task #1820076
In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.
Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.
To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)
Task #1820076
When a user click on an action button, we need to check if the record
match with the domain to remove it from the view if this action change
the record value.
Special case: we filter by active field equal true, if the active field
is available in the data (field present in the kanban view).
opw-1832879
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
These modules are currently made to run with an odoo 8.0 server.
They are given as-it on the odoo repository but are intended to be run on the
posbox and not supported on a classic server.
Install a database in some other language than en_US
In debug mode and in the app list viewer,
you'll see that the apps field are translated into your language
Then do an "Update App List"
Reload your page
Before this commit, the Apps' field lost their translation
This was because when checking for any updated data for known modules,
the ORM fetched the translation automatically, and compared the old (translated)
value with the new (English) value from the manifest
After this commit, This operation doesn't make the translations to be lost,
because only english values are compared
OPW 1832796
closes#23910closes#24091
Since 3d04e4488, several pages have to be denoted by:
`<div class="article" />`
And not as previously:
`<div class="page" />`
This was not taken into account in the "Location BarCode" report so we
had only one page of barcode (so 4 barcodes since there is 4 barcode by
page) displayed.
fixes#19698
opw-1817574
closes#24098
Thibault Delavallée