Friday, June 24, 2022
72 changes · master
Enhancements to existing features
This update removes unused chatbot-related code from the live chat area. It helps keep the system easier to maintain without changing the experience for users or customers.
Original PR description
Task-2891941
The live chat chatbot can now use dedicated welcome steps to start conversations more smoothly. This helps website visitors receive clearer initial guidance and gives businesses a more controlled first interaction in live chat.
Original PR description
*: website_livechat Task-2891987
Live chat internals were updated to make the chat button behavior and chatbot test mode easier to configure. This helps future website live chat changes be added more consistently with limited direct impact on end users.
Original PR description
*: website_livechat This will allow for newly introduced fields to be quite declarative immediately. Task-2892011
Live Chat and Website Live Chat were updated to make new chat button and chatbot test data easier to define and reuse. This supports faster, more consistent rollout of future live chat behavior without changing the customer-facing experience immediately.
Original PR description
*: website_livechat This will allow for newly introduced fields to be quite declarative immediately. Task-2892034
The live chat module now organizes button display and chatbot state handling in a clearer way. This makes it easier to add and manage future live chat options while keeping the customer-facing experience stable.
Original PR description
This will allow for newly introduced fields to be quite declarative immediately. Task-2892041
Live chat conversations can now display a dedicated chatbot name, making automated responses clearer and more personable for website visitors. This helps businesses present a more polished support experience and distinguish bot messages from other live chat interactions.
Original PR description
Task-2891910
The live chat system now uses a dedicated chatbot model and cleaner button state handling, including support for test chatbot data. This makes chatbot behavior easier to manage and helps improve reliability for website live chat experiences.
Original PR description
Task-2891904
Live chat now better tracks the chatbot's last welcome step, helping conversations start more consistently for website visitors. This should make automated chat greetings smoother and reduce confusion when users interact with the chat widget.
Original PR description
Task-2892000
This update improves how the website live chat button connects to its chat channel. It helps make the live chat experience more reliable and easier to maintain without changing the visible workflow for visitors.
Original PR description
Task-2891875
The live chat button now determines chatbot behavior through clearer stored settings instead of scattered logic. This makes chatbot display and testing behavior more consistent across website live chat experiences, reducing maintenance risk while preserving the user-facing flow.
Original PR description
Task-2892067
The live chat module now supports defining new button and session-related settings more directly. This makes future improvements, such as chatbot state handling, easier to add and maintain without changing the customer-facing experience immediately.
Original PR description
This allows defining some new fields immediately in a declarative way, such as `LivechatButtonView/chatbotState` Task-2892083
This update makes the live chat button easier to configure internally, allowing new live chat fields to be defined more quickly and consistently. It supports future enhancements such as chatbot state handling while keeping the visible customer experience largely unchanged.
Original PR description
This allows defining some new fields immediately in a declarative way, such as `LivechatButtonView/chatbotState` Task-2892092
Live chat now manages chatbot-related session and test data in a more consistent, declarative way. This should make the chat button behavior easier to maintain and more reliable across website live chat scenarios, without changing the user-facing workflow.
Original PR description
Task-2892074
Live chat chatbots now have a clearer model for controlling message timing, including delays between chatbot messages. This improves the visitor chat experience by making automated conversations feel more natural and easier to test and maintain.
Original PR description
Task-2892596
The live chat chatbot code has been reorganized around clearer chatbot and chatbot step data models. This makes chatbot behavior easier to maintain and test, supporting more reliable customer conversations on websites.
Original PR description
*: website_livechat Task-2892283
Website management and editing now run inside the main Odoo backend through an embedded website preview. This gives users a more consistent experience across Odoo apps, improves mobile preview/editing, and reduces disruptions when navigating or reloading website pages.
This update prepares the live chat area for a gradual modernization of its underlying interface code. It helps keep existing live chat behavior working while the system transitions to newer components, reducing migration risk without changing the customer-facing experience.
Original PR description
So that models can introduce models, that rely on legacy widgets while code is being converted fully to using models and components Task-2892617
The test setup for chatter features now opens real form views in the web client instead of using a simplified helper. This improves confidence in mail and eLearning behavior and helps unblock related development work without changing end-user functionality.
Original PR description
The createChatterContainer helper was used during tests to mount a chatter container and test it. However, this approach is not very realistic and blocks some waiting PRs. In order to get closer from the reality, let's mount a webClient and open a form view containing a chatter. enterprise: https://github.com/odoo/enterprise/pull/28684
The mail settings interface now gives users clearer guidance about what allowed mail gateway models do and which system setting they affect. The list view is simplified by removing a technical normalized email field and renaming the email label, making the screen easier to understand.
Original PR description
Purpose ======= Add an action helper that explain what does the model and with which system parameter it interacts. Remove the normalized email from the list view and rename the label of the email field. Task-2885455
Survey results now make it easier to see whether answers are correct, incorrect, or skipped, including for date, datetime, and number questions. Scoring fields are only shown when relevant, and missing required scored answers are flagged earlier when saving the question, reducing setup mistakes.
Original PR description
PURPOSE We are able to add scoring for date, datetime and integer question types. The way results are displayed can be improved, that's the main purpose of this PR. Current 1) There is no correct answer displayed on answer page. 2) Input field for point is visible whether score is checked or not. To be 1) Show correct answer For date,datetime and integer in the result page (and also for live survey): 2) Display the input for the score only if score is checked. 3) Trigger the warning "All "Is a scored question = True" and "Question Type: Date" questions need an answer" on the "Save" of the question, not the survey itself. Same way we trigger the missing title:(make it mandatory if score is checked) LINKS PR Task 2276724 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Salesperson and sales team details are now kept consistent between individual contacts and their linked parent companies. This helps ensure portal users see the right person responsible for handling their process, even when contacts and companies are created or linked in different ways.
Original PR description
PURPOSE The Salesperson and sales team values should be set on the individual partner and the parent company if the parent company is linked with an individual partner. This salesperson will display…
PURPOSE The Salesperson and sales team values should be set on the individual partner and the parent company if the parent company is linked with an individual partner. This salesperson will display on the portal to show who will handle the process. SPECIFICATIONS The Salesperson and sales team are set on contact/partner form view. This salesperson is showing on the portal view(website). This value shows who will handle the process. No contact will show on the portal if the salesperson is not set on individual contact/partner. With this commit, we have done two points. 1) If salesperson and sales team values are set on individual contact/partner, pass these values to a parent company which is created from here(individual contact/partner). 2) If the parent company is manually linked to an individual partner and the salesperson and sales team are not set on an individual, these values are getting from the parent company and set on individual contact/partner. This is the goal of this commit. PR #78696 Task-2636290 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the web interface framework used by Odoo, fixing several issues that could cause crashes or incorrect behavior in interface components. It also brings small performance improvements and better support for UI templates, helping make the web experience more stable for users.
Original PR description
Note: this PR is a manual forward port. The original PR are: - in saas-15.3 => https://github.com/odoo/odoo/pull/94249 - in saas-15.4 => https://github.com/odoo/odoo/pull/94407 Release notes:…
Note: this PR is a manual forward port. The original PR are:
- in saas-15.3 => https://github.com/odoo/odoo/pull/94249
- in saas-15.4 => https://github.com/odoo/odoo/pull/94407
Release notes:
https://github.com/odoo/owl/releases/tag/v2.0.0-beta-9
https://github.com/odoo/owl/releases/tag/v2.0.0-beta-10
Details:
Fix: event: no crash when using t-on + modifier on slots/components
Fix: component: fix props comparison code
Fix: component: fix wrong behaviour when using t-on on t-component
Fix: component: props values are own property of props object
Fix: t-out: allow expressions evaluating as number
Fix: compiler: add support for #{...} in string interpolation
Fix: compiler: escape backticks in attributes
Fix: crash when dynamic class have leading space
Imp: slots: add support for t-props on slots props
Imp: tooling: add another d.ts file
Imp: app: small scale perf improvement
Imp: app: add fast path for when component has no prop
Imp: validation: add support for value types
Imp: add support for t-call-context
Ref: compiler: remove useless ; in compiled output
Ref: move some code around
X-original-commit: 3c7e2cb5a2224ff624e0899ca392be8b3828b43a
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prDemo sales orders using timesheets now create a single related project instead of duplicate projects. This keeps sample data simpler and more realistic, making demonstrations and testing easier to understand.
Original PR description
Since 12bc2ab, there are two projects created for each SO instead of one in the demo data. This is because in the sale lines, one product creates a project with a template, but others create a project without a template, which creates two projects. This PR adds a project template to the products without one to create a single project per SO.
Recruitment reports were updated to make their labels and data easier to understand, especially by reducing confusion between applicant source and medium. This helps teams interpret hiring performance more accurately and make better decisions from their reports.
Original PR description
This commit aims to improve the recruitment reports clarity, particularly the confusion between source and medium TaskID : 2837445
Mail component tests now run in an environment closer to real user usage by mounting the full web client instead of a simplified test helper. This improves confidence in future mail changes and helps unblock related development work without directly changing user-facing features.
Original PR description
The createMessageComponent helper was used during tests to mount a message component and test it. However, this approach is not very realistic and blocks some waiting PRs. In order to get closer from the reality, let's mount a webClient so that the message component can be mounted in its real environment. enterprise: https://github.com/odoo/enterprise/pull/28720
The CRM app can now generate sample leads for performance and volume testing. This helps teams validate how CRM behaves with large numbers of leads before real-world usage grows.
The appraisal goals interface now makes it easier for employees and managers to monitor progress and deadlines. Completed goals are clearer to identify, and a new visual progress view supports better follow-up during appraisal cycles.
Original PR description
This commit adds: - progression and deadline tracking - a banner on the completed goals form - a graph view on goals progression taskID 2868693
Testing for enterprise mail message attachments now runs in an environment closer to how users actually experience the application. This reduces the risk of test-only behavior and helps unblock related improvements without changing day-to-day functionality.
Original PR description
The createMessageComponent helper was used during tests to mount a message component and test it. However, this approach is not very realistic and blocks some waiting PRs. In order to get closer from the reality, let's mount a webClient so that the message component can be mounted in its real environment. community: https://github.com/odoo/odoo/pull/94243
Odoo Social now shows users how close a Twitter post is to the 280-character limit before publishing. Posts that are too long are highlighted and blocked from being saved, reducing failed publishing attempts and user frustration.
Original PR description
Before This PR: While posting a message on Twitter, even though it has some character limit, we can still create a long message which eventually crashes on posting. The 'Retry' button which appears…
Before This PR: While posting a message on Twitter, even though it has some character limit, we can still create a long message which eventually crashes on posting. The 'Retry' button which appears after thus crashing of the post has no use then. So the goal of our commit is to limit the message length and prevent it from sudden posting failure due to character limits issues. After This PR: -Twitter post max length as per its documentation is 280 characters, where standard alphabets and space carry a weight of 1 and as well as emojis and new lines carry a weight of 1. This is now taken into account. -Under the 'message' field we have added a read-only text which indicates the current length out of total characters to be fit in the Tweet we are posting. -If the message length is beyond the max-length we have set, the count the sentence will be highlighted as a warning, -If one tries to post a Tweet with more than the max-length, a user error is threw to limit the characters. Task: https://www.odoo.com/web#id=2517821&menu_id=4720&cids=2&model=project.task&view_type=form
Recruitment reports were updated to make applicant source and medium information easier to understand. This reduces confusion when reviewing hiring performance and helps teams interpret recruitment channels more accurately.
Original PR description
This commit aims to improve the recruitment reports clarity, particularly the confusion between source and medium TaskID : 2837445
This update improves how VoIP connections identify users during sign-in, especially for OnSIP-based phone services. It helps ensure calls connect more reliably when the login name differs from the visible VoIP username, while removing outdated setup code that is no longer needed.
Original PR description
Part of task-2804807.
This update brings the embedded spreadsheet engine up to its latest version. Users benefit from improved chart support, new date-related spreadsheet functions, and fixes that make spreadsheet layouts behave more reliably around headers, hidden rows, columns, and figures.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f4511b6f [IMP] spreadsheet: export chart stuff https://github.com/odoo/o-spreadsheet/commit/690584fb [FIX] xml: escape…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f4511b6f [IMP] spreadsheet: export chart stuff https://github.com/odoo/o-spreadsheet/commit/690584fb [FIX] xml: escape chars in regex https://github.com/odoo/o-spreadsheet/commit/be1c78c1 [IMP] Functions: Add several date related functions https://github.com/odoo/o-spreadsheet/commit/cb557f1b [IMP] spreadsheet: export some utilities https://github.com/odoo/o-spreadsheet/commit/b88a5fac [FIX] Figure container: Crop figures to avoid overlap with headers https://github.com/odoo/o-spreadsheet/commit/9e12eaee [FIX] SheetPlugin: clear hidden cols/rows references in plugin https://github.com/odoo/o-spreadsheet/commit/ad019c5a [REF] Header Sizes: rename internal variable https://github.com/odoo/o-spreadsheet/commit/521c9b04 [REF] viewport: merge viewport and snapped viewport https://github.com/odoo/o-spreadsheet/commit/aa18b44e [FIX] header sizes: some small fixes https://github.com/odoo/o-spreadsheet/commit/8e11dd74 [REF] sheet: move header visibility out of sheet plugin https://github.com/odoo/o-spreadsheet/commit/108d337f [REF] sheet: put header size in its own plugin
Website editing tools and related menus are being moved from the public website interface into the Odoo backend. This makes content creation, appointment setup, media selection, and customization more consistent across apps while cleaning up older website editing assets.
Original PR description
*: planning, web_studio, website_appointment, website_helpdesk, website_sale_renting, website_sale_renting_comparison, website_sale_renting_wishlist, website_sale_stock_renting, website_twitter_wall See community counterpart for more details. task-2687506 Related: https://github.com/odoo/odoo/pull/89223 Related: https://github.com/odoo/design-themes/pull/572 Related: https://github.com/odoo/upgrade/pull/3464 Co-authored-by: Younn Olivier <yol@odoo.com> Co-authored-by: Arthur Detroux <ard@odoo.com> Co-authored-by: Mehdi Outagant <mou@odoo.com> Co-authored-by: Benjamin Vray <bvr@odoo.com>
The test setup for chatter-related features now uses a fuller application flow instead of a simplified test-only container. This helps make automated testing closer to real user behavior and reduces the risk of future changes being blocked by unrealistic test assumptions.
Original PR description
*: account_invoice_extract, approvals, voip. The createChatterContainer helper was used during tests to mount a chatter container and test it. However, this approach is not very realistic and blocks some waiting PRs. In order to get closer from the reality, let's mount a webClient and open a form view containing a chatter. community: https://github.com/odoo/odoo/pull/94175
Odoo Studio now lets users choose the field used to consolidate Gantt views when setting up consolidated planning views. This makes it easier for businesses to build meaningful workload or capacity summaries directly in Studio, while avoiding unsuitable fields like record IDs.
Original PR description
TASK:- https://www.odoo.com/web#view_type=form&model=project.task&id=40680&active_id=40680 PAD:- https://pad.odoo.com/p/r.4a8172a3a7c3fa59ebefc2fb6c649ab5 When a type of gantt view is 'consolidate', we need to set an extra attribute named 'consolidation'. Using studio, we were able to set the type of a gantt view, but could not set consolidation attribute in case of consolidated gantt view. This commit adds an option to choose the consolidation attribute from supported field types (integer, float or monetary). ID filed is excluded from the supported fields as it doesn't make sense to see a gantt consolidated by ID. Task: #40680
Internal users who create helpdesk tickets will now receive email links that take them to the backend when they have the right access. This helps staff reach the fuller ticket view faster, instead of landing on a limited customer-facing page.
Original PR description
Purpose ======= When an internal user creates a helpdesk ticket, they will get a link by email to the front end which does not contain a lot of information. If the user is part of the group_helpdesk_user group Task-2680414
Resolved issues and error corrections
The contract history report now displays the salary agreed at signature instead of a holiday-adjusted wage value. This prevents misleading salary information in HR records and helps users review contract history accurately.
Original PR description
task - 2879965
Features or functions removed from Odoo
The recruitment skills module no longer includes the Populate feature that was previously introduced. This removes related setup, access rules, and user interface elements, helping keep the recruitment workflow aligned with the intended product scope.
Original PR description
Partial revert of #93126. TaskID: 2894671
Code cleanup and technical improvements
The public live chat experience is being modernized to use the same underlying structure as Odoo Discuss. This helps make future live chat improvements easier to deliver and maintain, with minimal immediate change expected for end users.
Original PR description
*: website_livechat This commit is a step towards refactoring the JS of public livechat, so that it reuses the same architecture as the code of Discuss. This implies code that uses JS models and OWL components. Task-2894102
Miscellaneous changes
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.0-beta-9 https://github.com/odoo/owl/releases/tag/v2.0.0-beta-10 Details: fix: event: no crash when using t-on + modifier on slots/components fix: component: fix props comparison code fix: component: fix wrong behaviour when using t-on on t-component fix: component: props values are own property of props object fix: t-out: allow expressions evaluating as number fix: compiler: add support for #{...} in string interpolation
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.0-beta-9 https://github.com/odoo/owl/releases/tag/v2.0.0-beta-10 Details: fix: event: no crash when using t-on + modifier on…
Release notes:
https://github.com/odoo/owl/releases/tag/v2.0.0-beta-9
https://github.com/odoo/owl/releases/tag/v2.0.0-beta-10
Details:
fix: event: no crash when using t-on + modifier on slots/components
fix: component: fix props comparison code
fix: component: fix wrong behaviour when using t-on on t-component
fix: component: props values are own property of props object
fix: t-out: allow expressions evaluating as number
fix: compiler: add support for #{...} in string interpolation
imp: slots: add support for t-props on slots props
imp: tooling: add another d.ts file
ref: compiler: remove useless ; in compiled output
ref: move some code around
imp: app: small scale perf improvement
imp: app: add fast path for when component has no prop
imp: validation: add support for value types
fix: compiler: escape backticks in attributes
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#94249Original PR description
*: auth_signup, knowledge, mass_mailing, portal, survey, test_website, test_website_modules, test_website_slides_full, web, web_editor, web_tour, web_unsplash, website_blog, website_crm,…
*: auth_signup, knowledge, mass_mailing, portal, survey, test_website, test_website_modules, test_website_slides_full, web, web_editor, web_tour, web_unsplash, website_blog, website_crm, website_crm_partner_assign, website_customer, website_event, website_event_exhibitor, website_event_meet, website_event_track, website_forum, website_hr_recruitment, website_knowledge, website_links, website_livechat, website_mail_group, website_mass_mailing, website_membership, website_sale, website_sale_autocomplete, website_sale_comparison, website_sale_loyalty, website_sale_slides, website_sale_wishlist, website_slides, website_slides_forum, website_twitter, base A new client action is introduced, to display the website in an iframe. This allows to remove the "frontend" Odoo UI entirely. Everything related to the website configuration (and especially the edit mode) will now be done on the backend side. The idea behind this mainly comes from the fact that we needed the website in an iframe during edition to be able to render a mobile preview properly. It was also required so that options which reloads the page... are able to only reload the page and not the entire editor with it. From there, it was decided that actually, since the website is in an iframe, it could be in the backend and every website UI could rely on this. In the end, this comes with many functional and technical advantages. Here are some of them (a few of them are not entirely done with this merge but will follow the merge in the upcoming weeks, see this as a non-exhaustive list of possibilities that are unlocked by this work): Technical: - No duplicated logic for website UI and backend (purple navbar is the backend one, slightly customized). - No conflicting logic for website UI and website content (like dialog opening, ...). - No forced CSS for our website / web_editor UI, no conflict with website themes. - Everything converted in OWL, in backend code (no special OWL for frontend). - "Legacy" code moved as frontend code or removed. - No website content CSS for the case "when there is the Odoo purple navbar at the top". - Backend views & features available (e.g. creating a new event -> form view instead of custom code with onchanges, validations, etc) Functional: - All website features available while editing your website (product configuration, settings, etc), no switch backend/frontend, no redirection, no reload (just the iframe). - All other app features available while editing your website (discuss, calendar, all other apps, ...). - Typing a website URL in your browser reaches your website (very small Odoo UI overlay at the top left as a connected user). - Mobile preview: directly resizing the website rendering, in edit mode too and with a better phone image. - Editor: mobile view edition (the editor is instanciated around the website content instead of inside of it (iframe)) - Can reload the website without reloading all the tools (editor, html editor, menu edition, etc) (customize_show options for instance -> moved as standard editor options which reloads the website only) - Website UI in your language instead of website language On the backend side, some customizations were done so that the UI feels like it works as before (note that it will be reworked in upcoming weeks): - A `website_systray` registry is defined to replace the systray items with the website's one when previewing the website. - The webclient's navbar is patched to display additional dropdown menus related to the website edition. - A website service that holds the global state of the website is introduced. Components from the systray and the dropdown menus can access and modify it. - A component adapter for the wysiwyg (that will display the snippets menu) is added, that allows for caching the wysiwyg libraries, thus improving editions responsiveness. See sub-commits for details. This work is known to not be bug-free and will be bug-fixed, improved and reworked in the upcoming weeks. task-2687506 Related: https://github.com/odoo/enterprise/pull/28448 Related: https://github.com/odoo/design-themes/pull/572 Related: https://github.com/odoo/upgrade/pull/3464 Thanks to the whole team for reviewing and testing ! (ARD, BVR, BSO, GDI, MOU, PDE, QSM, RDE, SOBO, YOL) Co-authored-by: Younn Olivier <yol@odoo.com> Co-authored-by: Arthur Detroux <ard@odoo.com> Co-authored-by: Mehdi Outagant <mou@odoo.com> Co-authored-by: Benjamin Vray <bvr@odoo.com>
This fixes a problem where people opening Sign documents from email could see the signing page without the expected translations. The Sign app now passes the recipient's language preference correctly, so the signing experience appears in the right language when multiple languages are enabled.
Original PR description
Context: In commit [00e6b87c9d16af1bfb3e63b9b857fbaad90e620a](https://github.com/odoo/odoo/commit/00e6b87c9d16af1bfb3e63b9b857fbaad90e620a) the deletion of some code created a bug in the sign app…
Context: In commit [00e6b87c9d16af1bfb3e63b9b857fbaad90e620a](https://github.com/odoo/odoo/commit/00e6b87c9d16af1bfb3e63b9b857fbaad90e620a) the deletion of some code created a bug in the sign app where the language is set in the html_data and the frontend translations were hence broken. In the stable versions this commit was revert see PR https://github.com/odoo/odoo/pull/90757. On master we make a cleaner fix and find a solution solution in the sign module. By creating the get_frontend_session_info_sign we add the lang to the user_context and we don't need to extract it from the html attributes. We also remove the deprecated xml line of the first fix commit https://github.com/odoo/enterprise/commit/7d59eb832d727522fc3b4639634c377e66ce3c59 that are now irelevant as we don't use the html_data anymore. A recent fix was merged concerning a close but different issue regarding translations in the sign frontend https://github.com/odoo/odoo/commit/2b080ddbd8f332299b2343fa5ca0e0061b0ad554, but this issue fixes the specific case of only one language (that is not ENG) activated. While here we solve the issue where there are multiple languages and the client that receives the email to sign the document should have, when he clicks on the document link, the translations in the language set in its preferences. opw-2777044
- Currently, constraints _check_payment_mode only applied on expense sheet, we also need to check when changing payment_mode on dividual expense. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93772
Original PR description
- Currently, constraints _check_payment_mode only applied on expense sheet, we also need to check when changing payment_mode on dividual expense. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93772
The string concatenation would fail on False help_message. Closes #93036 Forward-Port-Of: odoo/odoo#94428
Original PR description
The string concatenation would fail on False help_message. Closes #93036 Forward-Port-Of: odoo/odoo#94428
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94386
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94386
revert of https://github.com/odoo/odoo/pull/91209 Steps: - Go to CRM, kanban view - click on "Planned" button - click on "Mark as done" button - click on "Write Feedback" textarea The activity dropdown disappears immediatly opw-2884875 Forward-Port-Of: odoo/odoo#94393
Original PR description
revert of https://github.com/odoo/odoo/pull/91209
Steps:
- Go to CRM, kanban view
- click on "Planned" button
- click on "Mark as done" button
- click on "Write Feedback" textarea
The activity dropdown disappears immediatly
opw-2884875
Forward-Port-Of: odoo/odoo#94393Steps to reproduce the bug: - Let's consider a project P with a task T - P has has two stages S1 and S2 - From T, create a new sub task ST1 with a new stage S3 - From T, create an other new sub task ST2 and try to select S3 as stage Bug: ST3 was not displayed in the available stages Fix: The stage ST3 is available for every task or sub task opw:2873640 Forward-Port-Of: odoo/odoo#94399 Forward-Port-Of: odoo/odoo#93548
Original PR description
Steps to reproduce the bug: - Let's consider a project P with a task T - P has has two stages S1 and S2 - From T, create a new sub task ST1 with a new stage S3 - From T, create an other new sub task ST2 and try to select S3 as stage Bug: ST3 was not displayed in the available stages Fix: The stage ST3 is available for every task or sub task opw:2873640 Forward-Port-Of: odoo/odoo#94399 Forward-Port-Of: odoo/odoo#93548
In the `_stock_account_prepare_anglo_saxon_in_lines_vals` method, we loop the moves' invoice lines but we called `filtered` on it to remove ineligible lines. That said, we have a conditional `continue` at the beginning of the loop precisely for the same reason, which is redundant. As it's better to filter out inside a loop instead of call `filtered` (one loop instead of two), this commit removes the call to `filtered`. Forward-Port-Of: odoo/odoo#93779 Forward-Port-Of: odoo/odoo#89149
Original PR description
In the `_stock_account_prepare_anglo_saxon_in_lines_vals` method, we loop the moves' invoice lines but we called `filtered` on it to remove ineligible lines. That said, we have a conditional `continue` at the beginning of the loop precisely for the same reason, which is redundant. As it's better to filter out inside a loop instead of call `filtered` (one loop instead of two), this commit removes the call to `filtered`. Forward-Port-Of: odoo/odoo#93779 Forward-Port-Of: odoo/odoo#89149
Steps to Reproduce: - Connect as Admin - Install event_booth_sale module - Give only sales right to Demo user (get rid of everything else (especially event) - Connect as Demo - Create a new SO - Add an event_booth as product to the SO - Try to confirm the SO Issue: Access error. Cause: When confirming the SO, we also update the selected event_booth while the sales right are not enough to update event_booth model. Solution: Use sudo to update
Original PR description
Steps to Reproduce:
- Connect as Admin
- Install event_booth_sale module
- Give only sales right to Demo user
(get rid of everything else (especially event)
- Connect as Demo
- Create a new SO
- Add an event_booth as product to the SO
- Try to confirm the SO
Issue:
Access error.
Cause:
When confirming the SO, we also update the selected event_booth
while the sales right are not enough to update event_booth model.
Solution:
Use sudo to update event_booth, since SO already confirmed.
Also fix unlink of booth, for the same reason.
opw-2823555
Task-2842621
Forward-Port-Of: odoo/odoo#93983
Forward-Port-Of: odoo/odoo#88914Purpose ======= The flow where we copy / paste the authorization code will be depreciated. Because of that, we now use the newest authentication system which uses redirect URI. Task-2852560 Forward-Port-Of: odoo/odoo#94411 Forward-Port-Of: odoo/odoo#91282
Original PR description
Purpose ======= The flow where we copy / paste the authorization code will be depreciated. Because of that, we now use the newest authentication system which uses redirect URI. Task-2852560 Forward-Port-Of: odoo/odoo#94411 Forward-Port-Of: odoo/odoo#91282
This PR introduces a node option `keydown_debounce_delay` on the character field and on emoji mixin, so that user can define the custom debounce delay (in milliseconds) instead of fixed 2000 ms for triggering an onchange on the field. Note that this delay will be applied only when `onchange_on_keydown` node option is also provided. Also, we've utilized the odoo's debounce instead of the one provided by underscore js, for 2 reasons: 1 - odoo's debounce is already well tested (see the f
Original PR description
This PR introduces a node option `keydown_debounce_delay` on the
character field and on emoji mixin, so that user can define the custom
debounce delay (in milliseconds) instead of fixed 2000 ms for
triggering an onchange on the field. Note that this delay will be
applied only when `onchange_on_keydown` node option is also provided.
Also, we've utilized the odoo's debounce instead of the one provided by
underscore js, for 2 reasons:
1 - odoo's debounce is already well tested (see the file
/web/static/tests/core/utils/timing_tests.js)
2 - to take a step forward for reducing external lib dependency
Task: https://www.odoo.com/web#id=2821978&menu_id=4720&cids=2&action=4043&model=project.task&view_type=form
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#94087
Forward-Port-Of: odoo/odoo#92223In a multi-company environment, when we transform a lead (which has no salesperson) into an opportunity, we get an error. To reproduce the issue: 1) Create a new company 2) Create a Lead for a customer with the Company set 3) Remove the Sales Team 4) Set the company on the Lead 5) Convert to an opportunity and you will see an error showing up Solution: A previous commit (1fad826743de9c8f916ef083e8de453212df6959) adapted the `_compute_company_id` computation in which a case was forg
Original PR description
In a multi-company environment, when we transform a lead (which has no salesperson) into an opportunity, we get an error. To reproduce the issue: 1) Create a new company 2) Create a Lead for a customer with the Company set 3) Remove the Sales Team 4) Set the company on the Lead 5) Convert to an opportunity and you will see an error showing up Solution: A previous commit (1fad826743de9c8f916ef083e8de453212df6959) adapted the `_compute_company_id` computation in which a case was forgotten (the case described here-above). The fix was to force the `company_id` to the one of the `partner_id` if it has one. opw-2805181 Forward-Port-Of: odoo/odoo#94164 Forward-Port-Of: odoo/odoo#88108
Before this commit, when a restricted editor search for an image, he will have an error 404 not found, when he try to access to the unsplash key. Now he can search for image on Unsplash. Forward-Port-Of: odoo/odoo#94422
Original PR description
Before this commit, when a restricted editor search for an image, he will have an error 404 not found, when he try to access to the unsplash key. Now he can search for image on Unsplash. Forward-Port-Of: odoo/odoo#94422
See ticket 2803314 for steps to reproduce the issue. Before this commit: When creating a mail template for a marketing campaign targeting mailing contact, the reply_to_mode would be set to 'thread', and the reply_to field would be read-only. Since there is no way to target a mailing list from a marketing campaign (see the domain on marketing.campaign's model_id), and there is no default followers mailing.contact, email responses would be "lost". After this commit: The reply_to_mode
Original PR description
See ticket 2803314 for steps to reproduce the issue. Before this commit: When creating a mail template for a marketing campaign targeting mailing contact, the reply_to_mode would be set to 'thread', and the reply_to field would be read-only. Since there is no way to target a mailing list from a marketing campaign (see the domain on marketing.campaign's model_id), and there is no default followers mailing.contact, email responses would be "lost". After this commit: The reply_to_mode is set to 'email', and the reply_to is set accordingly Forward-Port-Of: odoo/odoo#94043 Forward-Port-Of: odoo/odoo#92968
**[FIX] stock: display the forecast symbol on outgoing SM** To reproduce the issue: 1. Create a storable product P 2. Update the on-hand quantity: 5 x P 3. Create a planned delivery order with 4 x P - Note: once saved, the forecast symbole is green 4. On the delivery order, set the quantity to 5 and save Error: The symbol is now red, which is incorrect: there are 5 available P in the stock The color condition is incorrect, when `forecast_availability` is equal to zero, it mea
Original PR description
**[FIX] stock: display the forecast symbol on outgoing SM** To reproduce the issue: 1. Create a storable product P 2. Update the on-hand quantity: 5 x P 3. Create a planned delivery order with 4 x P…
**[FIX] stock: display the forecast symbol on outgoing SM**
To reproduce the issue:
1. Create a storable product P
2. Update the on-hand quantity: 5 x P
3. Create a planned delivery order with 4 x P
- Note: once saved, the forecast symbole is green
4. On the delivery order, set the quantity to 5 and save
Error: The symbol is now red, which is incorrect: there are 5 available
P in the stock
The color condition is incorrect, when `forecast_availability` is equal
to zero, it means that there will be just the right quantity:
https://github.com/odoo/odoo/blob/892232b5aef42dd2706cb9d1d027b1c463ca50dd/addons/stock/models/stock_move.py#L446-L448
\
\
**[FIX] stock: display the forecast symbol for inter-wh SM**
To reproduce the issue:
(Let WH01 be the existing warehouse)
1. In Settings, enable "Storage Locations"
2. Create a second warehouse WH02
3. Create a storable product P
4. Create a planned and internal transfer:
- From: WH01/Stock
- To: WH02/Stock
- With: 1 x P
5. Save the transfer
- Error01: the forecast symbol is green, it should be red
6. Confirm the transfer
- Error02: idem
Error 01: Because the picking type is internal, we don't consider the
picking as a consuming one. Therefore, we don't reach the line that
define the forecast availability as negative:
https://github.com/odoo/odoo/blob/892232b5aef42dd2706cb9d1d027b1c463ca50dd/addons/stock/models/stock_move.py#L446-L448
Error 02: Fixing the first error is not enough. Thanks to the first
correction, we reach this line:
https://github.com/odoo/odoo/blob/892232b5aef42dd2706cb9d1d027b1c463ca50dd/addons/stock/models/stock_move.py#L449-L450
And we will then call another method to compute the forecast
availability:
https://github.com/odoo/odoo/blob/892232b5aef42dd2706cb9d1d027b1c463ca50dd/addons/stock/models/stock_move.py#L457-L463
However, `_get_forecast_availability_outgoing` won't define any forecast
availability for the move (it won't find any quantity to fulfill the
need). So, when getting the value (`forecast_info[move]`), we will a
have the default values:
https://github.com/odoo/odoo/blob/892232b5aef42dd2706cb9d1d027b1c463ca50dd/addons/stock/models/stock_move.py#L2035
where `result` is the dict returned by
`_get_forecast_availability_outgoing`. Later on, when using the field
`forecast_availability` to render the view: in case of an outgoing
transfer, we use the forecast widget:
https://github.com/odoo/odoo/blob/73ab94402878a16c34c0e131818ffc0d2e8da3da/addons/stock/views/stock_picking_views.xml#L393-L394
And it correctly works because we compare the forecast availability with
the demand:
https://github.com/odoo/odoo/blob/6eaa4a2ae3b12b244f4c4277ef9cbc172f492f0a/addons/stock/static/src/js/forecast_widget.js#L34
However, in case of an internal transfer, we don't use the forecast
widget:
https://github.com/odoo/odoo/blob/3a2ee95c3ddfa0b2cf9383772ba48ebf6d9d5bb2/addons/stock/views/stock_picking_views.xml#L388-L391
And, if `forecast_availability` is equal to zero, it should mean that
there will be just enough stock to fulfill the need [1]. This explains
why the symbol is green.
So, the issue comes from the values returned by
`_get_forecast_availability_outgoing`: it should not set the forecast
availability to zero if there isn't any stock available.
[1] Some tests need to be fixed to respect this definition of
`forecast_availability`
task-2822157
Forward-Port-Of: odoo/odoo#94215
Forward-Port-Of: odoo/odoo#92028The documentation page for the external API was moved elsewhere with PR odoo/documentation#2026. See also: - https://github.com/odoo/documentation/pull/2251 Forward-Port-Of: odoo/odoo#94452 Forward-Port-Of: odoo/odoo#94122
Original PR description
The documentation page for the external API was moved elsewhere with PR odoo/documentation#2026. See also: - https://github.com/odoo/documentation/pull/2251 Forward-Port-Of: odoo/odoo#94452 Forward-Port-Of: odoo/odoo#94122
Steps to reproduce the bug: - Install mrp and purchase - Create a new user “U1” > give him only the “purchase” user access - Log in as “U1” - Go to purchase app > create a new PO - Try to select any product Problem: A user error is triggered because we check if the product has a BOM but since the user does not have access to MRP, an error is raised opw-2885982 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odo
Original PR description
Steps to reproduce the bug: - Install mrp and purchase - Create a new user “U1” > give him only the “purchase” user access - Log in as “U1” - Go to purchase app > create a new PO - Try to select any product Problem: A user error is triggered because we check if the product has a BOM but since the user does not have access to MRP, an error is raised opw-2885982 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94183
scheduled_date is not computed correctly as it should respect recordset, current implementation just ignores computation cla signed https://github.com/odoo/odoo/pull/93921 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93920
Original PR description
scheduled_date is not computed correctly as it should respect recordset, current implementation just ignores computation cla signed https://github.com/odoo/odoo/pull/93921 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93920
Emails could not be resent from the chatter after failing to be sent. This was due to parts of the code not being updated after the refactoring of OWL. Multiple other instances of non-updated code are updated here. Task-2887153 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94341
Original PR description
Emails could not be resent from the chatter after failing to be sent. This was due to parts of the code not being updated after the refactoring of OWL. Multiple other instances of non-updated code are updated here. Task-2887153 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94341
Description of the issue/feature this PR addresses: after made customization where we need in `mailing.contact.subscription` value of `partner_id` Odoo generate internal Server Error. Please merge it to 13.0 too Current behavior before PR: after added field `partner_id` to model `mailing.contact.subscription` which is not storable application generate 500 error Desired behavior after PR is merged: `partner_id` is not storable in result first condition is skipped what is fine --
Original PR description
Description of the issue/feature this PR addresses: after made customization where we need in `mailing.contact.subscription` value of `partner_id` Odoo generate internal Server Error. Please merge it to 13.0 too Current behavior before PR: after added field `partner_id` to model `mailing.contact.subscription` which is not storable application generate 500 error Desired behavior after PR is merged: `partner_id` is not storable in result first condition is skipped what is fine -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94504 Forward-Port-Of: odoo/odoo#90566
Use `dict.get()` instead of a subscriptable call. This way we let through selection values that are not loaded into the registry, instead of raising an error. This is especially useful in the upgrade environment where such values may be unavailable (because of being lambda-defined in a custom module for instance). Aims to generically fix the following tracebacks during an upgrade: ``` Traceback (most recent call last): File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line
Original PR description
Use `dict.get()` instead of a subscriptable call. This way we let through selection values that are not loaded into the registry, instead of raising an error. This is especially useful in the upgrade…
Use `dict.get()` instead of a subscriptable call. This way we let through
selection values that are not loaded into the registry, instead of raising an error.
This is especially useful in the upgrade environment
where such values may be unavailable (because of being
lambda-defined in a custom module for instance).
Aims to generically fix the following tracebacks during an upgrade:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 475, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
migrate(self.cr, installed_version)
File "/tmp/tmpy41hhfba/migrations/mrp/saas~13.4.2.0/end-migrate.py", line 375, in migrate
util.recompute_fields(cr, "mrp.production", ["state", "production_location_id"], strategy="commit")
File "/tmp/tmpy41hhfba/migrations/util/orm.py", line 188, in recompute_fields
cr.commit()
File "<decorator-gen-7>", line 2, in commit
File "/home/odoo/src/odoo/14.0/odoo/sql_db.py", line 101, in check
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/14.0/odoo/sql_db.py", line 445, in commit
self.precommit.run()
File "/home/odoo/src/odoo/14.0/odoo/tools/misc.py", line 1154, in run
func()
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 550, in _finalize_tracking
tracking = records.with_context(context).message_track(fnames, initial_values)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 611, in message_track
tracking[record.id] = record._message_track(tracked_fields, initial_values[record.id])
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 641, in _message_track
return self._mail_track(tracked_fields, initial)
File "/home/odoo/src/odoo/14.0/addons/mail/models/models.py", line 47, in _mail_track
tracking = self.env['mail.tracking.value'].create_tracking_values(initial_value, new_value, col_name, col_info, tracking_sequence, self._name)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_tracking_value.py", line 71, in create_tracking_values
'old_value_char': initial_value and dict(col_info['selection'])[initial_value] or '',
KeyError: 'picking_except'
```
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#94496
Forward-Port-Of: odoo/odoo#92466If the module `l10n_de` is installed, the test `test_kit_anglo_saxo_price_diff` will fail. This is because the flag `use_anglo_saxon` is not enabled by default in the chart template of German companies. Therefore, when posting the invoice, we skip the anglo-saxon lines generation: https://github.com/odoo/odoo/blob/f3ae759f2d54829f91badd32cacf70e8a8211288/addons/purchase_stock/models/account_invoice.py#L40-L42 This explains why the test fails. OPW-2843861 Forward-Port-Of: odoo/odoo#9442
Original PR description
If the module `l10n_de` is installed, the test `test_kit_anglo_saxo_price_diff` will fail. This is because the flag `use_anglo_saxon` is not enabled by default in the chart template of German companies. Therefore, when posting the invoice, we skip the anglo-saxon lines generation: https://github.com/odoo/odoo/blob/f3ae759f2d54829f91badd32cacf70e8a8211288/addons/purchase_stock/models/account_invoice.py#L40-L42 This explains why the test fails. OPW-2843861 Forward-Port-Of: odoo/odoo#94421
This commit fix the template "report_payment_receipt_document". The template call the python method "_get_reconciled_invoices_partials" but which signature was broken by https://github.com/odoo/odoo/commit/785d49f3f0a21720d8c929d597d4041918ab7f41 task-id: None Forward-Port-Of: odoo/odoo#94522
Original PR description
This commit fix the template "report_payment_receipt_document". The template call the python method "_get_reconciled_invoices_partials" but which signature was broken by https://github.com/odoo/odoo/commit/785d49f3f0a21720d8c929d597d4041918ab7f41 task-id: None Forward-Port-Of: odoo/odoo#94522
Steps to reproduce: - Create a partner-individual, assign to a company - Create an invoice and set the new partner as the customer - Go to the partner view - Delete it Issue: - It is possible to delete it Cause: The constraint in "account.move.line" uses the "commercial_partner_id" as the partner Solution: - Prevent the unlink if the partner is used in 'account.move' -> To delete in Master - add "ondelete='restrict' for partner and commercial_parner in 'account.move' opw-2858
Original PR description
Steps to reproduce: - Create a partner-individual, assign to a company - Create an invoice and set the new partner as the customer - Go to the partner view - Delete it Issue: - It is possible to delete it Cause: The constraint in "account.move.line" uses the "commercial_partner_id" as the partner Solution: - Prevent the unlink if the partner is used in 'account.move' -> To delete in Master - add "ondelete='restrict' for partner and commercial_parner in 'account.move' opw-2858789 Forward-Port-Of: odoo/odoo#93905 Forward-Port-Of: odoo/odoo#92793
The drag and drop mega test is quite simple: the python gets the list of all the snippets (by rendering a view + etree), then it just starts a JS tour by passing all those snippets in the tour URL. From there, the JS tour is in charged of building its own steps based on the list of snippets it received from the python. The MOST important part is to be 100% sure that the built steps are as expected: ~5 steps / snippets: ~220 steps with website only and ~280 steps with all modules. If
Original PR description
The drag and drop mega test is quite simple: the python gets the list of all the snippets (by rendering a view + etree), then it just starts a JS tour by passing all those snippets in the tour URL.…
The drag and drop mega test is quite simple: the python gets the list of all the snippets (by rendering a view + etree), then it just starts a JS tour by passing all those snippets in the tour URL. From there, the JS tour is in charged of building its own steps based on the list of snippets it received from the python. The MOST important part is to be 100% sure that the built steps are as expected: ~5 steps / snippets: ~220 steps with website only and ~280 steps with all modules. If we don't have that check, the tour could suddenly not test anything because the step list would be empty, but the test wouldn't fail. Thus, we don't want to programmatically try to compute that step amount but want it to remain an hardcoded number, which is lowered in this commit as if we have 220 (it could be 200, 150..) steps, it means that the steps were built as expected. Note that since the test is run on post_install, 280 was fine since all modules were installed. But the nightly build is also testing this test with only the website module, ultimately failing. Note that this check was actually not working at all since [1] as there was a typo on `length`. [1]: https://github.com/odoo/odoo/commit/61b19dafd1fb79120f701b94038bbe859aa2e271 Forward-Port-Of: odoo/odoo#94576 Forward-Port-Of: odoo/odoo#94543
In some situations (for instance when generating a SEPA payment file from a payslip without number), it can happen that the payment name is not filled in. As InstrdId element is not required, we should not crash in that case and simply ignore this element instead. opw-2873425 Forward-Port-Of: odoo/enterprise#28694
Original PR description
In some situations (for instance when generating a SEPA payment file from a payslip without number), it can happen that the payment name is not filled in. As InstrdId element is not required, we should not crash in that case and simply ignore this element instead. opw-2873425 Forward-Port-Of: odoo/enterprise#28694
…4.0 module Forward-Port-Of: odoo/enterprise#28625
Original PR description
…4.0 module Forward-Port-Of: odoo/enterprise#28625
Currently, when recording a bill with a res.partner which is not a commercial entity (e.g. Brandon Freedman from Azure Interior), clicking on "Open Invoices" in the Australian report will not retrieve the bill because of the domain of the action returned by 'open_invoices'. Forward-Port-Of: odoo/enterprise#28727
Original PR description
Currently, when recording a bill with a res.partner which is not a commercial entity (e.g. Brandon Freedman from Azure Interior), clicking on "Open Invoices" in the Australian report will not retrieve the bill because of the domain of the action returned by 'open_invoices'. Forward-Port-Of: odoo/enterprise#28727
This commit adds a new product demo to test the workorder tablet view. This new product adds data in mrp_workorder, quality and purchase. Task: 2870657 Forward-Port-Of: odoo/enterprise#28192
Original PR description
This commit adds a new product demo to test the workorder tablet view. This new product adds data in mrp_workorder, quality and purchase. Task: 2870657 Forward-Port-Of: odoo/enterprise#28192
Currently while sharing an appointment, there is some misbehavior while manually changing the code: 1/ clicking on "Save & Copy" will copy the old link (before manual change, unless another click is done first). 2/ if you type an already used short code, and immediately click on "Save & Copy", the rpc call is triggered and raises the validation error (before the div alert is visible, and the button gets disabled). Both of them happens because the onchange on the short code wo
Original PR description
Currently while sharing an appointment, there is some misbehavior while manually changing the code: 1/ clicking on "Save & Copy" will copy the old link (before manual change, unless another click is done first). 2/ if you type an already used short code, and immediately click on "Save & Copy", the rpc call is triggered and raises the validation error (before the div alert is visible, and the button gets disabled). Both of them happens because the onchange on the short code won't trigger unless we click somewhere else before hitting the "Save & Copy" button. With this PR, we enable triggering the on change while typing, with a short debounce delay of 0.5 seconds. Apart from that, we now do not hide the whole URL if short code is emptied by user. Task: https://www.odoo.com/web#id=2821978&menu_id=4720&cids=2&action=4043&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#28624 Forward-Port-Of: odoo/enterprise#27742
Forward-Port-Of: odoo/enterprise#28783
Original PR description
Forward-Port-Of: odoo/enterprise#28783
**Current behavior before PR:** When we upload a file and set the contact with the newly created contact. From Documents, you can click on the right menu on "create bills" or "create customer invoice", but the generated record won't have its populated payments term. **Desired behavior after PR is merged:** According to selected contact, payment terms will be populated. **LINKS:** Task-2645666 Forward-Port-Of: odoo/enterprise#21216
Original PR description
**Current behavior before PR:** When we upload a file and set the contact with the newly created contact. From Documents, you can click on the right menu on "create bills" or "create customer invoice", but the generated record won't have its populated payments term. **Desired behavior after PR is merged:** According to selected contact, payment terms will be populated. **LINKS:** Task-2645666 Forward-Port-Of: odoo/enterprise#21216
How to reproduce the bug ? - Install hr_exepense - If needed, change the email address of the current user to the one that will send the email. - In Settings > Expenses, make sure that an alias (check that incoming emails create expenses) is set and that Digitalize automatically is selected. - Send an email to the address set earlier. - Wait for the cron to fetch emails or execute the cron manually. - In the Expenses app, click on on the expense that has the subject of the email as d
Original PR description
How to reproduce the bug ? - Install hr_exepense - If needed, change the email address of the current user to the one that will send the email. - In Settings > Expenses, make sure that an alias (check that incoming emails create expenses) is set and that Digitalize automatically is selected. - Send an email to the address set earlier. - Wait for the cron to fetch emails or execute the cron manually. - In the Expenses app, click on on the expense that has the subject of the email as description What is the bug ? When you create an expense by sending an email with an attachment, the expense will be created but the attachment will not be automatically digitalized even if the option is set in the settings. This PR partially revert the following commit https://github.com/odoo/enterprise/commit/dded12fa892cb4a6f764494adff140a422e522b9 opw-2869381 Signed-off-by: Adrien Minet <admi@odoo.com> Forward-Port-Of: odoo/enterprise#28651