Move the kanban gauge field from web_kanban_gauge to web.
Also delete the web_kanban_gauge module and remove all its references.
opw-3231911
closesodoo/odoo#115293
Related: odoo/upgrade#4437
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since v16, the QRR reference would always be set at 000000000000000000000000000.
This was because of a conflict in the computation dependencies in account_invoice.py: _get_invoice_computed_reference (account_move) was called on a draft invoice, which hadn't compute its name yet. Since the computation of the QRR invoice checks for this name in order to integrate it into the reference, the space dedicated to the name was instead filled with 0 (see _compute_l10n_ch_isr_number).
By manually computing this field, we ensure the reference computation can be completed.
This fix allows for a correct behaviour in v16, while a more sustainable change will be made in master.
closesodoo/odoo#115071
X-original-commit: 7852b0ee4dddf6cf96b6ce40cf7c24011b9ef33a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
To reproduce
============
- on any app try to import a record that has subfields
- subfields are not matched and not even found on the list
Problem
=======
comparing to 16 **Allowing subfields matching** is disabled here in 16.1,
because of this condition that is checking the list of fields on a variable `fields`,
but this variable is not set before importing the file, so the condition is always true.
Solution
========
apply the condition on `res.fields` instead
opw-3209365
closesodoo/odoo#115639
X-original-commit: 284fab64e33ca398a0ebf69d3d6d59685480156d
Signed-off-by: Luca Vitali <luvi@odoo.com>
After 3a798039d6, the emoji in the chat box is not
properly position. This is because of the change in logic in the application
of the calculated position to take into account the tour pointer.
This commit restores the logic of reposition and then made the tour pointer to use
the onPositioned option to properly reposition its element.
closesodoo/odoo#115479
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before commit it you want to print original bills with report_original_vendor_bill and that your list contains a refund it ends up with a UserError "You can only print the original document for vendor bills.".
Fixing the filter, using the is_purchase_document helper, allows to properly print documents, including refunds.
closesodoo/odoo#115452
X-original-commit: 7dd553b8ec1bcea8487dfe71c336787f35d69bea
Signed-off-by: Laurent Smet <las@odoo.com>
The insertHTML test file was named too specifically while we want it to
test the recently renamed `insert` command, which doesn't only insert
HTML.
closesodoo/odoo#114176
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Although Odoo 16.0 was already adapted to work with python 3.11 in
67c7cea , the requirements were left untouched. The purpose of this
previous work was to prepare for the next Debian Bookworm release.
With this commit, the requirements are updated to match the python
packages versions from Bookworm. That way, it will allow people who
installs Odoo in Python 3.11 environments by using the requirements
should be able to do so.
Closes#114195
X-original-commit: fbe4932cd583a2cc019644807a7ea248d34eec80
Part-of: odoo/odoo#115618
## 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>
Julien