* = facturx, ubl, ubl_bis3, ubl_cii
Problem
---------
Currently, the EDI use the commercial partner to craft the XML document.
However, this causes issues when users add, for example, an invoice
address to a partner. Indeed, the address of the main partner will be
used and not the invoice address. This caused issue; see the relevant
OPW-3624205.
Objective
---------
Make sure that the correct address is used when generating the XML.
Solution
---------
Make sure the commercial partner // partner value is used at the correct
spot.
- `partner` should be used for addresses
- `commercial_partner` for everything else.
OPW-3624205
task-3636315
closesodoo/odoo#158219
X-original-commit: 95d3a5ac16c341acc4b680f19e404a9f2334b582
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Steps to reproduce the bug:
- Install the "Blogs" app and go to the "/blog" page.
- Click on "Edit" to enter edit mode.
- Go to the "Theme" tab.
- Select the 4th color from the theme colors and choose "black".
- Save the page to exit edit mode.
- Perform a search in the search bar input that yields no results, for
example: "zzz".
- Bug: The message "No results found. Please try another search." is not
visible because it is displayed in white on the white background of the
dropdown.
A previous commit [1] had already addressed the issue for the "Search"
snippet that can be dropped into a page, but this fix wasn't sufficient
to solve the problem everywhere. Indeed, the text-muted in a dropdown
should be adjusted in all cases and not just for snippets; it's a
Bootstrap issue. The text-muted color should be adapted to the
background color of the dropdown.
[1]: https://github.com/odoo/odoo/commit/f9bf40cb53cf487c8736c1f565c2f0d3834acd5e
task-3662985
closesodoo/odoo#158203
X-original-commit: 46fcb3712f0ba68144b03ed23f52157d4dfc789a
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit:
The snippet menu in the Mail Body appeared on the top of the form,
causing misalignment.
Technical details:
- This problem was observed in the `view_mail_mass_mailing_form` form and all
other views inheriting from it.
- The fix involves adding the `o_mass_mailing_iframe` class using the
`iframeHtmlClass` attribute on the body_arch field.
After this commit:
The layout is now aligned.
Task-3603623
closesodoo/odoo#158201
X-original-commit: 5b1d901014294274548765216ca4693501649ee9
Signed-off-by: Vivek Pathak (vivp) <vivp@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This will fix the number of employees in the partner view and redirect to a kanban view of the employees.
The smart button on the partner view for the number of employees related to this partner now gives the correct number depending on the companies selected.
If multiple employees are related, the action shows a kanban view of those employees.
closesodoo/odoo#158146
Task: 3693173
X-original-commit: c1e979203ec82de2300ad2f8b10478e1504b1c7c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Enter in edit mode.
- Select the 'Header' menu.
- Switch the default template to 'Rounded box menu'.
- Select again the 'Header' menu and on the 'Navbar' details, update the
format value (i.e: 10px) and save.
-> Problem: some buttons are not affected by the change of the format
value.
The problem is that since [1], those buttons have the `rounded-circle`
class so their font size is not the custom one (but it is the value of
`$font-size-base` instead). To solve the problem, the css rule has been
adapted in order to force the font size of the buttons inside the header
to the custom value if it exists.
[1]: https://github.com/odoo/odoo/commit/e3e9c492e0d1e009a0c459a1dc591e122b4b65d3
opw-3810794
closesodoo/odoo#158135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit sol name was not reflacting invoice
status when it moved to posted it only reflect draft
and cancel state.
This commit re-compute downpayment related sol name
when invoice related to that sol get posted this
way it'll update sol name to proper name instead of
keeping always Draft string in it.
opw-3768323
closesodoo/odoo#158094
X-original-commit: 40830f7e30ca8d84802088af17ade57f7b79998a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
Current behaviour before commit:
When trying to crop image in website, 'mousedown' and
'keydown' events are not getting caught. Due to this
- Crop is not getting closed when clicking on document
- Cropped image is not getting saved when pressing
enter
Desired behaviour after commit:
Now, events are added to the owner document of the
crop widget. As result,
- Crop gets closed when clicking anywhere in document
- Image gets saved when pressing enter.
task-3570524
closesodoo/odoo#158093
X-original-commit: afeba0d17a91d41ba2628524ccc03249835884b1
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Adnan Saiyed (adsa) <adsa@odoo.com>
This commit simply removes the table-responsive class from the pivot
view in desktop mode so that its eventual horizontal scrollbar will
remain inside the viewport instead of being positioned at the very
bottom of the page. Also hides the scrollbar in sample data mode so that
the user cannot scroll horizontally in this case which introduces weird
display.
closesodoo/odoo#158083
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
`_get_checkout_steps` didn't provide a friendly way to add steps in the
checkout flow. Developers had to reimplement part of the parent logic in
their overrides.
This commit introduces `get_checkout_step_list`. This method will allow
an easier override of the checkout steps while keeping the logic to
return a single step in the parent method.
closesodoo/odoo#158026
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Since [1] when the "Padding (Y, X)" option was added, form elements are
recognized as columns because they match the `.row > div` selector of
that new option.
This commit excludes those form elements from this option's selector.
Steps to reproduce:
- Drop a website form.
- Click on field's input.
=> An empty "Column" editor appeared in the side panel, and an error
occurred when trying to delete it.
[1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712
task-3748574
closesodoo/odoo#157572
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
When the user inserts a video with the `/video` command and provides a
link of an unlisted vimeo video, the system generates a new url based
on the options selected but omits the hash parameter granting access to
the given video. As a result, the video can not be loaded and the vimeo
`iframe` indicates that the video does not exist.
To fix the issue, we will copy the hash parameter from the original link
to the newly generated url. That way, the video will be loaded properly
and the user will be able to embed unlisted vimeo videos.
Steps to reproduce the issue:
1. Install the website app
2. Open the website builder
3. Drag and drop a text block
4. In the text block, type the `/video` command to insert a video
5. In the modal, paste the link of an unlisted video
6. The `iframe` indicates that the video does not exist
=> The system should extract the hash parameter from the provided url
and set it on the generated url. The video should then be loaded properly.
task-3697764
closesodoo/odoo#157279
X-original-commit: f72b873e58348374f3ce0e91ec5e87ed42215e55
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8
The following journals must have the following possible default account types:
- bank: asset_cash,
- cash: asset_cash,
- sale: income, income_other,
- purchase: expense, expense_depreciation, expense_direct_cost,
- general: all account types are possible,
The object of the task was mainly to allow misc journals to allow receivable or payable default account type for the following use case:
Suppose a user creates a Miscellaneous Journal to manage the details of the credit card statements.
Most journal entries will consist of journal items impacting the Payable Account, as this will reclassify the debt towards various vendors and address this debit to the credit card company.
It would in that case be necessary that the liquidity_payable accounts can be the default account on the miscellaneous journal. Otherwise, the user will have to fill in manually the account for each line of its credit card statement, and considering there can be a lot, this could become cumbersome.
task-3393017
closesodoo/odoo#157188
Signed-off-by: William André (wan) <wan@odoo.com>
With 17.0 the `mail.alias.domain` was introduced, allowing the
configuration of the bounce, catchall and default from email addresses
at the company level (`res_company`).
For this purpose, the `_compute_email_from` method was introduced to correctly
compute the `email_from` in various email contexts.
But, the `email_from` field in mass_mailing was using an obsolete combination
of `default=` and a compute method.
This meant that when one created a new `mailing.mailing` record, it was
always defaulting to `self.env.user.email_formatted`.
The compute was only triggered when the `mail_server_id` field manually
updated.
This is corrected with this fix and a unit test was added to test three
different use cases.
An invisible `create_uid` was added to the base mailing From view xml
to have the compute method trigger correctly in some unit tests.
How to reproduce bug:
See related github issue https://github.com/odoo/odoo/issues/151310
Behavior after this fix:
If `mail.alias.domain` is setup for the company and a default `ir.mail_server`
is configured for Email Marketing, `_compute_email_from` will select
the expected `email_from` at record creation for `mailing.mailing`.
opw-3704715
Fixes#151310
commit 4b5453d87498d32b0ec3e3e7d64d35f903ac2193
Author: jorv <jorv@odoo.com>
Date: Mon Mar 18 15:30:06 2024 +0100
[FIX] mass_mailing: precompute email_from based on alias domain
With 17.0 the `mail.alias.domain` was introduced, allowing the
configuration of the bounce, catchall and default from email addresses
at the company level (`res_company`).
For this purpose, the `_compute_email_from` method was introduced to correctly
compute the `email_from` in various email contexts.
But, the `email_from` field in mass_mailing was using an obsolete combination
of `default=` and a compute method.
This meant that when one created a new `mailing.mailing` record, it was
always defaulting to `self.env.user.email_formatted`.
The compute was only triggered when the `mail_server_id` field manually
updated.
This is corrected with this fix and a unit test was added to test three
different use cases.
An invisible `create_uid` was added to the base mailing From view xml
to have the compute method trigger correctly in some unit tests.
How to reproduce bug:
See related github issue https://github.com/odoo/odoo/issues/151310
Behavior after this fix:
If `mail.alias.domain` is setup for the company and a default `ir.mail_server`
is configured for Email Marketing, `_compute_email_from` will select
the expected `email_from` at record creation for `mailing.mailing`.
opw-3704715
Fixes#151310closesodoo/odoo#152655
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The process should not be triggered if a lock can't be acquired on
moves.
Also improve the error catching to be more readable.
Part-of: odoo/odoo#158035
The cron "send invoices automatically" was not properly using the
job_count parameter because the to_process invoices were now pulled from
a read_group. The limit parameter on read_group only limits the number
of groups and it was being grouped by company. This meant if there was
less than job_count number of companies this was not doing anything. And
if one company had a large amount of invoices this would time out and
repeat the same invoices the next time it was attempted because no
progress is saved until the batch is over.
Changing the read_group to a search.
opw-3765192
Part-of: odoo/odoo#158035
Some methods were using the `self.env` to decide users/partners while
those methods can also be called from Cron, thus the user would end up to
be OdooBot instead of the partner that initiated the async sending.
closesodoo/odoo#157991
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Before this commit, the aria-current was the name of the search_X
instead of value 'page'.
Code was strange since `'page' and X` == `X`, while we expect 'page' as
value.
In case of unknown 'search_slide_category' value, use '-' instead to
raise a KeyError Exception.
We still have some links that point to old url with slide category of
type 'presentation' that doesn't exist anymore since the v16.
Remove outdate code following the comment:
> I swear though, don't be afraid, remove it!
From this way, the wrong slide_type of type 'presentation' will be
ignored in all case and link from google will show the slide instead
of an error 500.
closesodoo/odoo#158002
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Starting from The "unbreakable menu fix" on `16.0` (see: [1]), the state
of the website extra menu was stored before every "resize" adaptation,
so it can be possible to reopen it if it was already opened.
On `17.0`, the same behaviour was fixed using the `odooEditor` >
`withoutRollback()` mechanism (see: [2]), and a step was added to the
`edit_menus` test (`clickOnExtraMenuItem`) to open the extra menu after
the "edit mode resize" [3].
The forward port of [1], on `17.0` was adapted to keep the main fix from
[2], and removed the tour step since the extra menu will be
automatically opened if it was already open before the "resize".
Now, if we have a menu with no overflowing items before the resize, and
after switching to "edit" mode an extra menu was added, this menu will
be closed by default which makes the test fail without the step in [3].
The goal of this commit is to fix this behaviour by simply restoring the
`clickOnExtraMenuItem` step with a simple tweak: We don't click if the
extra menu is already opened to prevent closing it again.
Remark: the test failed on `17.0` but the commit is targeting `16.0` to
prevent any test failure linked to the "extra menu auto open" feature.
[1]: https://github.com/odoo/odoo/commit/2598cc9ef7fe89a0ce5e375bca6f6a781f6ffdf7
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
Related to task-3439226
closesodoo/odoo#157290
X-original-commit: 42bcc3ef284ca355e2323641176573b53e7d2e28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
In the Quotations list view, it is possible to show "amount_to_invoice" field.
However, this field is empty for quotations and therefore useless.
It should be set as invisible for quotations.
An inherited view was already taking care of it, but was using "invisible"
attribute instead of "column_invisible" attribute.
opw-3722037
closesodoo/odoo#158043
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
With this commit, the domain of work location domain is reintroduced.
It was a mistake introduced by this PR : odoo/odoo#129308closesodoo/odoo#157580
X-original-commit: 94de3445f507c9c1801157c9526244ab91ceff0d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This adds a button to the AI Copywriter that allows the user to correct
the selected text without altering it otherwise.
task-3776377
closesodoo/odoo#156067
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
* Create a product tag (available on ecommerce)
* Select that filter on the /shop page
* Enter a search string
-> Traceback
The selected tag is given as a string to the
autocomplete route, and not a list of ids,
which fails when converted to an 'in' domain leaf.
`[('product_variant_ids.all_product_tag_ids', 'in', tags)]`
This commit makes sure to convert the given ids to a
list, correctly handled by the orm.
Fixes#155327closesodoo/odoo#155430
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
An error occurs when the user attempts to access a forecast report for the
replenishment product but does not receive the warehouse location ID
(archive/delete).
Steps to reproduce: (without demo data)
- Install "stock_account" module
- Inventory -> Operation -> Procurement -> Replenishment
- Create a new Replenishment product
- Configuration -> warehouse -> Archive warehouse records
- Go to a product made in the replenishment and click on forecast report
Traceback : "IndexError
list index out of range"
This commit will help to open a forecast report if the warehouse location is not
found.
sentry-4998176742
closesodoo/odoo#158017
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Have a list view with multiple groupbys and a lot of records to
have pagers displayed. Open a group (first level). The pager of the
group uses the number of records instead of number of (inner)
groups as total.
This commit fixes the issue. The pager now correctly allows to
navigate through inner groups.
closesodoo/odoo#157995
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
When an addon has an invalid version but is not installable,
there is no need to error out. This situation typically happens
when unmigrated modules are present in the addons path.
closesodoo/odoo#157657
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The pager was not getting the margin from the bottom. This commit fixes the
issue by providing the appropriate margin to the pager.
Task-3792586
closesodoo/odoo#157005
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Current behaviour:
When trying to preview a mailing template
with the debug mode enabled, there is an error:
Invalid props for component
Steps to reproduce:
1. Enable debug mode with assets
2. Go to Email Marketing
3. Create a new Mailing
4. Select a template
5. In the Editor, click on the mobile icon
6. ... 'preview' is not a function
Cause of the issue:
Caused by https://github.com/odoo/odoo/commit/13b3f8af4b55d32912b698ae1672be9e144cb775
opw-3702901
closesodoo/odoo#153176
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Description:
There is a discrepancy between the printed sale order report and the
customer preview when it comes to displaying the Payment Terms. On the
SO report, Odoo prints the 'note' field, whereas on the preview, Odoo
only displays the 'name' field.
Desired behavior after PR is merged:
Customer preview now matches the printed report by displaying the
payment_term.note field as well
opw-3790997
closesodoo/odoo#157926
X-original-commit: b25a119e8e3d4719a33bfbe69870f6f995488e6c
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Signed-off-by: Joel Bluemel (jobl) <jobl@odoo.com>
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings.
Steps to reproduce:
-------------------
* Go to the **Settings**
* Enable developper mode
* Select **User & Companies** > **Groups**
* Select `Technical/Analytic Accounting`
* Add user
* Go to the **Project** app
* Select **Configuration** > **Settings**
* Under **Time Management**, enable Timesheets
* Under **Analytics** > **Analytic Plan**, select Projects
* Create a new project
* Go into the settings of the project
* Under the **Settings** tab, select the internal link for the **Analytic Account**
> **Observation**: The Plan is set to Projects
* Go to **Conffiguration** > **Settings**
* Under **Analytics** > **Analytic Plan**, change Projects to Departments
* Create a new project
* Go into the settings of the project
* Under the **Settings** tab, select the internal link for the **Analytic Account**
> **Observation**: The Plan is still set to Projects
Why the fix:
------------
When creating, an analytic account, the plan is computed with `_get_all_plans()`.
https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/project_project.py#L894-L903
Inside `__get_all_plans()` the plan is computed as follows:
https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/analytic/models/analytic_plan.py#L106-L07
However, the setting that the user changes in the frontend corresponds to `analytic.analytic_plan_projects`.
https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/res_config_settings.py#L18-L22
This seeting is not company-related. It can be used on projects even if they have a `company_id` set to false. We fallback on `_get_all_plans()` if the user did not specifically choose a plan in the settings.
opw-3751661
closesodoo/odoo#157247
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Versions:
---------
- 17.0
Issue:
------
Message for flag timesheet from project as billable/non-billable
is misplaced.
Cause:
------
Xpath given for Message placed in sale_timsheet is not very specific.
Solution:
---------
Give accurate xpath for message div.
task-3630449
closesodoo/odoo#148880
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In SaaS, the DB is pre-prepared with the generic chart of accounts before the
new user finishes the form. Since the default country of the generic chart of
accounts is the US, then `set_tip_after_payment` option in the pre-created
pos.config is set to True. Now, when the form is submitted, the country is
identified but the said option remains to be True. This is a problem because not
all customers are creating an odoo instance for a US company. So customers from
other countries will have the option activated by default which is not a good
default for them.
We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in
this commit we won't set the option by default anymore.
closesodoo/odoo#149542
Task-id: 3635635
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
This PR introduces a new configuration parameter 'event.event_mail_async'
forcing registrations-based communication to be asynchronous. Instead of
directly sending communication it triggers the cron to be run as soon as
possible.
When having large volume of registrations, and especially concurrent
registrations it saves a DB to avoid generating tickets and preparing emails
synchronously to the registration creation.
Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3084943: Event: Improve communication scheduler scalability
closesodoo/odoo#155777
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, if we create a new event mail "after each registration" to be send
directly, the next time we confirm a registration it tries to send the
communication to all registrations that are not yet contacted. Indeed
the first new registration triggers the scheduler which runs on all
pending registrations. This may potentially break the transaction or
at least make it extra slow.
Now, we send the mail only to the new registrations (created after the
event mail). Old registrations will be contacted via the CRON instead.
Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155777
Co-authored-by: Stéphane Debauche <std@odoo.com>
Various registration side updates depends on its state: notably communication
schedulers and lead rules management.
However event_sale changes the 'state' field from a classic selection field
to a computed one, introducing links with sale order and sale order lines
as well as payment state computation.
Currently code leads to a double update of state when creating a new
registration, which causes communication scheduler to be called twice and
create additional queries. This commit tries to avoid this by updating value
of state only once, instead of setting everything to draft then updating to
another value afterwards. This avoids notably schedulers to be triggered
or called twice in the same transaction.
Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155777
This commit introduces a new configuration parameter 'event.event_mail_async'
forcing registrations-based communication to be asynchronous. Instead of
directly sending communication it triggers the cron to be run as soon as
possible.
When having large volume of registrations, and especially concurrent
registrations it saves a DB to avoid generating tickets and preparing emails
synchronously to the registration creation.
Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155777
Issue:
======
When you update the link button label from the sidebar it loses its
style.
Steps to reproduce the issue:
=============================
- Got to website editor
- Insert a text block
- Added a button in the text block and any label
- Click on the button to edit it from the sidebar
- Change font size or font color or any style you want
- Update the label
- The style is lost
Origin of the issue:
====================
When updating the label, we search for the first child that has that
text, but when we have `ZWS start` it will be considered as the first
child and then we update the inner text of the `a` element so we loose
the span of the text which has the custom styles.
Solution:
=========
We search for the first child which is not `ZWS`
task-3721686
closesodoo/odoo#157758
X-original-commit: 999d5787e3d8d0518692f987341dd6b298d7ffc4
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
**Current behavior:**
When making a new RFQ, dropship is not an available selection
for the 'Deliver To' option.
**Expected behavior:**
As on previous versions, you should 'dropship' should be
selectable here which reveals a sub-selection to select the
customer who should receive the shipment.
**Steps to reproduce:**
1. Enable `Dropshipping` in Purchase settings as well as
`Storage Locations` in Inventory settings
2. Create a new RFQ, observe that in the 'Deliver To' dropdown
there is no way to select a dropship option
**Cause of the issue:**
Dropshipping was made into a discrete `stock.picking.type`.code
and the domain that constrains the selection menu options is not
modified to accomodate this change.
**Fix:**
Update the domain to show picking types that have the dropship
code.
opw-3764617
closesodoo/odoo#157548
X-original-commit: 3ea6e552bde90533f983689d786fee219e0e61ce
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Before this commit, the `test_websocket_instances_weak_set` was
sometimes failing. Indeed, this test doesn't wait for the connection
to be fully established before making its assertions. This commit
fixes this issue.
fixes runbot-55037,55035
closesodoo/odoo#157510
X-original-commit: 15bad5ccbeced41127eeaea3e47eebbc3f55091e
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Before this commit:
IoT logs are kept in an IoT log file.
Any time the support would need IoT log information, we are forced to
ask the customer to send it to us as it requires to be in the LAN.
After this commit:
Relevant* log lines will be automatically send out to the server using
an HTTP route.
This feature can be toggled within the Handlers list page
* Relevant =
- Any odoo logs (depending on the level set in the handlers list, see:
https://github.com/odoo/odoo/pull/134174 )
- Any other logs (werkzeug, python libraries, etc.) except /hw_proxy/hello
Note: IoT logs received by the server will ALWAYS be logged regardless
of it level. So an Odoo server set in INFO which receive a DEBUG log
from the IoT will log it in its log with the DEBUG level
opw-3696519
closesodoo/odoo#156605
X-original-commit: 9f35fcd63d0a8a833b8b47e80084e5baccdcfb72
Related: odoo/enterprise#58111
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
When configuring a Newsletter Block snippet to display a subscription
form, the option to decide whether a message must be displayed is only
available when "On Success" is set to "Show Message" through the button
beside that option.
Unfortunately, the general option for the "Thanks" message is not
disabled for other "On Success" values, for which no outcome can display
a message. Trying to combine these triggered an error.
This commit fixes this problem by hiding the "Display Thanks Button"
option when the "Form Subscription" template is selected.
Steps to produce:
- Install `website_mass_mailing`.
- Drop a "Newsletter Block" snippet.
- Change template to "Form Subscription".
- Click on "Subscribe" button.
- Change "On Success" to "Nothing".
- Click on "Display Thanks Button".
=> An error was displayed.
task-3748574
closesodoo/odoo#157739
X-original-commit: b090d68894fb96a73df230e021e516e6df22f40e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Previously, users were required to enter their PAN number even after manually
inputting their GSTIN, even though the PAN is inherently part of the
GSTIN (spanning from the 3rd to the 12th character). Furthermore, there was
no mechanism to alert users if the manually entered PAN did not match the PAN
segment within the GSTIN.
This commit automates the filling of the PAN based on the entered GSTIN. Now
upon entering a GSTIN, the corresponding PAN is auto-filled.
task-3767627
closesodoo/odoo#157689
X-original-commit: ffd2274498f1fbf0205e60f1b125134e4fede16e
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Earth Patel (eapa) <eapa@odoo.com>
__Current behavior before commit:__
When a sheet is deleted, `charts` from `OdooChartCorePlugin` are not
being updated.
Therefore, since the commit [`905d856`][1], `getOdooChartIds` returns
some chart ids that do not exist on any sheet anymore.
This induces a crash when opening a spreadsheet that contains such
charts.
__Description of the fix:__
Handle `DELETE_SHEET` event in `OdooChartCorePlugin` by removing Odoo
charts that don't belong to any sheet.
__Steps to reproduce the issue on runbot:__
- Insert a Odoo graph inside a spreadsheet (starting from any app)
- Add a sheet to it to the new spreadsheet
- Delete the sheet that contains the chart
- Leave the spreadsheet
- Go to Documents app and try to open the spreadsheet
-> Traceback
opw-3783745
[1]: https://github.com/odoo/odoo/commit/905d8565ad2fae3f7ff96606352ee3ab86ee78cbclosesodoo/odoo#157847
X-original-commit: d44c45234577d19a728e92368f224b0e0e59e853
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
-Step to reproduce: any custom model that inherit from mail.thread then
define a field user_id but with type is char and boom error happen at
method '_message_get_suggested_recipients' because it always expect
'user_id' to be a many2one field
closesodoo/odoo#157942
-solution: need to check the type of 'user_id' also
X-original-commit: 4aaab353da1c1ddde63f2aa1232394c0b4dd6f68
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Antoine Boonen