Before this commit when you create an event from a lead, a button appears to jump back to the lead but while you're creating the record, it already appears but empty.
This commit hides the button in case the res_model_name is null, which happens while we are creating the event and before hitting save.
closesodoo/odoo#154956
Task: 3747059
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
The account_qr_code_emv module has an issue at the
moment where it will only return errors in
_get_error_messages_for_qr for the country the qr
code is intended for.
This makes sense since you want to check all countries
in later versions where we have multiple of them.
But it causes an issue with the standard implementation
where if you are using a country that is not supported
by an EMV QR, _get_error_messages_for_qr will just
return None.
This means that:
- The default QR CODE selection on the invoice that
depends on that may select EMV QR for unrelated
countries.
- If it gets selected, this method will not check
that the currency is correct for said countries.
To fix this issue, we will simply return an error
message in the common module, which will serve as a
fallback once all the EMV QR methods have been checked.
Task id # 3758668
closesodoo/odoo#156847
X-original-commit: 5290fb7a2d400ce1c9732e8d835f6b7990c0d145
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The widget for actionable errors does not update when the errors it
displays are updated due to, for example, a recomputation of the field.
This results in irrelevant errors being displayed in the view, when a
particular configuration is correct. The correct errors (or an absence
of any errors) will not be displayed until the view is refreshed.
This commit adapts the component, such that the record data is accessed
directly from the template. This means that the recordObserver, and the
method it uses can be removed (as they were redundant)
closesodoo/odoo#155914
Task-id: None
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Making a mention in full composer when `im_livechat` is installed
was making the following crash:
```
TypeError: Cannot read properties of undefined (reading 'type')
at SuggestionService.fetchSuggestions
```
Steps to reproduce:
- install module `im_livechat`
- open contacts app form view
- open full composer (e.g. Log note => expand icon)
- type @ + a character
=> throws error above
This happens because `SuggestionService` methods can optionally pass
a thread, but livechat overrides wrongfully assume they were always
provided.
This commit fixes the issue with optional chaining, taking into
account it's optional.
No test because full composer doesn't work in unit tests, tours
require adding steps blindly and I've already wasted too much time
to no avail.
closesodoo/odoo#156773
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit and most likely since commit [1], the "Open in new
window" option of link would not persist through editions.
Steps to reproduce:
- Create a link in the website builder
- Set its "Open in new window" property to true
- Save, and see that it works as expected
- Now enter edit mode again, the toggle will be off and not on as it
should be since the `target="_blank"` was correctly added.
For easy of debugging and understanding, you can just grep this line
```js
this.initialNewWindow = this.initialNewWindow || this.linkEl.target === '_blank';
```
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#
opw-3781477
closesodoo/odoo#156739
X-original-commit: 5ea2e015a8faed502c378d4e5042f8a0cf50cbf9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behavior:
When printing products ZPL Labels, special characters are not printed
correctly. e.g. quotes become '
Steps to reproduce:
- Modify a product name with special characters
- Print a product label
- Select ZPL Labels
As the report is only rendered as text, the special characters are not
dangerous and can be printed as is.
opw-3684870
closesodoo/odoo#156624
X-original-commit: 7875c91be5dd467374b39bc1a7d05e9f983fbaef
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When configuring the payment term to include the EPD within the payment's journal entry on a customer invoice, the tax_tag_invert field got wrongly set as True. This was hardcoded in the code; computing the field in the regular way gives the proper value.
OPW 3754446
closesodoo/odoo#156588
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Purpose
=======
Fix the UserError which is raised when the user submits
an answer to a question having the "save as nickname" or
"save as email" option checked. In testing or non-testing mode.
Specifications
==============
When the question is marked as "save as email" or "save as nickname"
and when the user isn't public, the partner data is already saved
as the question answer (in the form of a user input line).
The answer is then pre-filled in the survey.
This is an issue because when the survey has the "users can go back"
option to False and the user tries to submit the answer, it thinks the
user is trying to changed the already saved user input line and it crashes
for security reasons.
In addition of allowing the answer override if the user can go back,
also allow the override if the question is marked as "save as nickname"
or "save as email".
This issue was introduced in 17.0 when the overwrite_existing optional
parameter has been added on the _save_lines method. Before that, the
existing user input lines were overwritten no matter what.
related odoo/odoo#129329
Task-3756749
closesodoo/odoo#155561
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Have company A and company B
With company B:
- Create an analytic plan with default applicability 'Mandatory'
- Add an applicability: domain 'Expense', applicability 'Mandatory'
With company A:
- Open the same analytic plan
- Set default applicability 'Optional', no assigned applicability
- Add an analytc account for the plan
- Create an expense, add amount
- Create report > Submit to Mananger > Approve
Issue: Action will be blocked by Warning message
"One or more lines require a 100% analytic distribution."
This occurs because the system checks all applicabilities of the plan
without taking into account the company
opw-3709374
closesodoo/odoo#155195
Signed-off-by: William André (wan) <wan@odoo.com>
Prior to this commit, in the event of an RPCError, such as UserError or
ValidationError, it would display a generic 'Odoo Server Error' error.
This error lacked useful information for diagnosing and addressing the
issue.
opw-3776047
closesodoo/odoo#156697
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previous PR: odoo/odoo#135739 added in report placeholders for the sake
of easier editing of reports with studio. Unfortunately it didn't check
that these placeholders aren't printed with real records which results
in junk being included in the report, so we add in conditions to avoid
this situation.
Also, since the report was already being edited, clean up some of the
placeholders because they didn't make sense/ didn't do anything (e.g.
the `address` values weren't used + already have a special placeholder
in studio => remove them).
closesodoo/odoo#156674
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Enable MTO
- Create a manufactured product (no analytic distribution on the bom)
- Create an SO for that product and set an analytic account on it
- Confirm the SO
Bug:
no analytic account on the created MO
Fix:
inherit MO analytic account from SO if none is set on the BOM
opw-3708134
closesodoo/odoo#156535
X-original-commit: cd72327ff3fb3633e353b7f9443ca973c358fc01
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Both the `payment_custom` and the `account_payment` modules made changes
to the visibility of the `payment_followup` group in the view of the
`payment.provider` model. As these modules didn't depend on each other,
the visibility of the group was determined based on the (random) loading
order or the modules, causing the "Journal" field to be either visible
or invisible on other providers than Wire Transfer.
With this commit, a priority is set on `payment_custom`'s view to force
it to always load after that of `account_payment`.
closesodoo/odoo#156514
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Type an insdustry ... is not kind of something lean for user, this
commit change industry placeholder into a more cleaner version
closesodoo/odoo#156456
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this fix:
Receipts printed with kitchen/preparation printer does not show the details
of variants products. Just the product template name.
This is ambigious for kitchen as the variant information is generally
necessary in order to prepare the order correctly
After this fix:
Restore the previous behavior regarding the product name used
This bug is a side effect of:
https://github.com/odoo/odoo/pull/152213
due to the changes to `set_full_product_name`
Was also a good occasion to add some tests on the changes name & qty
opw-3755391
closesodoo/odoo#156390
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
This tasks aims to improve the out-of-the-box configuration of the NZ
localization by updating some tax groups, taxes, accounts and default
COA settings.
Task ids 3647518 & 3647460
closesodoo/odoo#154541
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Purpose
=======
When you go on any survey results page, you notice charts are smaller
than they used to be on version 16. But there are still readable. The
annoying part is when you click on the `print` btn or press `CTRL + P`,
the charts disappear from both the page and the window preview.
How to fix
==========
- add classes `w-100` and `h-auto` to the canvas elements containing
the charts
Also, we empty the before/after print events in the public widget. They
are no longer useful, but someone may have hooked in those function.
We want to avoid the fix breaks someone else code.
see #135683
task-3667969
closesodoo/odoo#152705
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Description of the issue/feature this commit addresses:
There is no localization for Zambia.
Desired behavior after this commit is merged:
This commit adds the base package of the Zambian localization including:
- Default Settings
- Chart of Accounts
- Taxes
- Fiscal Positions
- Reports (BS, P&L, Tax Report)
task-3391861
closesodoo/odoo#150134
Related: odoo/enterprise#54707
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit replaces the Display Name column by the Name column in the
Amounts to Settle view and adds the Journal Entry to the search options.
It also includes a small modification to the Amounts to Settle opening
action to adjust the amls that are shown.
task-3640027
closesodoo/odoo#148476
Related: odoo/enterprise#54137
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Since the commit [1] introducing Bootstrap 5, buttons within input
groups (e.g., "search bars") no longer have the same border-radius as
the inputs.
Steps to reproduce the bug:
- In Website edit mode, drag and drop a "Search" snippet onto the page.
- Click on the "Theme" tab.
- Set the inputs "Border Radius" option to 25px.
- Bug: The border-radius is not applied to the right side of the search
bar.
[1]: https://github.com/odoo/odoo/commit/9ea13513342b14e6b8d4e10e162b618a6ab2cce0
task-3662985
closesodoo/odoo#156603
X-original-commit: 58b57af056a83cda3d8caa6c22d8564c3f9816c9
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Previously, In "one_page & page_per_section" survey, pressing Enter would
submit the survey, leading to confusion and accidental submissions, as users
might press Enter intending to navigate through questions.
With this commit, Now, requiring "Ctrl + Enter" to submit, ensures clarity in
survey submission, reducing the chance of accidental submission.
task-3707763
closesodoo/odoo#152850
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit fixes the flicker issue of buttons hovering over content
on the course page.
Task-3751285
closesodoo/odoo#156543
X-original-commit: bc8162cb9786a8db9c32c62cfd43e5f422c9271a
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In this commit we will adds tags to some accounts. The tags added correspond to
a mapping that was added in this PR: https://github.com/odoo/enterprise/commit/81c427ba1a505e1e9d4a64dd6227bbb747214142
This mapping was useful to separate the tax and net amount and then use it in
the appendix A of the annual report.
We decided the use tags instead of this mapping so that it's clearer for the
users and to give control to them.
closesodoo/odoo#149752
Task: 3646832
Related: odoo/enterprise#54525
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
after this commit: [commit](https://github.com/odoo/odoo/pull/148866/files)
If tags belonging to localization are present in the database but with active='f', the user error will still trigger.
As mentioned in the commit if tags are deleted by the end user, then updating the localization module will resolve this and will create the new tags for that localization, but in our case if the tag are present in the db but are active='f', so updating the localization module will not help as noupdate will become true, if the enduser makes any changes to it. so updating the localization will not change active='f' and the user error will keep on coming unless the end user manually set it active='t'.
So, as this mentioned commit is introduced in 16.2, any db migrating to v16.2 or further, when the ```_get_tag_mapper``` is trigger this user error is blocking the migration.
Steps to reproduce:
1. Create a database in saas-16.2
2. Install the module account_accountant and a localization, for example l10n_ee.
3. With debug mode on, navigate to the account tags menu
(Configuration > Accounting > Account Tags).
4. Archive any tag using the archive action.
5. On the accounting settings page, under Fiscal Localization, trigger a user error when clicking the reload button.
This user error is blocking.
By making the record inactive, the user has made the account tag no-update, so upgrading the module does not solve this.
This commit add a context to include the inactive tags here:
[here](https://github.com/odoo/odoo/blob/saas-16.2/addons/account/models/chart_template.py#L924-L928)
OPW-3716164
UPG-1297494
TBG-1074
closesodoo/odoo#156627
X-original-commit: 328508bbdab1608e596a10f213c4a8e16d8e2a9c
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit:
Ctrl+clicking on a styled link is ineffective since the target is the styled
element, which lacks an href.
After this commit:
The target should be set to the nearest `<a>` tag rather than on the styled tag.
task-3773924
closesodoo/odoo#156544
X-original-commit: baf0a2f1e77b2f7aeb7f9fd657650829e5ba5e13
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Before this commit:
- Navigate to the author's profile from a course on website forum.
- Go to the Questions tab and remove the existing filter
- It directs to the login user's profile instead of removing the filter.
After this commit:
Now when the filter is removed and all the questions of the author are shown
from his profile.
Task-3725329
closesodoo/odoo#156536
X-original-commit: bde4e9ec29ff6daab29bc541a2baa07a74496f02
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Vivek Pathak (vivp) <vivp@odoo.com>
Issue:
- Expenses entered in currencies other than the company currency are
incorrectly calculated using today's exchange rate instead of the rate
applicable on the date the expense was made. This results in inaccurate
totals in the "totals to submit" section of the Expenses application.
Steps To Reproduce:
- Go to Expenses.
- See that the expenses to submit is $4,216.44.
- Create a new expense that is 999,999 EUR but $1.00 USD.
- See that the expenses to submit is $783395.96.
Solution:
- summing up total_amount_company directly instead of total_amount and
then converting to the company currency.
opw-3731445
closesodoo/odoo#156591
X-original-commit: 2c8b13e9270d2ccd6651e7618cbc363c1dd49f43
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
In [1], we added a rounding of the amounts in the `<PriceAmount>` tags
to avoid floating point rounding errors. However, it seems the
`float_round` function does not guarantee to avoid these errors.
Take the example of `price_subtotal` = 250.80 and `quantity` = 3.
We will compute the PriceAmount as 250.80 / 3 which yields
83.60000000000001. Even when using `float_round(amount, 10)`, it still
results in the same amount with the rounding error.
For that reason we use the built-in `round` method of Python instead.
[1] 58d57bbbaaab32ba0183890a9182e6de09b32ac5
closesodoo/odoo#156555
X-original-commit: 0b21d562fe4d315c01421b3f242e274830c34e79
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Side effect due to a combination of odoo/odoo#124182 making field_id not
required to keep trackings when removing fields, and odoo/odoo@9c9552fd20
where field is used to find model when computing groups instead of message
in case the tracking is logged on a model different from the field model
e.g. accounting.
Steps to reproduce:
1. Install project_enterprise in saas-16.4
2. Create a task and update some values for Date deadline
3. Upgrade to 17.0
4. Try to open the task in the upgraded DB.
We get an error:
```
ValueError('All tracking value should belong to the same model.')
```
The reason is that `date_deadline` field is removed during the upgrade
and thus `fields_models` is empty in
https://github.com/odoo/odoo/blob/0649134444fa6b26de1c8c25d7c4a3f70c6d64e0/addons/mail/models/mail_tracking_value.py#L120-L121closesodoo/odoo#156571
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In odoo/odoo@9c9552fd20 a support of tracking value belonging to another model
than the message has been added. In such cases the formatting method written
at odoo/odoo#124182 fails as it expects a single model for all tracking values
it receives. When field is removed 'model' is False, and we fallback on
mail_message model.
Part-of: odoo/odoo#156571
When there is no channel members to be updated the seen status, we
should not send a notification to the channel members, otherwise it
will lead into creating a channel member with id undefined.
test case added to check that the notification is not sent when there
is no channel members to be updated.
closesodoo/odoo#156534
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit changes the computation of product having a negative forecasted
quantity to create manual orderpoints. The issue was that each replenish
location needed multiple `_read_group` on `stock.quant` and `stock.move`
on all storable product.
This commit makes only 3 `_read_group`s for all products x locations and
post process the group and quantity sum by location in Python.
This method gives some performance gain in time as well as in memory
consumption
closesodoo/odoo#156507
Task: 3653272
X-original-commit: 1a061791e68a524480b4f230031af25411603606
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Behavior before the changes:
- When a note was modified, it cancelled the old orderline and recreated
it with the new note.
- Products were not sorted by category in the order preparation display.
- Clicking on the header of an order sent it directly to the next stage,
regardless of whether lines were crossed out or not.
- There were brackets around the order number.
Behavior after changes:
- When a note is modified, it is modified directly on the existing
orderline.
- Products are now sorted by category in the order.
- Clicking on an order header sends only the crossed-out lines to the
next stage. If no line is crossed out, the entire order is sent.
- There are no longer any brackets around the order name.
taskId: 3764317
enterprise PR: https://github.com/odoo/enterprise/pull/57385closesodoo/odoo#155246
Related: odoo/enterprise#57385
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Correct the terms in this module and translate them in Italian.
closesodoo/odoo#156502
X-original-commit: 8f4ded8ebb85e996c2fc556efd0ad080095ff82a
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Function `_pre_reload_data` checks for the existance of accounts with the same
code to avoid creating a duplicate. It does so however comparing with the code
before normalizing it with the length from the template, failing to find
possible duplicates with a normalized code.
closesodoo/odoo#156498
X-original-commit: d60a6d25ad31d85fd3737b0a96ef9958fbed9c70
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- create a relational filter, let's say on `res.company`
- add a default value
- reference the filter in a cell with `=ODOO.FILTER.VALUE("my filter")`
=> every `ODOO.FILTER.VALUE` triggers an evaluation
With this commit, the re-evaluation after the data is fetched uses the
data source mechanism which only re-evaluates when all the data promises
are resolved, instead of evaluating after every resolved promise.
With this commit, the number of evaluations required when loading the
Timesheet report on our prod goes from 5 evaluations to only 3 (each evaluation
is 2-3s) because `ODOO.FILTER.VALUE("Company")` is present two times.
One issue this commit doesn't fix: there one RPC per `ODOO.FILTER.VALUE`
(can be fixed in master very easily because we refactored data fetching)
closesodoo/odoo#156495
Task: 3787125
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
For repaired products with no stock, a new picking is wrongly created,
leading to a gap in the repair sequence.
This because the move is created in 'draft'
and the function does not take it into account.
closesodoo/odoo#156476
X-original-commit: b2f26a522d75d6f1e73076323384163595b29874
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Jean-Francois Aubert (ajf) <ajf@odoo.com>
Once a user posts a review, they are able to edit this single review
and not create any new ones. However if the user had multiple tabs open
of the same course, then they can still access the "Add a review"
functionality.
This fix enforces the single review per user per course policy.
Task-3721958
closesodoo/odoo#156411
X-original-commit: 61a95ad41e0b0c72554a491c555ddd33d8588566
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Bram Van Gaal (brvg) <brvg@odoo.com>
Description:
Since https://github.com/odoo/odoo/pull/76734, the new field
`alias_full_name` is used in addition to `alias_name` to search on
`mail.alias` and route emails in `message_route`. It's also used as
a search criteria in `_search_alias_email` on `mail.alias.mixin.
optional`. The issue is that the table `mail.alias` can grow quite
large, and only the old field `alias_name` has an index on it, which
may not be selective enough, forcing Seq.Scans on the table with
possibly millions of records. The impact is noticeable on
`message_route` which is a hot path for processing incoming emails.
Adding an index on `alias_full_name` allows PostgreSQL to do an
bitmap OR scan on the two indexes, considerably speeding up search
criteria that are a disjunction between `alias_name` and
`alias_full_name`.
Benchmark:
For domain
```python
[
'&',
('alias_model_id', '!=', reply_model_id),
'|',
('alias_full_name', 'in', email_to_list),
'&', ('alias_name', 'in', email_to_localparts), ('alias_incoming_local', '=', True),
]
```
with test arguments, on a `mail.alias` table containing over 2M records.
| | Before | After |
|-----------|--------|-------|
| Timing | 696ms | 1ms |
| Buffer IO | 790MB | 48KB |
Specially impactful as those gains needs to be multiplied by the
frequency of the searches.
Reference:
task-3724844
closesodoo/odoo#156237
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
In some conditions, a x2many field can be considered
as modified by the webclient when in fact there is
no change in 'meaningful' stored fields.
In this case, on save, an empty list of magic commands
will be sent to the server, potentially triggering
unexpected recomputations.
Steps to reproduce:
* install sale_stock & sale_management
* create a new storable product
* create a new SO
* create a new line with this product
* Confirm the SO
* Set or Update the SO delivery date (Other info tab)
* Save
-> In the chatter, you will notice an useless tracking
value being printed for the SO Total, with identical values
before and after update.
Cause
Since the server received an empty list of commands for
the `order_line` field, this triggered a recomputation
of the total amounts of the SO, even though there were no
effective changes in the lines.
Solution
Do not send empty command lists for x2m fields.
This will avoid unexpected recomputation and also improve
performance since the fields were recomputed for 'nothing'
closesodoo/odoo#155549
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Current behavior:
When entering a difference at the closing of the session for a bank
payment method, the daily sales report was not taking into account the
difference for the bank payment method.
Steps to reproduce:
- Start PoS and make a sales with bank and a sales with cash
- Close the session with a difference for both payment methods
- Go to the daily sales report and check the difference for the bank
payment method. The one for the cash is there but not the one for the
bank.
Note:
This bring back the original behavior of the report that was removed
here (https://github.com/odoo/odoo/pull/146341) and makes it coexist
with the current one so that all cases are covered.
opw-3737223
closesodoo/odoo#156376
X-original-commit: d9190e34543c4a1151656859acb41556bcb3a364
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Current Behavior:
Traceback when printing the BOM overview.
Expected behavior:
Generates a PDF of the BOM overview even if the information displayed
is entirely relevant.
Steps to reproduce:
Inventory > Configuration > Products > Attributes
Create an attribute with Variants Creation Mode set to "Dynamically".
Create a new product with this single attribute and multiple values.
Create a BOM for this product with BOM Type set to "Subcontracting".
Print the BOM overview.
Cause of the issue:
Creating such a product generates a 'product.template' that is not
associated to any variant and hence does not correspond to any
'product.product'. As a result the function_get_bom_data made can not
apply the method _select_seller properly in that case.
Notes:
- There is no error if a variant was manually created for that product.
- If the Variants Creation Mode set to "Dynamically" a variant is still
automatically created to be associated to the product tempalte so
that the erro does not rise.
Fix:
As the _select_seller method is only defined for product.product
and not for product.template, we can not not apply it here.
Furhtermore, since the additional informations provided by the
override of the method get_bom_data in the the BOM overview will
not be relevant without the existence of a variant, we skip this part of
the code when the argument of _select_seller is not valid.
opw-3698050
closesodoo/odoo#156346
X-original-commit: b983026f004d4958d2a47a0dac9b1b54e24ab04c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Purpose
=======
Take the last expired contract end date if there is not open contract
for the related employee.
closesodoo/odoo#156326
Taskid: 3610709
X-original-commit: c6ddecc09361cde4580242dc4f87594e78e51a57
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create an attachment with an URL to a static file that does not exists,
e.g. '/web/static/idontexist.png'. Inside your browser try to access
that file, open <localhost:8069/web/static/idontexist.png>. The browser
fails with a "Too Many Redirections" error.
When a path is not found, nor in the static files, nor in the
controllers, `_serve_fallback` kicks in and attempt to find a resource
outside of the router that matches the URL. In case it finds an
attachment with a matching URL, it'll deliver it.
In this specific case, it finds our attachment and return a redirection
to it's URL, which is the same URL as the request hence it loops back.
Don't deliver URL attachments via `_serve_fallback`, only deliver stored
files.
closesodoo/odoo#156323
X-original-commit: d2bea592db6a66d531b83437d42b273606f629f1
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
A new message type was added in stable. This is usually safe,
however in cases where there are related fields on that same selection
fetching them will raise an exception as the ORM has to fetch the translations
for the selection in DB.
We add a hack on mail.mail to update the selections in DB when fetching
the message_type field for the first time.
task-3773301
closesodoo/odoo#156235
X-original-commit: 19683173708a2b029acb4e744871772b6c248715
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
ahmad(alah)