Current behavior:
In the PoS when you add an order the 2 terms "Settle the order" and "Apply down payment" where hardcoded in the code.
Steps to reproduce:
- Have PoS and Sale module installed
- Go in PoS
- Try to add an order sale
- The 2 terms are hardcoded and cannot be translated
opw-2754052
closesodoo/odoo#85168
X-original-commit: 440cd020cfce4147973d356fd714a5d78c315c70
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
1) Now report manager (user_id) (with Team Approver rights) can't see the report.
Here we grant him the same rights as the manager (on employee app)
of the employee will have. Moreover, he can approve the report as well.
2) Purpose: accountant, manager, should be able to edit expense_line_ids
for expense report not only in draft, but also for submitted and approved states.
On the other hand, employee can only edit his expense report only in draft state.
task - 2768700
closesodoo/odoo#84978
Related: odoo/upgrade#3274
Related: odoo/enterprise#24579
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Without ce342f42f21cad3 the new test fails because copying an
attachment requires write access to mail.template
closesodoo/odoo#85271
X-original-commit: d5ceaa13a36e86e97f14e870ade477f62234b304
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, `Attachment.copy` has an *explicit* check for write access
on the underlying record.
This doesn't necessarily make sense e.g. a user copying an attachment
from a template to an email may not have write access to the template,
but that should not be an issue. And indeed if the copy is performed
"by hand" (read then create) things work fine[^1].
Since both `read` and `create` are checked, the explicit `copy` check
doesn't seem necessary. Drop it, and try to add some tests around
`copy`. Move `test_06_linked_record_permission` to its own `TestCase`
and split it for readability.
A secondary issue is that the `check` in `create` was performed in the
context of the `self` being copied, leading to the same issue as
`copy` being repeated (that is, `a.copy()` would call `a.create()`
which would call `a.check('write')`, even though we're semantically
creating a record from scratch). The behavior is really intended for
`write` where we want to check if we have `write` access to both the
"source" and the "destination" records.
Explicitly opt-out of having any source data in the `create` before
performing the `check` calls, this way we correctly and only check for
the writability of the destination, and only check for the readability
of the source.
issue 2746483
[^1] well not entirely true, see 4th paragraph
X-original-commit: 60723fb311ed7cc1cf901fe90e8745835cf4d54d
Part-of: odoo/odoo#85271
Since 15.0, the time off type can have different types of approval:
- No validation neededd
- Approved by Time Off Officer
- Set by Time Off Officer
This commit adds a tooltip on the allocation_validation_type to improve usability
task-2681288
closesodoo/odoo#85265
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This flag allows code to detect it's running on a neutralized database.
closesodoo/odoo#85259
X-original-commit: 892efa2c8b85b86155d50055dca568592569d411
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Raf Geens <raf@odoo.com>
In some cases like `fetchmail.server` and `calendar.alarm`, modifying
the record can result in the corresponding cron job being enabled as a
side effect through `ir.cron.toggle`, even if it was archived before. In
`fetchmail.server`'s case on a neutralized database, this can result in
the cron job unintentionally affecting a production mailbox.
Since `ir.cron.toggle` is inherently risky on a neutralized database,
this PR disables it when an `ir.config_parameter` indicates we are on
one.
This parameter can be set both by the neutralization API introduced in
Odoo 15.2 and by legacy neutralization tools for older Odoo versions.
closesodoo/odoo#85258
X-original-commit: 4fba314faa1c8f67ac1dd93351ebf8ce39c5caf7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Raf Geens <raf@odoo.com>
For the moment we cannot star a product from the form of sales view
Steps:
-Sales/Quotation
- Create new quotation
- Add a new product in the order lines
- Open product form from External link
- Try to star product
Because of the quickedit the onClick is called when it shouldn't,
the solution would be to rename the onClick function so that it
doesn't interfere with the quickEdit.
opw-2759063
closesodoo/odoo#85242
X-original-commit: edafd9fe49b1e4c73ee1768efc3df26b463b2f14
Signed-off-by: Achraf <abz@odoo.com>
In neutralized databases, modifying records like `fetchmail.server`
re-activates the related archived cron job as a side effect, which
could impact production mailboxes. The initial solution to this was to
comment out the server action code linked to the cron job as an extra
precaution.
The impact of that solution is too broad, and it also means users have
to be aware of the need to uncomment the code if they do want a cron job
to run on a neutralized copy. It's been replaced by disabling
`ir.cron.toggle` instead:
https://github.com/odoo/odoo/pull/85192closesodoo/odoo#85260
X-original-commit: 6c950959e1f4bed82d62796f0d89d82784e556b6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In this commit we fix computation of likes and dislikes by splitting computation
by usage. Computation for likes and dislikes is improved to be done using a
read_group instead of browsing potentially a lot of slide.slide.partner records.
This should speedup computation, even if we have to do 2 read group instead of
a single big fetch. Indeed we have to take into account vote being 1 or -1 to
compute both values "like" and "dislike".
We also fix batch computation as it was sharing a dict. As frontend UI leads
to voting one slide at a time this should have few effect on stored values.
But now batch computation is correct.
User vote computation is now basically a related on user_membership_id.vote.
We keep the old compute method in case it was called but computation itself
is now done with the other field.
Task-2607416
closesodoo/odoo#85257
X-original-commit: c5b1283862264132d0c2bb1f172c25af5d74448c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Munaf Bahelim <mub@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Recently with commit[1], we changed the sequence for partner grades and
partner activations at db level (from asc to desc) to see the records
created with data files in our chosen order (for example Gold, Silver,
Bronze instead of Bronze, Silver and Gold).
However, there are several drawbacks with this approach. For example
during db upgrade, all the existing records needs to be adapted to
keep up the order of records created by data files.
This commit reverts change of order at db level, and instead adapts the
sequence of the records being created with the data files in a way that
they are still in the same order we wanted. And it will also maintain the
order of the records manually created by users after db upgradation.
commit[1] - https://github.com/odoo/odoo/commit/b28aae2
taskID-2765577
closesodoo/odoo#85235
X-original-commit: 5cc309744de5c2d5713d6bd95d02a66c21aaf11e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, when completing the last step of a tour by hand, the tour
manager attempts to make an RPC to consume the tour in the backend. This
used to crash with an error saying parent._trigger_up is not defined.
This was caused by the root.widget, which is the tour manager parent,
not being a real instance of ComponentAdapter, but an object created
with the ComponentAdapter as it's protorype. To give it access to
_trigger_up, it should be created with the ComponentAdapter's prototype
as its prototype, but this would still fail as it wouldn't have the
correct environment containing the rpc service.
The simple solution is to create a real instance of the ComponentAdapter
by hand. Although owl 2 does not support instanciating components by
hand and mounting them later, we will never mount this component or use
any of its owl features, we are simply using it to replace what used to
be the ServiceProvider in legacy.
closesodoo/odoo#85221
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: mail, mrp
Previously, to prevent images and iframes from making GET requests in
tests, we would listen for the DOMNodeInserted event. This event is
deprecated and should not be used. Additionally, we weren't listening
for attiribute changes for performance reasons, which would result in
some GET requests still being made when an src attribute was changed.
This commit changes the mechanism that is used to do this from mutation
events to a MutationObserver which is not deprecated, and now also
listens for attribute modifications as MutationObservers can be
configured to only listen for changes to certain attributes, greatly
alleviating the performance impact of listening for those.
This mechanism has also been enabled globally by doing it once in the
test setup code, instead of requiring one to call a specific helper, as
we never want to make real requests during tests.
Some tests have been adapted to this new behaviour.
closesodoo/odoo#85216
Related: odoo/enterprise#24665
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Create new UOM categories
- Add a new reference UOM
- Add another line, for example:
- type: “Smaller than the reference”
- Ratio: 4
- Click outside the line
Problem:
The type is changed to “Bigger” and the ratio is reset to 0,
because we are trying to change the type and the factor based on the value of the current uom factor,
but as this factor has not yet been calculated in `set_ratio` the changes will be distorted.
This part of the code in the onchange is useful when for example we already have a UOM category saved,
and we change the reference, in this case all the UOM will have to be calculated again
Solution:
Don't change the factor and the type in the onchange if it's a new line
opw-2754303
closesodoo/odoo#85214
X-original-commit: daf0dd44345de9877e2e79035d05ddca6c19064b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Set the warehouse with manufacturing 3 steps
Create a BoM with a Components that use a Sub BoM
Set Both product MTO + Manufacture
Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO.
The idea between the fix is:
- We want to have the pick components picking merged.
- We want to have the store components split since they come from
different MO
So we create the different procurement groups during the _run_pull with
the picking type of store finished product. This way the pickings won't
be merged during _assign_picking
We will also propagate those groups to the newly created MO in order to
keep the picking type sequence and correct name.
FW PORT of
https://github.com/odoo/odoo/commit/bcfa03821b92bf52675db0e3b54d3cb19dfe3087
opw-2585525
closesodoo/odoo#85195
X-original-commit: a647e680a196f7e6d9147d51dd80f8c31e0e741b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before, if you would put Peru Street 23, it would put Peru in House number.
This is because the editable field was the street field, so behind the scenes,
Odoo will split it and according to the standard format without country,
this means Peru will go into House.
We tried first with a change inversing it, but as we are doing the change,
the best thing is to remove the split all together. We added also onchange
logic that if you put a district it would automatically put the right city.
City or city_id should depend on the country and is correctly inherited by a
fields_view_get.
Task 2724531
closesodoo/odoo#85194
X-original-commit: 47cd0b51fb60cebb88e3a84b7e332e1ff800b0a8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
The demo data created by account did not call _onchange_price_subtotal
on the created account_lines, making the total debit
and credit not matching the state of the lines.
closesodoo/odoo#85188
X-original-commit: 403939ea7b460b95cc31993613f5cba5f5fefcfa
Related: odoo/enterprise#24651
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Improve the journal audit report by adding information about impacted
tax grid for each computed journal.
Task id #2658937
X-original-commit: 09848ba2ae5bd0f25c20a20e73089a5a0f1c8f74
Part-of: odoo/odoo#85188
This commit removes the rating `rating_last_value` field as it is no
more used in odoo.
closesodoo/odoo#84784
Related: odoo/upgrade#3257
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, for the better first user experience, few partner activation
levels are available by default (added in data files). Since there is no
way to archive it, the only way to not use them in your production is to
delete it. But it means that on each migration, it will be restored.
To improve that, this commit introduces 'active' field in the activation
levels so that one can easily archive them if they are of no use, and
this way they won't be again created every time when db is migrated.
This commit also adds a search view with 'Archived' filter to see the
archived activation levels easily.
taskID-2753985
closesodoo/odoo#84401
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When we read data of one record, the method `recompute` (`_fetch_field`
-> `_read` -> `flush` -> `recompute`) can take more than 40 % of the
time of the `_read`, due to a huge number of recordset creation (from
`records_to_compute` and `records & recs`). Avoid that waste of time by
postponing the test on records.
For example, on a database with modules crm, mrp, purchase, website,
sale_management, reading the prefetchable fields of the current company
took 1.45 ms ± 60.3 µs, and now takes 1.17 ms ± 110 µs (more than 20%
speedup).
closesodoo/odoo#83818
Related: odoo/enterprise#24645
Signed-off-by: Raphael Collet <rco@odoo.com>
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
Part-of: odoo/odoo#83818
Remove `prefetch=True` on fields `legend_blocked`, `legend_done` and
`legend_normal`, because they aren't used a lot and translated fields
have a big cost to fetch (one extra LEFT JOIN by translated field).
Part-of: odoo/odoo#83818
Issue
-----
When website is installed, the rendering of template uses a side effect
of the ORM cache (cache shared between sudoed env vs non-sudoed env) and
the fields prefetching feature to work correctly.
The `self.visibility` in (`_handle_visibility`, website/ir_ui_view.py)
is done in sudo mode, then it will fetch all prefetchable fields and put
them in the cache (that will be read in non-sudo mode in the render of
the template). Another example of issue related to this:
https://github.com/odoo/odoo/pull/83341.
Because of this, the fields of mixin `website.seo.metadata` were forced
to be prefetchable (the default for translate is to be not prefetchable
since https://github.com/odoo/odoo/pull/82896), which causes a useless
LEFT JOIN on "ir_translation" in most of business flow.
Fix
---
Remove the `prefetch=True` on mixin fields, and add a extra read to fill
the cache in case of website rendering. It also allows to read these
fields at the same time.
Part-of: odoo/odoo#83818
We split the test in three to allow easier debugging at no cost in line
of codes and by extracting a part that could be used for future tests.
task-2659750
closesodoo/odoo#85162
X-original-commit: 8502d4ec895f2d4a2ddb1b305a9f6f119da750fa
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
The tax adjustment wizard shows tax reports of countries other than the
current company's country
Steps to reproduce:
1. Install Accounting
2. Go to Accounting > Configuration > Management > Tax Reports
3. Create a report for another country than the current company and add
a line with a tag name
4. Go to Accounting > Accounting > Actions > Tax Adjustements (in debug
mode)
5. The created tax report line is suggested but it shouldn't
Solution:
Put the domain of `tax_report_line_id` in python and add a filter on the
country
opw-2760337
closesodoo/odoo#84854
X-original-commit: cc13d20996f1e0a261829ced91cbbe18d6236fb5
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Go to inventory > configuration > Products > Attributes
- Create a new Dynamic Attributes > add two attribute values
- Create a storable Product “Test”:
- Add the two attributes
- Save
- Create a BOM related to this product
- Create a new manufacturing order:
- Do not choose a product
- Select the BOM related to the product “test”
Problem:
Traceback is triggered because as the product template only has dynamic variants, there is not a `product.product` record created yet.
but we try to access it in the onchange: https://github.com/odoo/odoo/blob/14.0/addons/mrp/models/mrp_production.py#L598
Solution:
do not set the product when a BOM of a product_tmpl without a variant was chosen
opw-2732254
closesodoo/odoo#84543
X-original-commit: 50b538e7d32bbce7cad7c05f0bc80db6b969a70b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In mass mailing edition :
Replacing a font awesome icon with an image was not working properly.
task-2733908
closesodoo/odoo#85167
X-original-commit: d4d25c8b497e465753cef030292faa4824145cb1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
PURPOSE
Make it easier to submit reviews and improve rating display.
SPECIFICATIONS
Remove useless and empty "Published on" + DATE MISSING when creating and/or
updating a comment response.
Fix various display of rating values when containing more than 2 decimals. Add
rounding in both frontend display as well as backend statistics computation.
In order to reduce friction and ease the rating process for attendees we do not force
the constraint stating that the message must contain a message or an attachment
onto the users. Do that only for courses
Fix various display issues (star titles, spaces, ...)
Task-2728564
closesodoo/odoo#82792
Related: odoo/enterprise#24640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When hovering a star, a title is disturbing since a description is already
displayed to the user. "One star" is therefore confusing since it will appear
on every star, even for the fourth one out of five, for instance. Therefore,
all titles are removed from stars. Also, to avoid this confusion in aria label,
we do not use numbers in cleaned labels.
Task-2728564
Part-of: odoo/odoo#82792
Before, the inline-block style created some small unbreakable whitespace between
the stars in the review/rating composer. It meant that when the user hovered
their mouse in that space, they left the star element, but not the stars area,
hence displaying the message of the default (current) rating instead of the one
that corresponds to the closest star. It is repaired using an inline-flex for
the stars area. The stars are also centered in their element, with a small
horizontal padding.
Task-2728564
Part-of: odoo/odoo#82792
In order to reduce friction and ease the rating process for attendees,
we do not force the constraint stating that the message must contain a
message or an attachment onto the users. Instead, we allow ratings and
replace the empty message by a blank space to avoid triggering the error
message. If no stars are selected, an error message is now displayed to
the user, asking to select a rating before submission, preventing them
to post their review until then.
Since we do not really support 0 stars ratings, and do not want the user
to see that error message in case of the course, we set the default rating
to 4.0 instead of 0.0.
-> Therefore, we also remove the grey star contrast coloring on first review
since we do not want the user to have the impression a choice has already
be made beforehand. In that case, everything will be yellow.
Void content detection is done by extracting it in both python (portal
chatter post controller) and frontend (submission check) and relaxing it
in slides modules.
Task-2728564
Part-of: odoo/odoo#82792
When hovering the number of stars of a course in front-end, for instance,
one can see "4,16666666666667 stars on 5". This is not very convenient.
The number is rounded up to two decimals instead. -> "4,17 stars on 5".
Same fix is done in backend in slides-specific kanban view of ratings. Value
is now rounded.
Finally _rating_get_repartition is fixed round values to the nearest half
value. We generally receive integer values between 0 and 5 but other values
may exist. Getting a repartition rounded at nearest half integer is sufficient
notably when looking at star-based display which covers only complete or half
complete stars.
Task-2728564
Part-of: odoo/odoo#82792
Co-authored-by: Noé Antoine <nan@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
When answering to a comment, or editing such an answer, the form shows
a "Published on" which is supposed to be followed by the date the comment
has been published. However, since when using the form we are editing or
creating an answer comment, it remains empty and useless. Therefore, we
remove it. It is still on comments once set, but not while editing them.
Task-2728564
Part-of: odoo/odoo#82792
Purpose is to try to have a single entry point when dealing with rating
values. Also fix incoherency introduced with odoo/odoo@32ba417549 where grades
are not coherent in all computation. This new computation seems better as
bad is now limited to <= 1 everywhere.
Task-2728564
Part-of: odoo/odoo#82792
It currently holds two different mixins. Let us split it into two files in
order to have a file per model. Also a quick reordering of rating model is
performed just to sort a bit things
Task-2728564
Part-of: odoo/odoo#82792
For surveys, we want to allow the end-user to un-tick an option he had ticked
before, for any kind of questions with choices (simple / multi-choices and
matrix).
e.g: You select an option but on second thoughts you're unsure it's the right
answer, you want to be able to remove your answer.
Especially if the question is not mandatory and you loose points if you don't
answer correctly.
Since the base browser behavior does not allow un-ticking a previously ticked
radio input, we have to play around a bit with specific classes.
Task-2727592
closesodoo/odoo#82272
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some useless SMLs are generated when editing the on hand quantity in
inventory mode
To reproduce the issue:
1. Create a storable product P
2. Update its on hand quantity to 100
3. Inventory > Reporting > Inventory Report
4. On the line for P, update to quantity to 75
5. Inventory > Reporting > Product Moves, search for P
Error: There are two SMLs with a quantity equal to zero
Calling `action_apply_inventory` from the `write` is useless since the
method is already called in the inversed method of
`inventory_quantity_auto_apply`
OPW-2739833
closesodoo/odoo#85152
X-original-commit: c2164fba4a9049115a6a46de28a90fc779fb9eee
Signed-off-by: Arnold Moyaux <arm@odoo.com>
roen-odoo