Wednesday, May 27, 2020
42 changes · master
Enhancements to existing features
The search panel is easier to use: expand and collapse controls now sit consistently to the left, and users can click the full category header instead of a small arrow. This makes filtering and browsing hierarchical options clearer and more predictable.
Original PR description
Tasks: 2258508 / 2264700
Odoo now uses its standard creation and update date fields for internal system records instead of older duplicate date fields. This reduces inconsistency in metadata and helps ensure record history is stored more reliably, including when records are created through direct database operations.
Original PR description
@moylop260's odoo/odoo#50516 led me to take a look, notice that create_date and write_date were pretty much never set on ir.model.data records and the it also had `date_init`/`date_update` which are…
@moylop260's odoo/odoo#50516 led me to take a look, notice that create_date and write_date were pretty much never set on ir.model.data records and the it also had `date_init`/`date_update` which are not reliably set, and seem like redundant ad-hoc versions of `create_date` and `write_date`. odoo/odoo#34988 removed them constrains & relations, but we might as well also nuke them from ir.model.data, and fix the various points where a date should be set and is not: * removes the date_init/date_update fields from the SQL and model * converts the one bit of code which did set those to set create_date/write_date * use create_date/write_date in the view * adds setting those columns to a bunch of raw SQL queries which were missing them (also updates the queries some to merge the literal values into the queries as it seems unnecessary to interpolate e.g. a boolean literal) Assuming this is considered a good idea, will require some migrationy bits: * copy date_init and date_update over to `create_date` and `write_date` * possibly update the schema to set default values on create_date and write_date if we decide to do that (?)
The Project app onboarding tour now uses clearer guidance and a better flow. It helps new users learn how to use task chatter features, making collaboration tools easier to discover during setup.
Original PR description
The onboarding tour of the project app has been improved by changing some messages and changing the flow to show users how to use the chatter features within tasks. Task ID: 2238624 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the recruitment setup by adding LinkedIn as a default source only for new job positions and cleaning up related sources when jobs are deleted. It also removes the Google Map from recruitment email templates because most companies do not have the required API key, reducing unnecessary setup friction.
Original PR description
Multiple small changes/fixes to the hr_recruitment module to provide a better base for later improvements. The linkedin recruitment source is only added by default to new records, existing records remain unchanged. For the google map in the email template, since it requires an API_Key and only a minority of companies will get this key, it was decided that it is better to remove it from the template. [IMP] hr_recruitment: remove duplicate LinkedIn sources. Now that linkedin is added to job positions by default, deleting a job position currently does not delete the related linkedin source. So after removing 10 job positions, there are still 10 linked in source in the database. This commit fixes that. Task ID: 2196767. 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
Purchasing teams can now see a vendor's on-time delivery rate from the past year directly on purchase orders and vendor records, with drill-down reporting for details. Vendors also receive reminders to confirm or update receipt dates through the portal, helping buyers spot delays earlier and keep purchase orders accurate.
Original PR description
1. add on-time delivery rate to vendor, when editing a PO, the on-time rate of last 356 days will be shown next to the vendor. When clicking the rate, redirect to a graph showing the detail. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update lets Odoo customize the labels shown on form dialog buttons, such as changing “Save” to “Add” when creating a new social stream. It also enables tailored celebration messages at the end of guided tours, making user flows clearer and more contextual.
Original PR description
Purpose ======= In Social, we want to be able to change the "Save" button into a "Add" button when we add a new stream. For that purpose, we need to be able to customize the text of the `FormViewDialog` buttons. Be able to customize the rainbowman message when a tour is ended. Task-2234580 See odoo/enterprise/pull/9933
OdooBot’s onboarding flow is now less disruptive and easier to follow, with clearer prompts, better help responses, and tutorial attachments moved to a more useful point. It also avoids creating repeated reminder conversations for administrators, keeping inboxes cleaner.
Original PR description
PURPOSE This merge attempts to improve the workflow of the OdooBot onboarding tutorial, as well as the answer given by the bot while idle. SPECIFICATIONS These changes come from watching how users…
PURPOSE
This merge attempts to improve the workflow of the OdooBot onboarding
tutorial, as well as the answer given by the bot while idle.
SPECIFICATIONS
These changes come from watching how users interact with OdooBot. To
improve the user's experience, the following changes have been made:
1. Move the attachment to the end of the tour, as it is where most
people just close the bot.
2. Remove the quotation marks around commands that OdooBot tells the
user to type, like "/" or ":)", as some users try to actually type
the quotation marks too. Instead, use a light grey background around
the command that the user should type.
3. Some users ask OdooBot questions, but the responses they get are
useless. To solve this, use a message linking to the documentation or the
videos when:
- The user gives wrong answers twice for the same stage of the tour
- The user talks again when the tour is completed
- There's a question mark in the answer
Other issues have been attended to:
1. The first message from OdooBot when starting the onboarding tour will now only appear as a notification instead of opening a new chat window. The user can open the chat window from the notification when they actually want to start the tour, as it can be otherwise distracting for the user to have the chat window pop up all of a sudden.
2. A bug has been corrected where OdooBot would open a new channel every time the admin user logged in, to remind them about changing the default password. Now, it will use an existing channel if it exists.
Task ID: 2233014
Upgrade PR odoo/upgrade#1251Mass mailing users now get clearer guidance when choosing a specific reply-to email address, helping avoid replies that cannot be tracked or processed. Mailing performance indicators are also easier to use, with sent counts shown as clickable text and click metrics leading to related link tracking reports.
Original PR description
- Add an info icon for the "specified email address" option in the "reply to" field. Going over this icon shows a message explaining why the indicated email address should belong to the DB. - Number of emails/sms sent is now display as clickable text instead of stat button and clicked stat button is now also visible in mass_mailing mailing_mailing_views.xml has been modified in mass_mailing_crm and mass_mailing_sale since the id used in the xpath doesn't exist anymore. Task ID: 2202495 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
The Social app now includes an in-app tour to guide users through its workflow, along with updated screens and clearer app information. Creating posts is also faster because accounts are automatically selected when there are three or fewer available, reducing manual setup for simple campaigns.
Original PR description
Purpose ======= Add a tour, to show the work flow of the social application. Update the application description and update views to improve the user experience. When we write a post, if there are 3 or less than 3 social accounts, select them all by default. Task-2234580 See odoo/odoo/pull/49622
The recruitment referral job view no longer shows the extra search panel. This simplifies the hiring referral experience by reducing screen clutter and helping users focus on the main job list.
Original PR description
TaskID: 2196767
This update makes sure the SMS message composer receives the right information when sending account follow-up messages. It helps reduce errors and makes customer payment reminders more reliable.
This update makes the SMS reminder setup more explicit so the system chooses the correct default sending mode. It helps ensure customer follow-up messages are prepared consistently when using the follow-up report.
Timesheet validation no longer interrupts users with a separate wizard. Instead, users receive a notification, making the validation flow faster and less disruptive while keeping related sales timesheet behavior covered by tests.
Original PR description
TaskID: 2264632
Resolved issues and error corrections
This update fixes problems in the SMS composer so users get immediate feedback when a phone number is invalid and can send messages without crashes when a contact has no mobile number. It also prevents the send button from moving unexpectedly, making the SMS sending experience smoother and clearer.
Original PR description
Description of the issue/feature this PR addresses: _See current behavior_ Current behavior before PR: [Youtube Link 1](https://www.youtube.com/watch?v=tsaR_JYlUM8) [Youtube Link 2](https://www.youtube.com/watch?v=7qFDL8YW63g) Desired behavior after PR is merged: The sms sending flow should now be working. Fix the button jump in video 2 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The SMS sending form has been simplified so phone number values are handled consistently whether entered by a user or filled automatically. This fixes crashes when sending from CRM records without mobile numbers and prevents the send button from moving unexpectedly after correcting an invalid phone number.
Original PR description
Description of the issue/feature this PR addresses: Update classic fields updated in some cases by onchange and/or default methods by fields with store=True, readonly=False. It means their value…
Miscellaneous changes
Before this commit, Clicking on "Unpaid Invoices" or "Bills to Pay" will open records which includes Unposted moves as well while the count was only counting Posted + Unpaid moves only. With this commit, We apply the default 'posted' filter to make this behavior consistent. 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-
Original PR description
Before this commit, Clicking on "Unpaid Invoices" or "Bills to Pay" will open records which includes Unposted moves as well while the count was only counting Posted + Unpaid moves only. With this commit, We apply the default 'posted' filter to make this behavior consistent. 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#51491 Forward-Port-Of: odoo/odoo#50522
This update improves the web module’s internal request handling used during testing, helping new visual components such as the map view behave correctly. It also prevents certain renderers from being initialized twice, reducing the chance of display issues and unnecessary processing.
Original PR description
This commit adds httpRequest in test_env because the new map renderer needs it. Task: 2230976
Pricelist rules that start and end on the same day now apply correctly when an order uses a specific time on that date. This prevents valid one-day prices from being missed on sales orders and helps ensure customers receive the intended pricing.
Original PR description
Description of the issue/feature this PR addresses: If a pricelist item is defined with the same date_start and date_end, and the context date is defined as a Datetime, the sql query will not return the pricelist item as the date_start <= and date_end => conditions will not be fullfilled. Current behavior before PR: * A Pricelist item with date_start = 2020-05-27 and date_end = 2020-05-27 (same) * A sale order with the date_order = 2020-05-27 08:00:00 * The pricelist will never be applied Desired behavior after PR is merged: * A Pricelist item with date_start = 2020-05-27 and date_end = 2020-05-27 (same) * A sale order with the date_order = 2020-05-27 08:00:00 * The pricelist will be applied -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previously misapplied fix in the invoice analysis report. It helps ensure accounting reports reflect the intended behavior and reduces the risk of misleading invoice analysis data.
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
This fixes an error that could occur when changing an attendee's status on a calendar event. It helps ensure calendar responses can be updated reliably without disrupting users.
Original PR description
Coming from the calendar refactoring at https://github.com/odoo/odoo/commit/39aef65f37a8ae969527b31a680eb27fddbc5710 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
This fixes an issue where a previously invisible line at the top of the website footer could become visible in some situations. The change keeps footer editing behavior working while removing the unwanted visual artifact for visitors and editors.
Original PR description
The footer of Odoo is composed of 3 main elements: a `<footer/>` with a .oe_structure and the footer copyright inside. The footer had a transparent top border which was there for technical reason: making sure the .oe_structure content was "1px" below the end-of-page content so that dropping a snippet at the end of page but also in the footer was possible (otherwise the dropzones would be at the exact same position). This border which was invisible at the time may now become visible in more cases so we have to remove it. Another hacky solution is made to replace the old one, while remembering the footer usability is being reviewed anyway. task-2197038
Studio approval workflows now work correctly on more header buttons, including those that launch actions. The update also prevents uninstall issues by allowing approval rules to be removed cleanly when the related module is being uninstalled.
Original PR description
Check commit messages for details.
This update corrects a small typo in the Studio approvals area. It helps keep the interface or related behavior polished and avoids confusion from incorrect wording.
This fix removes outdated internal access-related entries in Odoo Studio. It helps prevent obsolete configuration data from lingering and reduces the chance of confusing or incorrect behavior when Studio-managed models are updated.
Original PR description
Cf odoo/odoo#50661
Description of the issue/feature this PR addresses: Update classic fields updated in some cases by onchange and/or default methods by fields with store=True, readonly=False. It means their value comes either from manual user input, either from trigger based computation. Remove onchange and default_get when possible, leading to an unique computation method and clearing fields definition. Also clean some fields definition inconsistencies, notably required fields that should instead be correctly computed or default that have no real meaning. Current behavior before PR: Bug #1: sending an sms from CRM to a lead that doesn't have a mobile number resulted in crash Bug #2: When updating the phone number on the sms composer after that the phone was not valid and going directly to click on send, the send button jumped from it's place. Desired behavior after PR is merged: Fixed Bugs mentionned above. Task [#2229050](https://www.odoo.com/web#cids=1&id=2229050&menu_id=5195&model=project.task&view_type=form) and [#2244192](https://www.odoo.com/web#cids=1&id=2244192&menu_id=&model=project.task&view_type=form) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
- Set two companies (A and B); - Set intercompany flows enabled between company A and B with synchronization of PO/SO; - create a product X is configured as follows in company B: - Storable product; - Routes “Buy” and “Dropship”; - Vendors price list set with vendor = company A. - Product X is configured as follows in company A: - Storable product; - Reordering rule Min 0 / Max 0; - Route “Buy”; - Vendors price list set with vendor = 'External Vendor'. - Create and v
Original PR description
- Set two companies (A and B); - Set intercompany flows enabled between company A and B with synchronization of PO/SO; - create a product X is configured as follows in company B: - Storable product;…
- Set two companies (A and B); - Set intercompany flows enabled between company A and B with synchronization of PO/SO; - create a product X is configured as follows in company B: - Storable product; - Routes “Buy” and “Dropship”; - Vendors price list set with vendor = company A. - Product X is configured as follows in company A: - Storable product; - Reordering rule Min 0 / Max 0; - Route “Buy”; - Vendors price list set with vendor = 'External Vendor'. - Create and validate a sale order for product X to final customer within company B; Odoo will automatically create a purchase order for product X to company A within company B; - Validate the purchase order in company B; Odoo will automatically create a sale order for product X to company B within company A; - If there is no available stock in warehouse A; Odoo will automatically create a purchase order for product X within company A. Before this commit, the purchase order is created with vendor as 'Company A'. As '_select_seller' is run in sudo mode (see: https://github.com/odoo/odoo/blob/a16c4a0dabe58ab2cfade353c113387ae5bcd572/addons/stock/models/stock_rule.py#L458), so is not company-aware, therefore the first matching supplier is chosen. Now, the purchase order will be created with vendor as 'External Vendor'. opw-2255989 Forward-Port-Of: odoo/odoo#51886 Forward-Port-Of: odoo/odoo#51866
Bug === Since 0bd14547a7f6389192f522da08527a2c8a13f1a8, When editing a record which has a tracked field with a group, and if the current user is not in the group, an error is raised. Technical ========= When we get the tracked fields, we must care about the group of the current user and keep only the tracked fields the user have access to. To do that, we use `fields_get`, which will return only fields accessible by the current user group. The method `_get_tracked_fields` is cach
Original PR description
Bug === Since 0bd14547a7f6389192f522da08527a2c8a13f1a8, When editing a record which has a tracked field with a group, and if the current user is not in the group, an error is raised. Technical ========= When we get the tracked fields, we must care about the group of the current user and keep only the tracked fields the user have access to. To do that, we use `fields_get`, which will return only fields accessible by the current user group. The method `_get_tracked_fields` is cached, but it need to depend on the current user (and also if we are in sudo mode or not), because the function will return different results, depending on the group of the user. Task-2250070 Forward-Port-Of: odoo/odoo#50629
### Issue - Attendances > Manager > Attendances - Create a line for any employee check-in 30/04/2020 12PM check out 01/05/2020 12PM - Go to Employees > the employee Last month worked hours = 0 but it should be 12 ### Cause We only take into account records checked_out the previous month ### Solution Rethink the whole method to take into account records checked_in last month and checked_out this month **OPW-2259533** -- I confirm I have signed the
Original PR description
### Issue - Attendances > Manager > Attendances - Create a line for any employee check-in 30/04/2020 12PM check out 01/05/2020 12PM - Go to Employees > the employee Last month worked hours = 0 but it should be 12 ### Cause We only take into account records checked_out the previous month ### Solution Rethink the whole method to take into account records checked_in last month and checked_out this month **OPW-2259533** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#51694
Steps to reproduce the bug: - Let's consider a product P (invocing policy based on timesheet and creating new task) - Create a quotation with the product P - Confirm it (A new task T is created) - Go to T and add a follower (who is a portal user PU) in the task but uncheck the box to send him an email - Connect to the portal with PU - Go to T and send a message Bug: A 403 error was raised opw:2239844 Forward-Port-Of: odoo/odoo#51906
Original PR description
Steps to reproduce the bug: - Let's consider a product P (invocing policy based on timesheet and creating new task) - Create a quotation with the product P - Confirm it (A new task T is created) - Go to T and add a follower (who is a portal user PU) in the task but uncheck the box to send him an email - Connect to the portal with PU - Go to T and send a message Bug: A 403 error was raised opw:2239844 Forward-Port-Of: odoo/odoo#51906
Steps to reproduce: - Install eCommerce - Check in website setting that the sales team is website - Logout - Without being logged, buy a product (all the cart flow, until the end) - Once the flow is finished, connect with the admin - Go to website > Orders > Unpaid Orders (since only wired is set when you create the db) - Go to the tab "Other Info" of the SO you just created when buying the product Previous behavior: the sales team set in website settings is overriden during the "/sh
Original PR description
Steps to reproduce: - Install eCommerce - Check in website setting that the sales team is website - Logout - Without being logged, buy a product (all the cart flow, until the end) - Once the flow is finished, connect with the admin - Go to website > Orders > Unpaid Orders (since only wired is set when you create the db) - Go to the tab "Other Info" of the SO you just created when buying the product Previous behavior: the sales team set in website settings is overriden during the "/shop/address" endpoint Current behavior: the team set in website settings is used for sale orders coming from website opw-2231654 Forward-Port-Of: odoo/odoo#51900
A view is marked as `arch_updated` if `arch` is being written on it and `install_filename` is not in the context: https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/odoo/addons/base/models/ir_ui_view.py#L460-L461 When a view is being updated from a `theme.ir.ui.view` through `_update_records` https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L29 https://github.com/odoo/odoo/blob/7b1a6c
Original PR description
A view is marked as `arch_updated` if `arch` is being written on it and `install_filename` is not in the context:…
A view is marked as `arch_updated` if `arch` is being written on it and `install_filename` is not in the context: https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/odoo/addons/base/models/ir_ui_view.py#L460-L461 When a view is being updated from a `theme.ir.ui.view` through `_update_records` https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L29 https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L92 https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L208 https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L168 we can basically consider it comes from a data file, the template is updated, and its copies as well if the copies are "unchanged" and therefore the `arch_updated` should not be set to `True` in such as case, as the goal of this flag is to mark the view as `arch_updated` if it was updated by the user, not from a data file loading. Because the views are marked as `arch_updated`, in 13.0, when updating the theme view "templates" (`theme.ir.ui.view`), the copies are not being updated even if they have been left untouched: https://github.com/odoo/odoo/blob/23511dffb9e3f597a7df9bb834d008f74abb07b8/addons/website_theme_install/models/ir_module_module.py#L165-L166 This is really problematic for upgrades, as the "copies" (the themes views) are not updated according to the latest changes in the xml files, even if the views have been left untouched by the user. For instance, this change in the common theme: odoo/design-themes@29da153784705b48b8c6b99fcdaa5bcbce54f183 is never updated in databases, resulting in the below traceback ``` ValueError: Element '<xpath expr="//div[@data-js='content']">' cannot be located in parent view Fout context: Weergave`s_badge_options` [view_id: 2103, xml_id: n/b, model: n/b, parent_id: 901] load could not load template ValueError: Element '<xpath expr="//div[@data-js='content']">' cannot be located in parent view ``` opw-2255753 Forward-Port-Of: odoo/odoo#51933 Forward-Port-Of: odoo/odoo#51931
Steps to reproduce the bug: - Let's consider the current company CY in € - Let's consider a cash basis tax T of 20% - Let's consider that 1€ = 2$ - Create a customer invoice I on journal J in € for customer C - Create a line on J with 100€ and set T on it - Post I - Create a payment P of 240$ for C on bank journal in € - Confirm P and click on payment matching - Try to reconcile P with I Bug: A traceback was raised. Fine tuning of https://github.com/odoo/odoo/commit/0497c311e
Original PR description
Steps to reproduce the bug: - Let's consider the current company CY in € - Let's consider a cash basis tax T of 20% - Let's consider that 1€ = 2$ - Create a customer invoice I on journal J in € for customer C - Create a line on J with 100€ and set T on it - Post I - Create a payment P of 240$ for C on bank journal in € - Confirm P and click on payment matching - Try to reconcile P with I Bug: A traceback was raised. Fine tuning of https://github.com/odoo/odoo/commit/0497c311e790454deb9ded2ed4fb206f5fd929ef opw:2256207 Forward-Port-Of: odoo/odoo#51938
[FIX] web: mount owl renderer once --- Before this commit, owl renderers were mounted twice. This commit makes owl renderers mounted just once as it should be [FIX] web: fix httpRequest GET + add in test_env --- This commit fixes the method GET in httpRequest and adds it in test_env. Before this commit, the GET method crashed because of the forced body param. Forward-Port-Of: odoo/odoo#51949 Forward-Port-Of: odoo/odoo#51884
Original PR description
[FIX] web: mount owl renderer once --- Before this commit, owl renderers were mounted twice. This commit makes owl renderers mounted just once as it should be [FIX] web: fix httpRequest GET + add in test_env --- This commit fixes the method GET in httpRequest and adds it in test_env. Before this commit, the GET method crashed because of the forced body param. Forward-Port-Of: odoo/odoo#51949 Forward-Port-Of: odoo/odoo#51884
⚠️ As indicated in the comments, it's much preferred to perform response buffering at the reverse proxy level than to increase the socket timeout. It will free up HTTP workers for other requests faster, while the proxy does the work of buffering the stream on disk as needed. The timeout is also used to protect from accidental DoS effects in situations of low worker availability, due to idle connections caused e.g. by wkhtmltopdf's connection pooling. Setting a high timeout will make the prot
Original PR description
⚠️ As indicated in the comments, it's much preferred to perform response buffering at the reverse proxy level than to increase the socket timeout. It will free up HTTP workers for other requests faster, while the proxy does the work of buffering the stream on disk as needed. The timeout is also used to protect from accidental DoS effects in situations of low worker availability, due to idle connections caused e.g. by wkhtmltopdf's connection pooling. Setting a high timeout will make the protection less effective, so ensuring you have enough free HTTP workers at all times becomes critical. In our tests with nginx's defaut buffering on a typical hardware with SSD storage, buffering up to 1GB responses did not require any change of the socket timeout on the Odoo side, though your mileage may vary. See also nginx's `proxy_buffering` and `proxy_max_temp_file_size` config directives. OPW-2247730 See also: #20158 Forward-Port-Of: odoo/odoo#51824
Before this commit, Clicking on "Unpaid Invoices" or "Bills to Pay" will open records which includes Unposted moves as well while the count was only counting Posted + Unpaid moves only. With this commit, We apply the default 'posted' filter to make this behavior consistent. 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-
Original PR description
Before this commit, Clicking on "Unpaid Invoices" or "Bills to Pay" will open records which includes Unposted moves as well while the count was only counting Posted + Unpaid moves only. With this commit, We apply the default 'posted' filter to make this behavior consistent. 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#50522
replace #51810 Forward-Port-Of: odoo/odoo#51822
Original PR description
replace #51810 Forward-Port-Of: odoo/odoo#51822
When a resequencing is done inside an object hierarchy of two controllers, since 9b90d8727d we would call resquencing code one time per controller. So if for example we are in a list view inside a form view (eg. a "Search More" modal in a form view) the resequencing would work for the list view, but then cause traceback when it is handled by form view. With this changeset, the first controller that get the event `resequence_records` even gobbles it up. TODO: adding test causing the error opw
Original PR description
When a resequencing is done inside an object hierarchy of two controllers, since 9b90d8727d we would call resquencing code one time per controller. So if for example we are in a list view inside a form view (eg. a "Search More" modal in a form view) the resequencing would work for the list view, but then cause traceback when it is handled by form view. With this changeset, the first controller that get the event `resequence_records` even gobbles it up. TODO: adding test causing the error opw-2256818 Forward-Port-Of: odoo/odoo#52013 Forward-Port-Of: odoo/odoo#51827
- Go to Project - Open a project to display Tasks - Switch to list view - Click on create button - On task form page, click nowhere. (It is important to not click on anything) - On the taskbar of the WYSIWYG editor used for Description, click on one of the following actions: * Unordered list * Ordered list * Checklist * Table * Style - The action will be applied to the "name" field (Task Title) and an error will prompt for Unordered list, Ordered list and Checkl
Original PR description
- Go to Project
- Open a project to display Tasks
- Switch to list view
- Click on create button
- On task form page, click nowhere. (It is important to not click on anything)
- On the taskbar of the WYSIWYG editor used for Description, click on one of the following actions:
* Unordered list
* Ordered list
* Checklist
* Table
* Style
- The action will be applied to the "name" field (Task Title) and
an error will prompt for Unordered list, Ordered list and Checklist actions
- If not, discard the form and retry by opening the form with create button
In this case, the WYSIWYG editor does not have the focus and try to execute
the tool action on the current focused element.
opw-2256835
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#51956This reverts commit fdd4a143f2148ec5f4aeea80fecd3138fea95dc6. See discussion in #51969 Forward-Port-Of: odoo/odoo#52019 Forward-Port-Of: odoo/odoo#52015
Original PR description
This reverts commit fdd4a143f2148ec5f4aeea80fecd3138fea95dc6. See discussion in #51969 Forward-Port-Of: odoo/odoo#52019 Forward-Port-Of: odoo/odoo#52015
Before this commit, there were negative values in the mod 111 tax report ('[02] Importe de las percepciones' and '[03] Importe de las retenciones'). Now, both values are positive. opw-2209079 Forward-Port-Of: odoo/enterprise#10797 Forward-Port-Of: odoo/enterprise#10782
Original PR description
Before this commit, there were negative values in the mod 111 tax report
('[02] Importe de las percepciones' and
'[03] Importe de las retenciones').
Now, both values are positive.
opw-2209079
Forward-Port-Of: odoo/enterprise#10797
Forward-Port-Of: odoo/enterprise#10782Forward-Port-Of: odoo/enterprise#10783
Original PR description
Forward-Port-Of: odoo/enterprise#10783
Steps to reproduce the bug: - Let's consider a subscription product SP - SP name is translated in SPF in French and in SPE in English - Let's consider a customer C with French as lang and our current user U is in English - Create a SO for C with SP (the description of SP is translated in SPF on the line) - Confirm the SO - Go to the related subscription and tick 'To renew' - Click Renewal quotation Bug: A new quote is created for C but the description of SP is not translated. o
Original PR description
Steps to reproduce the bug: - Let's consider a subscription product SP - SP name is translated in SPF in French and in SPE in English - Let's consider a customer C with French as lang and our current user U is in English - Create a SO for C with SP (the description of SP is translated in SPF on the line) - Confirm the SO - Go to the related subscription and tick 'To renew' - Click Renewal quotation Bug: A new quote is created for C but the description of SP is not translated. opw:2261110 Forward-Port-Of: odoo/enterprise#10763
Go in Documents App Select some tags from the left bar Create a Documents share Review the created share under Configuration>Shared Links Tags will be missing. This occur because of an error in the view: tags are defined twice, the second time invisible, thus conflicting with the first definition. opw-2254193 Forward-Port-Of: odoo/enterprise#10693
Original PR description
Go in Documents App Select some tags from the left bar Create a Documents share Review the created share under Configuration>Shared Links Tags will be missing. This occur because of an error in the view: tags are defined twice, the second time invisible, thus conflicting with the first definition. opw-2254193 Forward-Port-Of: odoo/enterprise#10693