Some account terms are mistranslated, this PR aims to fix these translations. The customer provided a table with the mistakes and suggestions. The customer’s suggestions are available in the ticket.
How to reproduce:
1. Ukrainian translation > chart of accounts > some terms are mistranslated
closesodoo/odoo#126294
Opw: 3247005
X-original-commit: 95ae2afd3bd5b2a2df62e6e33eeb03066d1d8276
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
To reproduce (V16):
0. Install Accounting (can also be reproduced with just Invoicing, but
there is no "journal item" menu that will ease the process to show the
issue)
1. (In debug), change the dollar currency rounding to 0.0001
(instead of 0.01)
2. Go to Accounting > Customers > Invoices
3. Create a first invoice with:
- a partner P1
- set an invoice date
- make sure that there is a payment term set (for example "30 days")
- at least one invoiced line (the product does not matter) with the
tax 15 % and the price to 12.36
DO NOT confirm the invoice
4. Create another invoice with
- ANOTHER partner P2
- set an invoice date
- make sure that there is a payment term set (for example "30 days")
- at least one invoiced line (the product and the price does not
matter)
5. Go back to the Invoices list view and select the 2 new (unposted)
invoices then Action > Post entries.
6. Check Force and "Post Journal Entries"
7. Go to Accounting > Reporting > Journal Items
8. Group by "Journal Entry" and unfold the 2 last invoices (that should
be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)
Analyse:
This issue is a mix of different sub-issues. Solving any of this
sub-issue would solve the issue but as other sub-issues may exists we
will fix each of them individually.
Sub-issue 1:
The account.move.line (=AML) partner is set correctly before the post
(6.), this is during the "mass posting" process that the issue happens.
The partner is changed because of this line:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
The value written to AML of id `line_id` include `move_id` which
overwrite the account.move that was originally set on the AML.
As the `partner` is computed only in certain circumstances, if the
`move_id` written differ from the one of the AML, most of the values
will be updated with the write values, but the `partner_id` will keep
its value (this is why the swap of partner happen).
In other words, this issue happen as `line_id.move_id` order is
different from `key["move_id"]`. So we write on the "wrong" AML.
Sub-issue 2:
In theory, this issue should not have happened in the first place.
The line:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
should have prevent the re-edition of the AML (as actually no relevant
datas are written). But the equality between the dictionaries fail due to some rounding errors.
Here:
- needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
- needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
N.B: if we don't set an "invoice date" on the invoice, a rewrite is
done before which would prevent our issue to reproduce.
Sub-issue 3:
If we try to reproduce the issue without setting a "payment term", the
issue would not reproduce.
By setting a "payment term" the `to_delete` computation change at:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067
This happens as the `existing_before` keys and `needed_after` keys are
different:
- existing_before[<key Invoice 1>]["discount_date"] -> False
- needed_after[<key Invoice 1>]["discount_date"] ----> None
As the values are different, Odoo all the AML to the `to_delete` which
then trigger their overwrite.
In other words, if no "payment terms" were set on the invoices, the
issue would not happen either
opw-3270471,3292931,3333799
closesodoo/odoo#126272
X-original-commit: 074964b6c91d223da0b416855a92e9ed8a17ee55
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
Duplicating the contact that is linked to an attendee of a course also
creates a copy of an attendee as well.
After this commit:
It does not create duplicate attendee in course.
Task-3253983
closesodoo/odoo#126244
X-original-commit: 4af091bd62243db243555d46b97cc7af49ceeeb1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Mayur Raj Sinh Rathod (mrsr) <mrsr@odoo.com>
Reproduction:
1. Install Event, Sales, Webiste
2. Login as Admin, go to Website -> Go to website -> Events
3. Click the Open wood event, Register, buy one VIP ticket
4. In Address step, Edit the billing address, change the name to “Test
Name”, click next
5. The user name “Mitchell Admin” is changed to “Test Name”, we
shouldn’t be able to change the info
Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
we use the can_edit_vat to check if we have existing invoice(s) or
SO(s). However, we should block the route that an employee changes the
billing address when placing an order. If they are placing an order for
external people, it should be done from the back end.
Fix: add an extra error case when it's an employee trying to change the
name or email address when editing billing address. This is the case
when an employee tries to order for external people. They should do it
from the back end. They can still buy for themselves without changing
the billing address. Also added translation in pot. Edited the test for
editing address of log in user, added tests for portal user. Reformat
the invoice exsits check for name change to have better readability
The adding of can_edit_vat:
https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085
Related fix to block the name change:
https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
A patch to not block the checkout process when name is not set:
https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394
opw-3126325
closesodoo/odoo#126261
X-original-commit: 972c55bf76f4c5f1b1bedec4a77ddaeac8be1483
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Current behavior:
When you refund a downpayment in the PoS, the downpayment is not added
to the original order.
Steps to reproduce:
- Create an order in the sales app
- Open the PoS and make a downpayment for the order
- Refund the downpayment you just made
- Go back to the original order in the sales app, the downpayment is
correctly added, but the refund of the downpayment is not added.
- The order should contain : The original product, the downpayment and
the refund of the downpayment.
opw-3275708
closesodoo/odoo#126250
X-original-commit: 95c770c8164ef3d11d27c8cb0fc85e0b0d0054c3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Previously, copy-pasted tables from other spreadsheet editors did not
keep their style once in our editor. This is simply because the way
style information is embedded in the HTML is not inter-compatible across
editors.
Google Sheets places all the cell's style on <td> tags, which can't be
styled in Odoo 15. This has been fixed by moving all possible style
attributes to a direct <span> children, which is created if necessary.
In Odoo 16 and forward, the styles are left on <td> tags.
Microsoft Excel defines the style in the standard <style> tag (in the
<head> of the HTML), using custom CSS classes on tags. We parse that
<style> and copy it to the style attribute of <td> tags with matching
classes. Those styled <td> tags are later handled as described above.
Libre Office makes use of deprecated <font> tags and its specific
attributes. Those attributes are mapped to equivalent values for the
standard style attribute. It also places eventual <s> and <u> tags as
parents of <font> tags, which means the strike or underline doesn't
inherit the style of the text. We invert those for nicer styling as is
the default in our editor.
Tests have been added for each of those aforementioned Spreadsheet
editors, ensuring we save exactly their style values that are compatible
with the Odoo editor, nothing less and nothing more.
Note that for v15.0, background color of cells is discarded as it is not
supported in our own editor. For v16.0 and on, it is supported and kept.
Task-3255167
closesodoo/odoo#126248
X-original-commit: 8b0f7e32ac73636cd3ce142dd44fe921fcc4c849
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Previously, when copy-pasting HTML with styles on styleable tags, those
styles could still be removed by the editor if they had a default value.
This was supposed to be a way to keep the DOM clean and lighter.
However, styles with default values still serve a purpose when
overriding non-default values inherited by their parents. Therefore,
removing them was a conceptual mistake.
One example in the editor where this purpose can be served is in
tables where spans can override the style of the cell or parent span.
This commit ensures we no longer remove style attributes because of
their default value.
Task-3332955
X-original-commit: 39acbc23929f6004e6cb5fe1059ccabf87799e8c
Part-of: odoo/odoo#126248
Removing ps-0 class that was breaking the default button padding
To deal with the possible aligment issue when `btn-link` is used
alone (as this button style has no background), we are switching the
second possible type of buttons to `btn-secondary`. It also matches
with the `btn` combinations used in modals
closesodoo/odoo#126246
X-original-commit: 16237b7ee064a4a7047d0eb6d58a477b048daf67
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Current behavior:
When computing the discountable values of an order, the discount of the
program where not taken into account if you used specific discountable
products.
Steps to reproduce:
- Create products A and B with a price of 20$
- Create a loyalty program
- Rule:
- Minimum qty : 2
- Apply on specific products : Product A and Product B
- Reward : 5 points per order
- Reward:
- 10$ per order
- In exchange of 2 points
- Apply on specific products : Product A and Product B
- Open PoS and add Product A and Product B to the order
- A reward should be added automatically with a value of -10$
- Click on the reward button, another reward should be added but it has
the wrong value. It should be -10$ but it is not.
opw-3232565
closesodoo/odoo#126245
X-original-commit: f33d3b09ff49aae1fdaf3379915b7e7b5f03080c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
The index is being added because when processing a large PoS session, the method consume_specific_qty is called a large number of times if the product categories are set to automatic valuations. This method has the line:
tmp_value += qty_taken_on_candidate * ((candidate.value + sum(candidate.stock_valuation_layer_ids.mapped('value'))) / candidate.quantity)
This line, when running upwards of 20,000 times, can cause large performance issues, due to the stock_valuation_layer_ids being a related field on stock_valuation_layer_id.
This causes a doubling of the number of sql queries which causes slowdowns in performance. Adding this index drastically improves the performance of the queries generated by this line of code.
opw-3295560
closesodoo/odoo#126207
X-original-commit: 6f491e34d9355d1e45599fd0c881d7d721ea7d73
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently we skip the lot_id assignment if move.quantity_done is set,
which causes issues when using "Mass Produce" option.
closesodoo/odoo#126191
Task: 3370869
X-original-commit: 72f316a4c0ad1d443aa84051858fa6d8885b464e
Signed-off-by: Tiffany Chang <tic@odoo.com>
pos_*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert
In many pos l10n addons, we assume that country is present in the company, and
this is a wrong assumption. Thanks to the runbot error that we are able to
detect these mistakes in the code. In this commit, we fix the issue by checking
the presence of country first before actually accession the country code.
Runbot Error: 20917
closesodoo/odoo#126117
X-original-commit: 172a5bc8628f8b774d9738c05c2eb7b0ef4db5ae
Related: odoo/enterprise#43019
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
This reverts commit [1]. It broke all snippet button colors, making
them invisible. Besides that, the fix seems not obvious to make properly
and would thus require some more testing, thus the need of reverting
this urgently.
There is probably more things to consider when remaking that fix:
- mass_mailing scss code in web_editor should not be a thing. Even if
the comment about variables not being accessible is true, there are
definitely other ways to do it (make them accessible, add those rules
generically with a custom selector and fill that custom selector when
mass_mailing is installed, etc etc)
- More than scss code, we really do not want mass_mailing *CSS* rules
in website pages, especially in that code that generates *many* CSS
rules. Of course web_editor.common.scss contains many things that
should not be there and mass_mailing has probably already a lot of
useless code in the frontend assets... but the goal is to fix those
inconsistencies in the future.
- The fix impacts buttons which are not hovered while the goal seemed to
be to have their hover style disabled...
- The fix impacts buttons which are in o_ccX environments only (?) but
seemed to be about disabling all hover styles.
- Much doubt on the need of an at-root instruction, especially since
it creates a bug in frontend pages without o_mail_wrapper containers
so it probably does not work as intended.
- The fix should probably not be about overriding/duplicating the CSS
rules but rather post-processing the mass_mailing assets to remove all
hover rules. I guess it is even possible to do in JS removing the
:hover CSS rules, at worst by moving all CSS rules to inline <style>
rules or something like that.
Note: the main bug about button text being invisible is apparently from
16.0 and up only. This still reverts the code at its root (15.2) for all
mentioned reasons above.
[1]: https://github.com/odoo/odoo/commit/55aff2dcdf5537e16bdaf01ee68d776510572171
task-3376724
closesodoo/odoo#126116
X-original-commit: a6e861b19002b02e369d6b7c1ed5fe1401e77028
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `waitfont.js` module depends on the presence of the `document.body` and it's
possible that during loading of the services, it is still `null`, which results
to indeterministic random error in the test. In this commit, we make sure to use
the module (calling `waitForWebfonts`) only when the pos app is about to be
mounted, such that `document.body` is already present.
Runbot Error: 22519 (and probably others)
closesodoo/odoo#126110
X-original-commit: a1b250f555e328b2d97ae347cef3d71773329d87
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Prior to this commit, when a filter or a dropdown item had a long name,
the layout was broken on mobile, the item went out of the viewport and
wasn't readable.
This commit fixes this issue.
task-3378207
Part of task-3326263
closesodoo/odoo#126071
X-original-commit: 96d1edcdba78af3572c3395867e561c0eb3d5054
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Creating a move line with some reserved quantity should make its stock
move recompute its state as this noew reservation quantity could make it
assigned.
closesodoo/odoo#126069
Task: 3371590
X-original-commit: ca4cf35b3450ad3246e57a34aa8f3fe7c4f187af
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
do not create stock move line from quant for consumable products
Task: 3256447
X-original-commit: b327825de0b50de9cdb81fc9e8384c503351d6d7
Part-of: odoo/odoo#126069
We want be able to click on the button right at the stock move creation
Task: 3256447
X-original-commit: d8926ec8f4a2d8f7840ea4c0ddd8393a74e57d90
Part-of: odoo/odoo#126069
The goal is to provide a better feedback to the user, especially in
mobile mode. With this commit, when switching menus, we clear the screen
and display an empty control panel (only for act_window actions though)
so we have some initial content that get filled as soon as the
view/action is ready.
Task 2900847
closesodoo/odoo#124068
Related: odoo/enterprise#43038
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when the user creates new resource and employee on
the fly in many2one field, the default avatar of Initial name should be
set instead of placeholder (grey icon). The reason why a grey icon is
displayed is because the `_compute_avatar` for employee set that icon
when avatar or image is not found.
This commit add default avatar of initial name when new resource and
employee is created.
task-3251689
closesodoo/odoo#123403
Related: odoo/enterprise#41823
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
before this commit,
once users got an invitation to fill out any survey and if they log in with
another credential than the shared credentials, they will be redirected to the
home page instead of a survey.
after this commit,
if the user tries to fill out the survey with another credential, an error
will be raised that the user doesn't have access
Task-2960271
closesodoo/odoo#102612
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Current behavior:
When the text for the button in the cash in/out popup is too long, the
first number of the amount is hidden behind the currency symbol.
Steps to reproduce:
- Install l10n_bo and PoS
- Switch language to Spanish
- Create and open a PoS with a cash payment method
- Open the cash in/out popup, enter a value.
- The first number of the amount is hidden behind the currency symbol.
opw-3324406
closesodoo/odoo#126120
X-original-commit: decafb5b7d59967d64f5bb553e95fe32c7b0ccb8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Steps to reproduce:
1) Install the timesheet application.
2) Open the grid view and select a project.
3) Search for a task that does not exist, for example, 'xyz'
4) Notice that both 'Create xyz' and 'No records' are displayed
Cause:
-The issue arises when using the timesheet grid view, as the default_project_id
is passed through the context. However, when a project is initially selected,
the props do not update, resulting in the 'canCreate' value being set to false.
Fix:
-This change will allow canCreate value to be set as true when the project
is selected.
-In the timesheet grid view 'no_create_edit=True' is passed, indicating that the
user should not create and edit new tasks. Modifying this value is not
appropriate as it goes against the functionality of preventing the user from
editing the tasks.
task-3318851
closesodoo/odoo#122485
Related: odoo/enterprise#41500
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit,
When you use the 'group by' feature in the portal view of a project, selecting
any value will group the items by stages.
However, when you choose to 'sort by' any option other than 'Title' or 'Newest',
and then navigate back to the project table using the breadcrumb, it may result
in a traceback. The reason why this error occurs is that the query string
remains in the URL even when you switch back to the 'Project' view using the
breadcrumb.
In this commit, keep_query is keeping query in URL so removing it solve
the issue. By default, the 'Stage' is used as the groupby for each project.
task-3318851
Part-of: odoo/odoo#122485
If a cart has multiple lines with the same product (custom/no_variant attributes),
opening the reordering wizard on the portal would fail, because the key used in
foreach would be the same for multiple iterations.
closesodoo/odoo#126151
X-original-commit: 80bce88e73770debe64fb401003dac35cb4f6785
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
New "Re-order from portal" feature for e-commerce orders was not
considering specified no_variant & custom information on the order at all.
This commit makes sure the information is correctly forwarded to the cart,
ensuring the reordered products are the same as the ones previously ordered.
opw-3380312
X-original-commit: 9e774cf88398b7ffc701c4adf44451e39963db08
Part-of: odoo/odoo#126151
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.
opw-3229080
closesodoo/odoo#126144
X-original-commit: cf68853573f70f8dfa84a15ef515479142705a38
Signed-off-by: Tiffany Chang <tic@odoo.com>
PR odoo/odoo#115197 refactored how a field's domain is read.
Unfortunately it removed the ability to use a domain with python code in
it which can lead to a "Invalid domain AST" client error since it is no
longer parsed correctly.
Steps to reproduce:
- Install mrp_workorder and quality_control
- Open Quality app
- Quality Control > Control Points > New
- Click on `product_ids` field
=> Error is thrown. Issue is due to `product_ids` domain being python
dependent (i.e. if specific record value is set => use one domain,
otherwise use other domain):
https://github.com/odoo/enterprise/blob/d2b0eacd68d6558aa9376985a72a350e20d7619d/mrp_workorder/models/quality.py#L101
which isn't correctly parsed into an AST and which results in this call
throwing the "Invalid domain AST" error
https://github.com/odoo/odoo/blob/75c71ccfa8b5daa79f82af1e492831c565ee54f3/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L153-L154C13
Note that the type check is needed because sometimes the domain is
passed as an array and other times as a string and we should only
evalExpr on strings. Also for safety we ensure that we do not pass an
domain of "undefined" as well.
closesodoo/odoo#126089
X-original-commit: ffd4ee838cfddb366aa9aafa2f2d92d9a434569e
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, due to the milk design, there was a gap between the
buttons in btn-group. However, in certain modules, it was necessary to
have a negative margin-left to achieve an edge-to-edge appearance.
To address this issue, I introduced a CSS variable called
--btn-group-gap to control the margin-left property for the elements.
This change allows for customization of the margin-left value, with a
fallback value of $btn-border-width by default, when needed.
task-3336458
part of task-3326263
closesodoo/odoo#126068
X-original-commit: 1a82e8e80745d26b8c96cd5bf0c10f14b793d440
Related: odoo/enterprise#43001
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit increases the priority of the sequence in the ordering of tasks
so that reordering by drag & dropping is more useful.
Task-3371921
closesodoo/odoo#125073
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
before this commit, when creating new record in landed
cost, the newly added record is coming in the last
position in the tree view.
after this commit, the records shown in the tree view
will be sorted based on the desc order of recorded date
in the landed cost.
closesodoo/odoo#124101
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove button is shown when the view of our field is in kanban mode.
When our field is one2many it will delete the record and when our field is
many2one it will remove the record.
So many times user get confuse that they are deleting the record or removing
the record.
So to clear out the confusion this commit changes the label of remove to
to delete if the field is one2many.
A test was added to ensure this ux change.
Task-3185967
closesodoo/odoo#126112
X-original-commit: 008f3e792bd377499fdac5b16de356f9e03b230f
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, to refine the choose of the best existing purchase
order on which we could add the commission, we need to recopy the
query and add new constraint on it.
Now the method return all purchase orders valid, and a simple override
of this method will allow to refine adding filter on current result.
Use the company from the PO and not the company of the current env.
It should be 'more' correct to compute taxes with real used company and
it will also allow to force another company on the po and respect it.
closesodoo/odoo#125572
X-original-commit: 082938d254e9d7fc4ae442412077b9019b2394d0
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
Add a lot of hook to allow a custom module to reuse the standard
sale_purchase module.
X-original-commit: 89a761bdf84f3a9b06f3504f7ee66540ec0e9f0e
Part-of: odoo/odoo#125572
In the course fullscreen view, a black overlay is
hovering the content on medium screen size and lower
when the sidebar is active.
Fix the black overlay which is still showing after
closing the sidebar. When the sidebar is close the
overlay shouldn't be displayed.
As the content is translated to the right and still
fully visible on medium screen size, a black overlay
isn't needed. Only show the black overlay for small
screen size and lower.
Task-3371743
closesodoo/odoo#126118
X-original-commit: f8c45330605837c61f20bed962532b339afc4460
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Context: the subtask button should not be clickable
when all the subtasks are in a closed stage.
The change in this commit fix a problem of the subtask
button, where it would not be clickable even when it
should have been (it had open subtasks).
Also it fixes a tooltip "e" that appeared on hover when
the button was not clickable.
Task-3283488
closesodoo/odoo#126090
X-original-commit: 831d48f1ef301d6f64d53a247515a41cc250f678
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when selecting tags for a task with no project (private
task) on mobile, a warning is displayed. On top of that, the amount
available tags is way more limited than in classical view and the
selection of some exesting tags is impossible.
Steps
=====
1. Warning when selecting tags
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field
A warning is displayed (on the server logs) stating:
"The domain term '('project_ids', 'in', False)' should use the '=' or
'!=' operator."
2. Limited tag choice
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field
- The tags that are only related to project(s) are not displayed in this
view
- Try to create a tag with the same name than an existing tag that does
not appear.
- A traceback is displayed because this tag already exists.
Cause
=====
As noted from the test of expression.py, M2M fields in the domain should
be compared to list of elements. It is not the case here. When a
project_id exits in the context, nothing happens, but there exists a
check in the ORM to ensure that '=' or '!=' operator is used if the
second element of the domain leaf is a boolean. In this case, there is
not project_id set in the context for private task, resulting in
the previous warning (False used instead of project_id).
Fix
===
We use the improved implementation of _name_search to get the ordered
list of id of records project.tags to display. This list has the
advantage to not be restricted to the current project, while still
presenting the tags of the current project at the top of the list. The
mobile view uses the method search_read to get the list of project.tags
record values, therefore we call the _name_search in this method and use
an optimized sorting function to sort the resulting records accordingly.
task-3302370
closesodoo/odoo#126091
X-original-commit: a03a93aa8cf5567f79dd66ced5911721b82a3802
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Ever since iOS 16.4, going back and forth through a website with the
cache enabled, creates an error in the console which Odoo tries to
handle but fails to do so. Therefor a generic CORS error message
appears.
There is unfortunately no proper way to fix this bug on our end so
instead, this commit tries to mitigate the error by returning early and
not showing the traceback dialog.
I (ARD) have submitted a feedback through Apple's Feedback Assistant app
and will subsequently remove this commit when Apple releases an update
that fixes this.
opw-3281727
closesodoo/odoo#126094
X-original-commit: ff78ee498fe858e2564262df13600c64a4e2f418
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- steps to reproduce bug:
In project.task sharing form view, When clicking on any of the stat buttons (subtasks or parent task)
when you arrive on the actual task formview a MissingError saying 'missing record' appears
- Issue:
The record loads accordingly but the Missing Error shouldn't appear
- Cause:
It is coming from the project_sharing_form_compiler which gave the projectSharingId props to the ChatterContainer element
but the projectSharingId is equal to the "props.record.context.active_id" of the action, and in the context of the
chatter we want the active_id to be equal to the project_id, which was the case when we are coming from the KanbanView and
sub-list views but when coming from the task stat button the active_id is equal to the task_id and the env can't find
the document 'project.project' with the id of the task. (in portal.py _document_check_access())
- Fix:
We simply change the projectSharingId to take the "props.record.contect.active_id_chatter" the give an
active_id_chatter= active_id in the Project Sharing task_action which will always equal the Id of the project
Task-3284755
closesodoo/odoo#126092
X-original-commit: 22c0825b70bbe8234dee57060bdd5640001f74d7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Adds more tests to the chart_template update of taxes with children_tax_ids.
closesodoo/odoo#126083
X-original-commit: 747b6498ca86c65ad63fd934e4f57f0c85e56461
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Matheus Leal Viana (malv)