## To reproduce:
=> Import 5 units of P1 at $5
=> Import 2 units of P1 at $2
----> Current valuation: Qty 7, Value $37, Std Price $5.29 (rounded)
=> Change standard Price to 7
----> Current valuation: Qty 7, Value $48.97, Std Price $7
## Solution:
To compute the value delta, we don't use the current standard_price (which may be rounded), but the current value_svl.
OPW-3233260
closesodoo/odoo#115574
X-original-commit: 07ad8744a37a3e8d5a665a452f050e0dfacc6917
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
We have introduced a method that compute the download URL of a slide in the fix
odoo/odoo#113749 which we convert here into a computed field to simplify the
code.
Task-3196081
closesodoo/odoo#115267
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This commit translate the ics file for an event to
the language chosen by the public user on the website.
For connected users, the ics file is translated to
the user's language.
Task-3199180
closesodoo/odoo#115599
X-original-commit: 2fa5ceaf2978036f44027c19abaf17afec1d5db3
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since [1] when the Dynamic Snippet was first introduced, it also
introduced a concept of "inherited" snippets. Specific snippets would
all `t-call` the same template for their rendering.
A mechanism was introduced to deduce the `data-snippet` from the caller
template, but it stored the obtained value in the `t-called` template
itself. Because of this if several "specific snippets" that used that
template had to be rendered, they would all have the `data-snippet`
value of the first one that got compiled.
We could compile the snippet template into something having a
dynamically obtained `data-snippet` value, but then that would be
equivalent to just using a `t-attf-data-snippet`.
All specific snippets already do set a `snippet_name` in the context
because it needs to be added in the classes.
This commit therefore adds a `t-att-data-snippet` attribute on the
base template, and populates with that same value in `onBuilt` for
stable versions.
During forward ports across stable versions, each new caller must be
patched as well - and all patches must be removed in master.
[1]: https://github.com/odoo/odoo/pull/53175
task-2922635
closesodoo/odoo#115566
X-original-commit: 73d2c9f87bf9a1a792f4318325c2e52fc81db5f2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When the user schedules a datetime for the emailing campaign, it creates
a ir.cron.trigger entry that should run the Mail Marketing: Process queue.
This fix tries to take this into account to calculate a next_departure
datetime closer to the true moment job will be run.
When the schedule datetime is between now() and the next call datetime
for the cron job (nextcall field), current logic will always chose
nextcall given the use of max(). This can be confusing for the end-user
as the information banner in the form view will indicate the nextcall date,
which in some cases can be way farther in the futur.
While a ir.cron.trigger is not a 100% guarantee that the cron job will
run at that specific time, it will give better feedback to the user for
when he should expected his mailing campaign to be send out.
Main changes:
simplified logic in _compute_next_departure to take into account
the implicit creation of cron.triggers (methods action_launch and
action_schedule)
added test_mailing_next_departure to simulate "Send", "Cancel" and
"Schedule Date" buttons on mass_mailing form view. Check ir.cron.trigger
model for presence of triggers for cron job "Mail Marketing: Process queue"
and assert if cron.trigger was created as expected
opw-3137819
original commit b98494d
some trailing whitespace got linted from commit 4cebf5
closesodoo/odoo#115068
X-original-commit: f82dec9e6433dc027391978420237efaa1d0be7d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Commit [1] recently restricted the context sent to read records
and related records (m2o, x2m) in form views (see commit message
for details). It restricted the context in too many cases though.
For instance, open an existing record (or create a new one) with
an x2many, and add a line in that x2many. If there is an inner
x2many inside, and there're records in that inner x2many by
default, the context sent to read those records does not need to
be restricted, as this is not part of the (initial) read of the
whole form view.
To reproduce the issue, create a new invoice, add a line: the
default tax's name isn't correct ("15% (Sales)" instead of "15%").
[1] fa11f330b8closesodoo/odoo#115552
X-original-commit: 81c619113fed0b70c2bb69e016b18e1f93ce5983
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
Create an expense by sending an email.
Make sure the product has a zero cost.
Issue:
The expense has no total amount even if
a unit price is detected in the subject of the mail.
Solution:
Compute a total amount if we have a unit price.
opw-3128566
closesodoo/odoo#115620
X-original-commit: eb629fa82cbf592184ed60d0bf309a26a4465b70
Signed-off-by: William André (wan) <wan@odoo.com>
Fix the populate script of account bank statements that
would try to create statement lines with an amount set to 0.
This is wrong, and also causes the populate to fail because
of a constrains
closesodoo/odoo#115597
X-original-commit: 273b99adc34d478d62d107040eae1db3ca883f6e
Signed-off-by: William André (wan) <wan@odoo.com>
Prior to this commit, the generation of token aliases in Ogone relied
on the util function `singularize_reference_prefix`, which is intended
to make transaction references (and not token aliases!) more
distinguishable by suffixing a timestamp accurate to the second. That
util function does not guarantee the uniqueness of generated reference
prefixes, which is okay because the final reference is further suffixed
if the prefix happens to collide with an existing reference.
Using the util to generate Ogone's token aliases, however, poses a
problem because aliases *must* be unique. Otherwise, a customer saving a
payment token at the same second as another customer would end up
linking their payment method to the other customer's payment token.
This commit drops the use of the util method and replaces it with a UUID.
closesodoo/odoo#115580
X-original-commit: 61d833ffcd1562950126d3c87c92569fe35a8b08
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
- enable PICK + PACK + SHIP
- in Inventory/Configuration/Operations Types
- check print label in PACK
Bug:
print label is already enabled by default in the SHIP Operation
and it's not possible for the user to edit it.
Fix:
allow the user to disable print label on the SHIP Operation
opw-3085428
closesodoo/odoo#115572
X-original-commit: 0e26baa8881e44edc85f553559f9c572008a921c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since [1], when a filter dropdown menu is active a check icon is shown but it's
positioned over the carret of the dropdown sub-menu (e.g. a date field).
After this commit, the CSS rules for [1] are excluded when it's a
`o_menu_item` (OWL) to target only Bootstrap dropdown.
Steps to reproduce:
* Open the Sales app
* Filter by the `Create Date` and select a sub option
=> BUG the check sign is on the right
[1]: odoo/odoo@e24bff6991closesodoo/odoo#115551
X-original-commit: 965c6cdcdedcc8696f20a27c39273c0a24c941b8
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
mrp_operation picking type is not handle by default in stock module get_description function.
Add default return to stock get_description function
opw-3232811
closesodoo/odoo#115533
X-original-commit: ea9632e643071ae1b0d85053fde506fb1a7c606f
Signed-off-by: Tiffany Chang <tic@odoo.com>
"Non-stored fields like product.template.location_id/warehouse_id cannot
be searched" log error is generated because the non-storable fields are
not searchable, so it shows a log error for those fields.
This commit added the blank filter_domain in the above fields to avoid
the log error in search.
This fix is for the "product.product" search view for the
"product.template" search view has already been fixed in
https://github.com/odoo/odoo/commit/a5835a160ea3f7aea37644ed4e1a49e2e4a6effd
sentry-3933983991
closesodoo/odoo#115522
X-original-commit: 92448abfb4d488cc03a14e5cec0ca15c49b8e8e5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Task: 857
Description of the issue/feature this PR addresses:
The customer's address is added twice in the printed invoice report but it only has to be shown only one time in the printed invoice.
Current behavior before PR:
The customer's address is added twice in the printed invoice report
Desired behavior after PR is merged:
The customer's address is added only one time in the printed invoice report
closesodoo/odoo#114874
X-original-commit: 9a9c6a5ffcf67f67a1a074caa412345a3b71cbe4
Signed-off-by: Josse Colpaert <jco@odoo.com>
Since c857473 the Kanban arch parser do not take into account the root
node class attribute anymore.
This lead to an issue regarding the x2many fields making use of kanban
views.
This commit brings the following changes:
- the kanban and list arch parsers now share the class attribute in
their arch infos.
- the x2many field adds the className from arch infos to its root node.
closesodoo/odoo#115534
X-original-commit: 980244fa8bf2b720527e457f22c4039c450eed5b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
In the fix introduced in https://github.com/odoo/odoo/pull/114341
we have added a 'position-relative' in the event_track_content
template. As it fixed a quite important issue on screen layout,
we also added a check in the JS to also impact stable instances
not updating their modules.
This commit removes this check in master.
Original task : 3215833
closesodoo/odoo#115515
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
How to reproduce:
- Create a tracked product;
- In the receipt picking type form view, for the lot and serial numbers,
uncheck "Create New" and "Use Existing ones";
- Create a planned receipt for some of this tracked product;
- Confirm and validate the receipt:
It opens the "Immediate Transfer" wizard;
- Apply the immediate transfer:
-> It asks if you want to create a backorder.
Since the picking type doesn't use new or existing LN/SN, it accepts to
be confirmed even if some move lines for tracked product have no
tracking numbers.
The issue was, when a `stock.move` sets its done quantity to its
reserved quantity, if its product is tracked, it doesn't change its done
quantity if it has no tracking number, regardless the picking type's
configuration.
OPW-3186155
closesodoo/odoo#115234
X-original-commit: 89567288e9c134f1262e8ba8b5fc65f730a239cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
When closing a POS session, a journal entry is generated for it. By
default, first we try to create that entry as the logged in user, and if
that fails we try again with sudo.
Suppose you only have the Point of Sale and Accounting apps installed,
and the user has the Auditor role in Accounting. In that case they won't
be able to create account moves. If the user closes a POS session, the
creation of the account move in `_create_account_move` will fail with an
AccessError and the creation will be retried with `sudo` by
`_validate_session`. This works fine.
Now suppose that you have the Purchasing app installed as well. By
default that will give the User role in Purchasing. That role introduces
a restriction on which account move types the user can write to. The
permissions do not include 'entry', which is the move type of the POS
journal entry. If the user again tries to close a POS session, the
creation of the move is able to proceed further, because the role from
Purchasing granted additional rights. The SQL statement inserting the
account move data gets executed inside the transaction. When it
validates the Python constraints afterwards, another AccessError is
raised, because of the rule on `move_type` failing due to the move being
an 'entry'.
If at this point the operation is simply tried again with sudo, the
original database changes inside the transaction will still there, and
will be committed together with the journal entry created with sudo.
This results in an empty draft entry showing up in addition to the POS
journal entry.
To prevent this from happening, the initial attempt is wrapped in a
savepoint so that the transaction gets rolled back fully if the creation
of the account move fails, no matter at which point.
opw-3160140
closesodoo/odoo#115519
X-original-commit: 176ab1db87648198641d0b880d6d2c8ffddf108a
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
The purpose of this key was to force the form view to be in edit
mode directly when opening a record, in specific actions. This is
now automatically the case since form views are always in edit
mode. This commit thus removes the support of the key, and removes
all occurrences where it was set in the codebase.
Part of task 3179751
closesodoo/odoo#115172
Related: odoo/enterprise#38130
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the "Your contact" details in the portal
layout were not shown if the user_id (salesperson) was not set
on the portal user's partner.
In order for them to have contact info in that case, we now use
as a fallback contact the one responsible of their company, i.e.
the first company in the parent hierarchy (corresponding to the
commercial_partner_id field).
We still do not use the user if it they are a public user.
Task-3213421
closesodoo/odoo#114599
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Fix a forgotten field after a renaming after a forward conflict:
[REF] *{stock,mrp}*: rename reserved fields
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: #80434
opw-3225854
closesodoo/odoo#115501
X-original-commit: 022de9edabb9993bfab6dd4e45feed788b7e1c38
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before 16.0 and the "always edit" form views, some fields allowed to
be edited in readonly (e.g. the statusbar in crm lead or project
task). Users could thus change the stage of a record in readonly and
the change was saved directly. If the field was tracked, the change
was even logged in the chatter directly. Since the form view is always
in edition now, we loose that behavior and the user must click on the
save cloud icon to manually save and see the tracking messages. To
mitigate this, those fields that were editable in readonly could save
the record directly when edited, like buttons do.
Changing the values of the following fields should automatically save
the record.
- BooleanToggleField
- PriorityField
- StateSelectionField
- StatusBarField
To accomplish this, we now unconditionally save the record when the above
mentioned fields are changed.
closesodoo/odoo#115500
Task-id: 3175672
X-original-commit: c9b7c43c69eaf87e7900801b926d3868adc36d8c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
In mobile view, when text as well as link is in range the unlink button
in the toolbar was visible.
After this commit:
The unlink button is only displayed when link is in range
Task-3184393
closesodoo/odoo#115161
X-original-commit: 5cab1c90b13074e642f3da3a773c55d37419f90b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
When having long choices in the question form, prevent
the "Upload your file" button from being cropped by applying
a fixed width to the image column.
Task-3215473
closesodoo/odoo#115481
X-original-commit: eb0f2b27cf9c8af1c5c77f0736e430b793e54b2d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
By default, clicking on links in a contentEditable context does not open
the link because it would make it hard to edit it otherwise.
This is a problem now that the views are always in edit mode because it
means the user cannot quickly and easily click on links to open them.
This commit aims to solve this conundrum by finding a middle-ground
between these two use cases, that is reintroducing the oh-so loved
Ctrl+Click behavior that was commonly used in previous versions.
This required two changes:
1. Explicitely implementing the behavior of opening the link in a new
tab in that case since it is not the native behavior in a
contentEditable context.
2. Giving special treatment to links inside a contentEditable context in
the `globalClick` listener introduced at [1] such that the event can
actually reach the custom handler in the editor.
task-id 3188438
[1]: https://github.com/odoo/odoo/commit/47acba560a8954f10bfa97b28daf90047005fdf1#diff-ce4923ebad38db28d4fc17267c93d147c4404feefd42eb140ef990bddbe1a9ffR93closesodoo/odoo#115428
X-original-commit: 8bd6b28f7915d7d84ff42722e5cb4b6f798cb81d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1” with 2 variants:
- Color: Red and blue in this order
- Create a BoM for each variant
- Create a SO:
- select the product “P1 - blue” → the second variant
- Click on the forecast button → manufacturing forecast
Problem:
The BoM overview is showing the wrong product variation because it pulls
the default BoM of the base product (always the first variant from the
list)
opw-3166074
closesodoo/odoo#115421
X-original-commit: 873d6d921c3955b707d10826a898ae405f296531
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signing CLA to be able to merge other pull requests.
closesodoo/odoo#115470
X-original-commit: def64958c3c67d889df4caf4709004f77575ddf5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In some cases name and email are NULL in survey.user_input so it's
return False and can't change the case of the boolean value.
So here add the blank string if name and email is not set.
sentry-3951409506
closesodoo/odoo#115455
X-original-commit: 68b5ab4f2936a02fe8245b887bf402abd4fd2997
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this fix, the 'hide_sponsors' value was used to hide the
row of sponsors in several views:
- page of all exhibitors
- page of single exhibitor
- if website_event_track is installed -> registration confirmation
But actually it did not do anything anymore, because the old
selector used to apply the display none !important was hard-coded
to the previous code structure. This is very unstable, and structure
changed first in 35f70e5f11
Also, o_wevent_sponsor_wrapper selector was not used anywhere.
FIX:
Use o_wevent_sponsor_wrapper to not depend of structure anymore.
'hide_sponsors' adds o_wevent_hide_sponsors on the view and the
sponsors bar will be hidden, as expected.
Task-3213873
closesodoo/odoo#115453
X-original-commit: 13778a454b10aa40fae3cc0e3b7fcbd9e8781ce1
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Commit https://github.com/odoo/odoo/commit/22baab2d0ec2c076a4c769f6c594062c0cea5f90 introduced changes to make sure that
footer is not visibly moving when user moved from course to rating tab
on website slides. However, that issue was already solved in the same
commit, with style changes on o_wslides_course_main. Thus, we were left
with big empty space underneath comments section on not only website slides,
but also on any other place where comments section(portal.chatter_messages)
was present.
This commit removes redundant code in order to correct style in pages where
comments section is present.
Task-3203106
closesodoo/odoo#115431
X-original-commit: a58123c1faf888c561e41fd5716be25a44973d6c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Issue introduced in https://github.com/odoo/odoo/pull/95450
After migrating to 5.1.3 Bootstrap, the col-12 element no
longer had implicit position-relative attribute, meaning that
o_wesession_track_main div was no longer position-relative.
Therefore, children position-absolute elements for loading
and track suggestion at the start / end of the video became
absolute to the window instead, and format failed to match
the video frame anymore, as it should have.
-> FIX : add manually the position-relative back on the live
track container element (see o_wevent_event_track_live).
We also add JS check to make sure we add position-relative
even if templates are not updated in stable, as the screen
is very disturbed otherwise.
Task-3215833
closesodoo/odoo#115430
X-original-commit: 643cdc649bf14d51528e9502266bfbcd62576b6e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Fix the isuue that manual consumption is not correctly calculated when
backorder/split/merge.
closesodoo/odoo#115429
X-original-commit: d72ddd80d8a6aaa808c07db685972a1c05e8d6a4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Purpose
=======
Change the current alert banner closing icons
(a "x" in a gray box) by the new good-looking
bootstrap 5 closing button.
Task-3222588
closesodoo/odoo#115424
X-original-commit: 6f83f60f2f0d031c15df5c3b450fb583feaea3b9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since #104062, the uom field on a scrap order is still editable when it is in the done state. This behaviour is now fixed.
Community PR: https://github.com/odoo/odoo/pull/115288closesodoo/odoo#115399
X-original-commit: 5785d19c749fb1456bf1079d07e83e401850b330
Signed-off-by: Tiffany Chang <tic@odoo.com>
In the profit and loss report, if you go to "Analytic Group By" and select
'Search More' (need more than 7 plans), there is a traceback because
"True" is not a valid JSON.
This PR fixes this by changing "True" by "1" like other occurrences
of multi_edit parameter.
opw-3222611
closesodoo/odoo#115422
X-original-commit: 687a166e8c089a650c99eefe9d604c8c2762e1b7
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>
This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.
How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice
Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.
closesodoo/odoo#115444
Task: 2852452
X-original-commit: 09cb57446d99a48651cbfeeb5405029bc2d77226
Related: odoo/enterprise#38255
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When a company is created during the odoo installation, depending on the installation parameters, importing "res_company_data.xml" before "res_currency_data.xml" can prevent the activation of the company currency.
E.g. a fresh odoo install with account_accountant and no demo data will have 0 active currencies.
X-original-commit: f9247a276b71e9d09bb03c85dc93b36c53703e60
Part-of: odoo/odoo#115444
To Reproduce
============
- go to employees app and filter by `Absent is Yes` then by `Absent is No`
some employees are present in both filters which is not logical
Problem
=======
the search method on `is_absent` field always performs the search `ids in absent_ids` no matter what are the operator and the value
Solution
========
use the `operator` argument in the searching
opw-3205967
closesodoo/odoo#115443
X-original-commit: 89a762ec463efd936c5d60a483f3cac876724b7e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
At the moment translations are only available if a user chooses es_CO specifically. This commit changes it to es, making it available regardless of which Spanish version is chosen by the user.
task-3230384
closesodoo/odoo#115462
X-original-commit: 33b96bce49ea7e0173faf4dc20312dcbe5657634
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
before this commit, the pivot view of hr.work.entry model
is not showing the details by default.
after this commit, the pivot view will be expanded by
employee and work entry type and duration is added
as measure for the pivot view.
closesodoo/odoo#115303
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when toggling the codeview in mass_mailing (debug=1),
the overlay that highlights the selected snippet is not deactivated.
This results on the blue rectangle being seen on the codeview when the mouse
cursor is hovered over the corresponding position.
This commit deactivates the current snippet overlay when the codeview is
toggled.
closesodoo/odoo#115299
X-original-commit: ec8070adb38d092d743679c2dd30872424d46e9d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection is outside the editable and the `autohideToolbar`
option is false, `_updateToolbar` will perform computations in order to
update a toolbar that is not visible.
In fact, trying to do so can lead to a traceback, as `getComputedStyle`
is called with a null argument when the selection is not contained in
the editable.
This commit avoids such useless computations and tracebacks by returning
from the function when the selection is not inside the editable element.
task-3171892
opw-3161789
X-original-commit: d4b13a147f2a69628c050a04655452fcb2e6d759
Part-of: odoo/odoo#115299
Every imported vendor bill now will have the chance to make its invoice_origin linked to a Purchase Order.
The function is moved from account_journal to account_edi_format to allow the link being done from all webservices, thread attachments and upload.
- Avoid mocking the proxy testing
The test on the check that the same attachment is coming twice from the proxy doesn't actually need to test the proxy. By splitting the function, we avoid mocking the proxy for no added value. Added an ir.rule for companies to only look for their account_edi_proxy_client.users
- PA Index label should be Destination Code
PA Index is a completely wrong description. This is the destination "address" of the partner at which our EDI documents (invoices) should be directed to inside the SdI e-invoicing system, much like an IP address. It's not an index, doesn't have much to share with the Public Administration. The correct literal translation of the name should be "Destination Code"
for Codice Destinatario. We have clients opening tickets because they don't recognize this field on the partner form because of the wrong translation.
- Fixes on taxes import
Lines didn't have their taxes cleared, so invoices actually added the taxes in the XML to the default supplier taxes of the product VAT taxes on import search was conflicting with actual withholding / pension fund taxes, so extra conditions are added in the search if withholding / pension fund fields are not specified
Task link: https://www.odoo.com/web#id=3175353&model=project.task
Task-3175353
closes odoo/odoo#114870
Forward-port-of: #111365
Signed-off-by: Josse Colpaert <jco@odoo.com>
Current behavior:
The rescue session are created with a starting balance of 0.00. When the
starting balance should be the end balance of the previous session.
Steps to reproduce:
- Open a POS session on 2 different browsers
- Make an order on the first browser, and close the session
- Make an order on the second browser, and close the session
- The second browser's session will be in rescue mode and the starting
balance will be 0.00 when it should be the end balance of the first
session.
opw-3136236
closesodoo/odoo#115258
X-original-commit: 265817f7d7d096be4a84a7dd710c1dabb93fe402
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
David (dafr)