Thursday, April 20, 2023
57 changes · master
Enhancements to existing features
Employee lookup in HR contracts and attendance now supports searching by either registration number or employee name. This makes it faster for users to find the right employee when filtering or selecting HR records.
Original PR description
This change adds a filter_domain attribute to the employee_id field. The filter_domain is set to filter the employee_id based on either the registration number or name of the employee. This will allow for easier searching and filtering of employees in the system. task-3130593 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 update lets Odoo's internal web test helper accept more request options, such as query parameters. It makes automated tests easier to write and maintain without changing normal user-facing behavior.
Original PR description
**Current behavior before PR:** The odoo.tests.common.HttpCase.url_open method wraps requests.Session.get/post/head, but is unable to use the full range of their functionality. **Desired behavior after PR is merged:** It will be possible to run tests passing alternative kwargs, such as params. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Replaces #54868.
This update prepares the web editor so multiple users can work together more reliably in Knowledge articles, including when embedded Odoo views are inserted. It improves synchronization, protects non-editable embedded content, and helps avoid missing updates between collaborators.
Original PR description
# Editor changes to enable the collaborative mode in Knowledge Here are the necessary changes to make it possible to enable the collaborative mode in Knowledge. Knowledge commands introduce a new…
# Editor changes to enable the collaborative mode in Knowledge
Here are the necessary changes to make it possible to enable the collaborative
mode in Knowledge. Knowledge commands introduce a new kind of editor blocks:
`Behaviors`, which are OWL `Component` which need to be mounted. This mounting
is asynchronous and this has to be supported, while not all nodes are observed
by the editor, meaning that parts of a `Behavior` can be collaborative while
others may not.
The following is a brief introduction for every commit in this PR, check them
out individually for more detail.
### [FIX] web_editor: notify current step when joining a collaborator
- Inserting an embedded view from a module in an automated process happens as
soon as the first collaborator connect. This commit notifies the step for the
embedded view during the following collaborators connections (to be sure they
actually received it).
### [IMP] web_editor: fully implement oeProtected and oeTransientContent
- Those attributes will allow a fine control on which nodes are NOT observed by
the editor (`oeProtected="true"`), and which nodes are NOT saved/serialized
for collaboration by the editor (`oeTransientContent="true"`). It can be a
better choice than using `observerUnactive` which stops the observer for all
nodes of the editor, in case a node should never be observed.
### [IMP] web_editor: prevent 'insert' command unwrapping in root
- Modify the 'insert' command of the editor so that it does not unwrap nodes
when the selection is directly inside the editable ('root'). Unwrapping a
paragraph in that case would put text nodes as direct childs of the editable,
which is not desirable with the current implementation.
### [IMP] web_editor: add a hook for historyResetFromSteps
- When joining an `html_field` in collaborative mode, there is no way to know if
there are connected collaborators before actually making said connection. This
is a problem when we want to automate the insertion of an embedded view from
another module in Knowledge. With the hook, it is now possible to execute a
specific action as soon as a collaborator is joined.
### [IMP] web_editor: force load collaborative on form view
- The collaborative mode loads lazily with the focus by default. In Knowledge it
should start as soon as possible, therefore this commit adds an option to do
so.
### [IMP] web_editor: make mocha tests odoo modules
- Since `web_editor` tests were not odoo modules, it was not possible to import
dependencies from i.e. `web`. This commit addresses that.
### [IMP] web_editor: buffer external steps during Component rendering
- In a collaboration, when applying a step requiring a custom OWL `mount`
(which is asynchronous), further external steps should be buffered while the
rendering is done, in case those following external steps should concern
"rendered" nodes which are not yet present in the editor. Once all nodes are
rendered and present in the editor, further steps can be applied safely.
See odoo/enterprise#33483
See odoo/upgrade#4384Users can now use saved favorites inside Knowledge embedded views, making it easier to reuse preferred filters and views in shared content. This improves consistency and convenience when working with embedded Odoo data in Knowledge.
Original PR description
Purpose ======= Allow to use favorite in Knowledge embedded view. For that purpose, we need to hook some function in the web module (because the favorite are store in the view arch, and not with ir.filters records). Task-3251129
This update prepares the Knowledge app for real-time collaborative editing by making complex Knowledge blocks safer to render, save, and share between users. Collaboration is not enabled yet because related editor issues still need to be fixed, but the changes reduce future data-loss risk and improve readiness for multi-user editing.
Original PR description
# Implement the collaborative mode in Knowledge /!\ This PR does not enable the collaborative mode in Knowledge, because some collaborative errors are in the process of being fixed in the…
# Implement the collaborative mode in Knowledge /!\ This PR does not enable the collaborative mode in Knowledge, because some collaborative errors are in the process of being fixed in the `web_editor` module. see task: 3217965, as well as the traceback `InvalidStateError, failed to execute setRemoteDescription on RTCPeerConnection`, which will be investigated soon. In the meantime, the `collaborative` option of the html_field should stay `false`, because there is a risk of data loss as long as those bugs are present. Here are the necessary changes to make it possible to enable the collaborative mode in Knowledge. Knowledge commands introduce a new kind of editor blocks: `Behaviors`, which are OWL `Component` which need to be mounted. This mounting is asynchronous and this has to be supported, while not all nodes are observed by the editor, meaning that parts of a `Behavior` can be collaborative while others may not. The following is a brief introduction for every commit in this PR, check them out individually for more detail. ### [MOV] knowledge: move the abstract_behavior wysiwyg template - Move the abstract_behavior wysiwyg template with other similar templates in `knowledge_editor.xml` ### [IMP] knowledge: remove duplicate editor getter - The `get editor` was unnecessarily overrided with the same implementation. ### [IMP] knowledge: fully implement oeProtected and oeTransientContent - Those attributes will allow a fine control on which nodes are NOT observed by the editor (oeProtected="true"), and which nodes are NOT saved/serialized for collaboration by the editor (oeTransientContent="true"). It allows `Behavior` OWL lifecycle steps (like `onMounted`, `onPatched`) to not use the `observerUnactive` method to make changes in the editor, which was hazardous as some steps are asynchronous (so there could be a lock active during an asynchronous task). - Every `Behavior` is now `oeProtected="true"` by default, and can specify which of its sub-nodes are `oeProtected="false"` (meaning they should be observed by the editor and collaborative). - An usage example of `oeTransientContent="true"` is an embedded view, as its content is generated dynamically each time, and in the context of the current user, meaning that sharing those nodes in collaboration or saving them in the database does not make sense. - As OWL `mount` is asynchronous, this commit introduces a way to "pre-render" `Behaviors` in a `d-none` div aside the editable, so that the `Behavior` fully rendered can be inserted at once in the editable. (this is to avoid generating multiple `add` mutations during the rendering process, which could be decoupled in collaboration, breaking the rendering logic.) ### [IMP] knowledge: avoid OWL instructions in unprotected Behavior nodes - OWL template instructions can add empty text nodes in the DOM after rendering (i.e `t-if`, `t-else`). If those nodes are observed by the editor (under a `oeProtected="false"` parent), this means that functionnally identical content could have technical differences and not be considered the same by the editor. As such, the current solution is to avoid those instructions under a `oeProtected="false"` parent and handle conditional content manually in the `Component`. ### [IMP] knowledge: make articles structures collaborative - The /index command creates a block with content generated by OWL, so we are exactly in the case mentionned in the previous commit. That content should thus be handled outside of the OWL template. And this requirement is reinforced by the fact that we want to let the editor override those rendered nodes from a collaborator mutation (external step). (OWL crashes if its rendered nodes are modified without its consent). - Therefore this commit introduces the necessary changes for that command to work properly in collaboration. ### [IMP] knowledge: setup embedded view intersectionObserver in editable - The intersection observer for embedded views does not catch the moment when a "pre-rendered" node is moved from the `d-none` rendering zone to the editable. Therefore it is only set up once in the editable, with the usage of a temporary mutation observer. ### [IMP] knowledge: insert external embedded views in collaboration - When joining an html_field in collaborative mode, there is no way to know if there are connected collaborators before actually making said connection. This is a problem when we want to automate the insertion of an embedded view from another module in Knowledge. - This commit uses the hook introduced in `web_editor` to attempt the insertion a second time if the content received from the database where the embedded view was inserted the first time is reset from the currently active collaborator when the current user joins him in collaboration (`onHistoryResetFromSteps`). ### [IMP] knowledge: buffer external steps during Component rendering - In a collaboration, when applying a step requiring a custom OWL `mount` (which is asynchronous), further external steps should be buffered while the rendering is done, in case those following external steps should concern "rendered" nodes which are not yet present in the editor. Once all nodes are rendered and present in the editor, further steps can be applied safely. - This commit uses the option introduced in `web_editor` to provide a promise when it detects that a step added a new `Behavior` anchor node, and that promise will be resolved when the `Behavior` is fully rendered and ready. See odoo/odoo#104680 See odoo/upgrade#4384
Knowledge users can now save favorites such as default searches and groupings directly inside embedded views. These favorites stay specific to each embedded view, making repeated analysis easier without affecting other views.
Original PR description
Purpose ======= Support favorite in embedded views and be able to have default search, group by, etc... Specification ============= The favorite / default search - group by, are defined per view. It means that if you create a favorite for an embedded view, it won't be visible for the other views (even if they share the same parent). Technical ========= The favorite are saved in the HTML arch of the view, instead of creating real `ir.filters` records. The reason is that `ir.filters` are defined for an action, or for the entire model. Embedded view have no action and no id, they are just inserted into the HTML body. If we wanted to create a special model for that, we would have need to clean those records in a CRON, which means parsing HTML to know which view has been removed, etc. So it made more sens to store it in the arch (we remove the view from the body, we remove its filter as well). Task-3251129
The Knowledge app has been simplified by removing obsolete internal logic related to article favorites. This has no expected change for users, but it helps keep the codebase cleaner and easier to maintain.
Original PR description
Since e68d7b81a6403665355991e80ae5ab3e03260335, the inverse method for is_user_favorite field is not used anymore. This commit simply removes it. Task-3274933
Resolved issues and error corrections
Opening Discuss from a chat window now keeps the app name consistent in breadcrumbs. This prevents users from seeing a confusing "Unnamed" label when navigating to channel settings.
Original PR description
Before this commit, when opening Discuss from chat window and then accessing the settings page of a channel, the breadcrumb showed "Unamed" as the name of the App instead of "Discuss". This happens because the client action was not named when expanding the chat window by opening Discuss app.
Code cleanup and technical improvements
This update replaces older helper-library code with standard JavaScript across several Odoo apps. It should make the codebase easier to maintain and reduce reliance on legacy utilities, with little to no visible change for users.
Original PR description
Replaced _.map(), _.flatten(), _.delay(), _.contains(), _.pluck(), _.isUndefined(), _.isEmpty(), _.isString(), _.isEqual(), _.isBoolean(), _.memoize(), _.invoke(), _.bind(), _.escape(), _.debounce(), _.str.sprintf(), _.str.repeat(), _.str.startswith(), _.str.trim(), _.str.escapeHTML(), _.str.escapeRegExp(), _.str.startsWith(), _.str.include() I had some troubles with _.escape() in legacy so I don't replace its. Description of the refactoring this PR addresses: Current behavior before PR: There are underscore.js function enumerated above used in odoo. Desired behavior after PR is merged: These functions has been replaced by native javascript prototypes/methods/functions. TaskId : 3246238 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
odoo/odoo#111651 improved and optimised triggers but dropped the in-place cleanup of field dependencies. As a consequence, during module uninstallation if a stored computed field is removed (because it's part of a module being uninstalled), and one of its dependencies is subsequently altered (e.g. it's itself removed, or written to) the second update will break as the query trying to find out which dependent records to update will error, either because of trying to select / filter on a missing c
Original PR description
odoo/odoo#111651 improved and optimised triggers but dropped the in-place cleanup of field dependencies. As a consequence, during module uninstallation if a stored computed field is removed (because…
odoo/odoo#111651 improved and optimised triggers but dropped the in-place cleanup of field dependencies. As a consequence, during module uninstallation if a stored computed field is removed (because it's part of a module being uninstalled), and one of its dependencies is subsequently altered (e.g. it's itself removed, or written to) the second update will break as the query trying to find out which dependent records to update will error, either because of trying to select / filter on a missing column, or because of trying to fetch in a missing table. The simplest examples of this issue are computed fields with a dependency on `ir.model`: - In `calendar`, `calendar.event.res_model` is a related on `res_model_id.model`, this prevents the removal of *any* `ir.model` record if it gets uninstalled. As a result the `calendar.attendee` and `calendar.event` tables don't get removed (just emptied of all their non-automatic fields), their records remain as well, and when the non-automatic fields get re-added during installation re-instating the NOT NULL constraints fails, breaking the uninstall/reinstall test. - In `payment`, `payment.provider.module_state` is a related on `module_id.state`, this breaks *during* uninstallation, as after `module_uninstall` first calls `_module_data_uninstall` which removes the field, then it *updates the modules being uninstalled* (sets their state), which tries to find out which `payment.provider`'s `module_state` is should update, which breaks because the `module_id` column has been removed. This second one was worked around in odoo/odoo#118900, by marking modules as uninstalled before actually gutting them, but as it turns out the "actual" fix is needed anyway. So revert the workaround, and actually fix the issue. Forward-Port-Of: odoo/odoo#119080
This fixes a visual glitch where the “read more” button briefly appeared while users quickly created a new Kanban card. The change makes the Kanban view feel smoother and avoids momentary confusion during record creation.
Original PR description
Before this commit, when quick creating a new record in a kanban view, the "read more" button is briefly shown (flickering). This issue occurs because, when creating a new record, we increment the number of records in the group before adding the record to the list of displayed records. This means that for a brief moment the number of records of the group is bigger than the number of displayed records, therefore the "load more" button is show. Now, we increment the number of records on the group after we added the record to the displayed records' list.
Opening Discuss from a chat window now keeps the app name set correctly when users navigate to channel settings. This prevents the breadcrumb from showing an unclear “Unnamed” label, making navigation clearer and more professional.
Original PR description
Before this commit, when opening Discuss from chat window and then accessing the settings page of a channel, the breadcrumb showed "Unamed" as the name of the App instead of "Discuss". This happens because the client action was not named when expanding the chat window by opening Discuss app.
This fixes an issue where selecting fields such as Sales Team on mobile could show the wrong list view in newer Odoo versions. The change updates how related kanban views are referenced so users see the intended selection interface across Sales, CRM, POS Sales, and website sales flows.
Original PR description
Steps to reproduce: - Install Sales. - Go to any quotation and toggle mobile device mode in the browser. - Go to Other Info > click in Sales Team field. Issue: We stop supporting the 'kanban_view_ref' in newer versions of odoo. So we won't be able to get proper view. Solution: Changed the way we ref the kanban view to use context to get the referenced kanban view. Related to #[39499](https://github.com/odoo/enterprise/pull/39499) opw-3152174
Manufacturing orders for serial-tracked products can now be completed correctly after using Mass Produce. This prevents an error that blocked users from validating split production orders, helping production teams finish batches without manual workarounds.
Original PR description
Description of the issue/feature this PR addresses: Issue : When mass producing a tracked product, an User Error is raised on validation of splitted MO. Reproduction : - Create Serial storable product "Component A", Lot storable product "Component B", Serial Storable product "Finished Serial Product" - Immediate Transfer 10 * "Component A" and 20 * "Component B" - Create a BoM for "Finished Serial Product", consuming 1 * "Component A" and 2 * "Component B" - Create a Manufacturing Order for 10 * "Finished Serial Product" and Confirm - Click on "Mass Produce", Set "First SN", Generate all the serials and Apply - Click on "Produce All" on the splitted MO Current behavior before PR: User Error Desired behavior after PR is merged: Working fine Task : 3274962 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update keeps PDF-related font handling working with newer versions of the fonttools library. It helps avoid failures when generating or processing PDFs after dependency updates, with no expected change to normal user workflows.
Original PR description
Support recent version of fonttools. In particular, class `_TTGlyphSet` was refactored between 4.37.1 and 4.37.2 and no longer has an `_htmx` attribute. Instead, the new attribute `hMetrics` can be used to get the metrics from htmx. see: https://github.com/fonttools/fonttools/compare/4.37.1...4.37.2
The chat window now shows a subtle divider between the header and message content when content is present. This makes the interface easier to read and reduces visual confusion for users.
Original PR description
Before this commit, content inside chat window could visually fuse with the header in a way that makes it hard to see the separation between the header and the content. This commit fixes the issue by adding a small border below header when there is some content. Before/After <img width="341" alt="before-w" src="https://user-images.githubusercontent.com/6569390/233338963-78705781-5653-4d05-9c5e-0a78cdd19435.png"> <img width="340" alt="after-w" src="https://user-images.githubusercontent.com/6569390/233338988-1f463737-7804-4b92-a372-1fb1c36c1283.png"> <img width="347" alt="before-d" src="https://user-images.githubusercontent.com/6569390/233339057-057eff6d-bfdb-4e6f-bb25-b7a4afdc3525.png"> <img width="338" alt="after-d" src="https://user-images.githubusercontent.com/6569390/233339088-7be3371f-18a2-4da1-b5ad-72055116968c.png">
This fix prevents parts of a website table of contents block from being dragged outside of their original block. It helps avoid broken page navigation when editors arrange content in the website builder.
Original PR description
In the table of content snippet, both its generated entries and its content wrapper can be dropped outside of it. This cannot be allowed because the entries are generated from the wrapped content that belongs to the same table of content snippet. If any of them is missing, the feature is broken. This commit prevents this by hiding the drag handle from the generated table of content and from the content wrapper. Note that they can still be moved using the arrows. task-2752391
This fixes an issue in the Mail app where clicking a reply preview could trigger across an overly wide area of the conversation. The clickable area now matches the reply text itself, making message interactions more predictable and reducing accidental clicks.
Original PR description
Before this commit, clickable of a reply-to message mistakenly extended all the way to the other end of the conversation. # Before <img width="980" alt="Screenshot 2023-04-20 at 16 15 11" src="https://user-images.githubusercontent.com/6569390/233393944-eeed82d4-5334-47c9-b23d-8994f29abfc7.png"> # After <img width="978" alt="Screenshot 2023-04-20 at 16 11 06" src="https://user-images.githubusercontent.com/6569390/233393731-f6671292-ab3d-4eda-8621-38ad74e38058.png">
A recent internal refactoring accidentally removed handling for simple notification alerts used by several Odoo apps. This fix restores those alerts so users continue to see important messages with the expected warning or danger level.
Original PR description
* = base_geolocalize, calendar, website_crm_partner_assign Oversight of discuss refactoring. Code is restored into bus module as it does not depend on any mail or discuss feature. ----- Note: default type (unless `warning` was specified) was `danger` before https://github.com/odoo/odoo/blob/5da763a8ef0503286fa5cc55e32970f4d785825a/addons/mail/static/src/models/messaging_notification_handler.js#L429 and now the default from notification service is kept (it is `warning`) so `danger` is added in code to keep the same behavior.
Odoo Studio now correctly ignores fields that a user is not allowed to access when opening or editing views. This prevents access rights errors and lets users continue working in Studio even when a view contains restricted fields.
Original PR description
Commit @baebb6a5b05ac8d59501a6071a5513e31a4ca047 introduced a universal way to handle multiple instances of the same field in a view arch. To do so, it separates what fields are to be fetched (activeFields) from the "instances" of those fields in the arch (fieldNodes). Studio's code was only partially ready, relying on the fact that the key for fieldNode was the field's name, which isn't true any longer. This commit fixes that, and removes from the fieldNodes the ones that have studio_no_fetch and more importantly removes them from activeFields. To reproduce: have a field with a group declared in python, which the user doesn't have. Open studio with a view that has that field in the arch. Before this commit, there was an access rights crash. After this commit, there is no crash.
Users can now insert links to Odoo menus in spreadsheets without being unexpectedly sent back to the Odoo home page. The menu picker also better reflects the currently selected item and includes apps, making accidentally removed app links easier to restore.
Original PR description
This PR fixes the problem when inserting a link to an odoo menu, clicking the menu item in the dropdown will jump to odoo home page, and the insertion fails. The root cause is the menu item uses `a` tag and has a `href` leading to home page. The solution is to prevent the default clicking behavior. This PR also fixs a small bug of showing currently selected menu item. task [3159543](https://www.odoo.com/web#id=3159543&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This fix ensures selection popups, such as choosing a sales team on a quotation in mobile view, open with the correct layout in newer Odoo versions. It updates affected areas to use the supported method for loading kanban-style selection views, preventing broken or unsuitable displays.
Original PR description
Steps to reproduce: - Install Sales. - Go to any quotation and toggle mobile device mode in the browser. - Go to Other Info > click in Sales Team field. Issue: We stop supporting the 'kanban_view_ref' in newer versions of odoo. So we won't be able to get proper view. Solution: Changed the way we ref the kanban view to use context to get the referenced kanban view. Related to #[116031](https://github.com/odoo/odoo/pull/116031) opw-3152174
Inviting people to a Knowledge article no longer duplicates the article name in the breadcrumb trail. The invite window now stays open after sending invitations so users can see confirmation, while the relevant panels refresh only when needed.
Original PR description
Purpose: - Currently, after inviting someone to an article using the invite modal, the article is added to the breadcrumbs even though we stay on the same article (we thus have the same article name twice in the breadcrumbs). This happens because the `action_invite_members` action returns an action window to reload the form view (to reload the sidebar in case the article went from private to shared). After this commit, the action won't return an action window anymore, but closing the invite modal will reload the permission panel and the sidebar only if the article changed from category. This also allows to keep the invite modal open after inviting new members on an article, allowing the user to get a visual feedback that the members have been invited. Task-3159149
Before this commit, when opening Discuss from chat window and then accessing the settings page of a channel, the breadcrumb showed "Unamed" as the name of the App instead of "Discuss". This happens because the client action was not named when expanding the chat window by opening Discuss app. Forward-Port-Of: odoo/odoo#119121 Forward-Port-Of: odoo/odoo#118941
Original PR description
Before this commit, when opening Discuss from chat window and then accessing the settings page of a channel, the breadcrumb showed "Unamed" as the name of the App instead of "Discuss". This happens because the client action was not named when expanding the chat window by opening Discuss app. Forward-Port-Of: odoo/odoo#119121 Forward-Port-Of: odoo/odoo#118941
This commit allows to reopen submenus and mega menus if one of them was opened when scrolling on a page of a website. Steps to reproduce the bug fixed by this commit. - Have a submenu or a mega menu in the navbar - Open a dropdown of the navbar - Scroll down => It is no longer possible to open the dropdown. This commit fixes this issue and adds a test for this flow. --- Since the upgrade to Bootstrap 5 and especially since this [BS5 commit], there is a gap between the mega me
Original PR description
This commit allows to reopen submenus and mega menus if one of them was opened when scrolling on a page of a website. Steps to reproduce the bug fixed by this commit. - Have a submenu or a mega menu…
This commit allows to reopen submenus and mega menus if one of them was opened when scrolling on a page of a website. Steps to reproduce the bug fixed by this commit. - Have a submenu or a mega menu in the navbar - Open a dropdown of the navbar - Scroll down => It is no longer possible to open the dropdown. This commit fixes this issue and adds a test for this flow. --- Since the upgrade to Bootstrap 5 and especially since this [BS5 commit], there is a gap between the mega menu and the navbar when the user opens a mega menu. This commit removes that gap. Steps to reproduce the bug fixed by this commit: - Have a mega menu on your website. - Drop a block of a dark color at the top of the page (it helps to see the problem). => When you open the mega menu, you can see a small piece of the block of dark color between the navbar and the mega menu. Technical explanation: This [BS5 commit] introduces a new css rule that adds a `margin-top: 0.125rem;` on the `.dropdown-menu[data-bs-popper]`. However when [mega menus were introduced], another css rule prevents having a gap between the nav and the mega menu (`margin-top: 0;` on `.o_mega_menu`). This commit makes sure that it will be a `margin-top` of 0 by making the property more important. BEFORE:  AFTER:  [BS5 commit]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3 [mega menus were introduced]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7 --- Since [this commit], a horizontal scrollbar appears on mega menus. This is because Bootstrap position the dropdown automatically and the dropdown is no more aligned to the left. This commit fixes the issue by restoring the class that positions the dropdown to the left. Steps to reproduce: - Have a system setting that enlarges the texts size or zoom the page - Have a mega menu - Open the mega menu => There is a horizontal scrollbar. [this commit]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914 --- task-3133137 opw-3226013 Forward-Port-Of: odoo/odoo#117070
Current behavior: When printing a bill in the restaurant you had an error poping. Steps to reproduce: - Open a restaurant session - Go on a table and add some products - Click on the bill button - Click on the print button - You get an error opw-3259014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118756
Original PR description
Current behavior: When printing a bill in the restaurant you had an error poping. Steps to reproduce: - Open a restaurant session - Go on a table and add some products - Click on the bill button - Click on the print button - You get an error opw-3259014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118756
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in bom while creating Manufacturing Order and confirming it, KeyError will be generated. Steps to Produce:- 1) Create a new product, create bom for that product, add components, and create or add at least 2 operations to the BoM. 2) In the components of 'Consumed in Operation' add the newly created operation. 3) Now, Archive one operation. 4) Create new Manufacturing Order with a newly created BOM 5) Tr
Original PR description
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in bom while creating Manufacturing Order and confirming it, KeyError will be generated. Steps to Produce:- 1) Create a…
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in bom while creating Manufacturing Order and confirming it, KeyError will be generated. Steps to Produce:- 1) Create a new product, create bom for that product, add components, and create or add at least 2 operations to the BoM. 2) In the components of 'Consumed in Operation' add the newly created operation. 3) Now, Archive one operation. 4) Create new Manufacturing Order with a newly created BOM 5) Try to confirm it. KeyError will be generated. By applying this, if there are no operations left after archiving one linked to the component then the server error won't occur sentry - 4042593205 See:-  sentry - 4042593205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117335
Calling `fetch` with 'id' in the `fields_name`, will always generate SQL query even if all requested field values are in the cache. This is because we also look for values in the 'id' field cache, but we don't ever fill the cache for `Id` fields. Forward-Port-Of: odoo/odoo#119086
Original PR description
Calling `fetch` with 'id' in the `fields_name`, will always generate SQL query even if all requested field values are in the cache. This is because we also look for values in the 'id' field cache, but we don't ever fill the cache for `Id` fields. Forward-Port-Of: odoo/odoo#119086
This commit prevent the reset of password for de-activated partner Also, change the _compute_token to be able to work in the context of an onchange Forward-Port-Of: odoo/odoo#119085
Original PR description
This commit prevent the reset of password for de-activated partner Also, change the _compute_token to be able to work in the context of an onchange Forward-Port-Of: odoo/odoo#119085
Before this commit, The audio context used in media_monitoring was not closed. Which could lead to memory leaks. The source was not connected to the destination in the script processor (used in old browsers that do not support audioWorklets), which would prevent the monitored audio to be used as an audio source. Forward-Port-Of: odoo/odoo#119036 Forward-Port-Of: odoo/odoo#119014
Original PR description
Before this commit, The audio context used in media_monitoring was not closed. Which could lead to memory leaks. The source was not connected to the destination in the script processor (used in old browsers that do not support audioWorklets), which would prevent the monitored audio to be used as an audio source. Forward-Port-Of: odoo/odoo#119036 Forward-Port-Of: odoo/odoo#119014
In this paragraph, we are trimming the string and then converting it to an int type. But there is no guarantee that value_string can be converted to int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118299
Original PR description
In this paragraph, we are trimming the string and then converting it to an int type. But there is no guarantee that value_string can be converted to int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118299
Use case to reproduce: - Set "receive good in input and then stock" on the warehouse. - Set two suppliers on a product. one from a partner (higher priority) and one from a child partner (lower priority). - Set the child partner as the vendor on the replenishment report. - Order a replenishment for the product. It happens due to an hack that use a field on `stock.move` in order to temporaly store the partner among the moves until the RFQ. But this field is a many2one on `res.partner` model
Original PR description
Use case to reproduce: - Set "receive good in input and then stock" on the warehouse. - Set two suppliers on a product. one from a partner (higher priority) and one from a child partner (lower…
Use case to reproduce: - Set "receive good in input and then stock" on the warehouse. - Set two suppliers on a product. one from a partner (higher priority) and one from a child partner (lower priority). - Set the child partner as the vendor on the replenishment report. - Order a replenishment for the product. It happens due to an hack that use a field on `stock.move` in order to temporaly store the partner among the moves until the RFQ. But this field is a many2one on `res.partner` model and not on `product.supplierinfo` `_run_buy` receive a partner and still use `_select_seller` with the partner in order to find the best pricelist. But it won't use the specific supplier price list set on the orderpoint. In order to fix, we don't store anymore the price list partner on the intermediate move. In run_buy we receive the orderpoint if it's the origin of the procurement. On the orderpoint the supplierinfo is set. So we take it from there. opw-3180945 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#118890 Forward-Port-Of: odoo/odoo#114845
Description of the issue/feature this PR addresses: When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error. If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template. So, all activity schedules triggered from an orderpoint
Original PR description
Description of the issue/feature this PR addresses: When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering…
Description of the issue/feature this PR addresses: When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error. If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template. So, all activity schedules triggered from an orderpoint should be created without checking access rights Current behavior before PR:  Desired behavior after PR is merged: Confirm MO without any inconvenient. Comments: This is possibly not the entirely correct solution, but I am opening this PR to be reviewed and a complete solution to the problem found. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118300
If applied, this commit will solve the issue of the singleton when there are 2 quants with the same location and same products but one quant with a lot and another quant without a lot number. Steps to produce: - Create one quant with location-1 and without lot number. - Create another quant with location-1 but with the lot number. - Create 3rd quant with location-1 with same lot number as step2. The error will raise in 3rd step as it is not accepting the 2 quants where one is with lot numb
Original PR description
If applied, this commit will solve the issue of the singleton when there are 2 quants with the same location and same products but one quant with a lot and another quant without a lot number. Steps to produce: - Create one quant with location-1 and without lot number. - Create another quant with location-1 but with the lot number. - Create 3rd quant with location-1 with same lot number as step2. The error will raise in 3rd step as it is not accepting the 2 quants where one is with lot number and another is without lot number. see - https://tinyurl.com/2hqrgmwm sentry - 4024572562 Forward-Port-Of: odoo/odoo#116318
**Steps to reproduce the bug:** - Install purchase, then mrp (in this order) - Create a storable product “P1” - route: buy - Add a supplier - Add a BoM - Create a delivery for the product “P1” - A need is created - Go to inventory > operation > replenishment **Problem:** An orderpoint is created with the preferred route: Manufacture instead of buy As the "Purchase" module was installed first, the override of the `_set_default_route_id` function will be triggered firs
Original PR description
**Steps to reproduce the bug:**
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
**Problem:**
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
Forward-Port-Of: odoo/odoo#119067On a multi warehouse configuration where a warehouse view_location is a parent of an other warehouse's view_location this will now compute the closest warehouse of a location, a not the warehouse with lowest sequence. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118128
Original PR description
On a multi warehouse configuration where a warehouse view_location is a parent of an other warehouse's view_location this will now compute the closest warehouse of a location, a not the warehouse with lowest sequence. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118128
Before this commit the "This page" menu sub-section of the website's menu is displayed as a clickable entry when it is empty. After this commit any website custom menu sub-section title entry is hidden if none of its children is displayed. Steps to reproduce: - Install website only - Log in as a restricted editor - Go to website - Open the "Site" menu => "This page" appears as a clickable entry instead of being hidden. task-3149639 Forward-Port-Of: odoo/odoo#111576
Original PR description
Before this commit the "This page" menu sub-section of the website's menu is displayed as a clickable entry when it is empty. After this commit any website custom menu sub-section title entry is hidden if none of its children is displayed. Steps to reproduce: - Install website only - Log in as a restricted editor - Go to website - Open the "Site" menu => "This page" appears as a clickable entry instead of being hidden. task-3149639 Forward-Port-Of: odoo/odoo#111576
Unsupported operand type(s) for +: 'NoneType' and 'relativedelta' occur when we create payment terms without a preview date (date_ref). This is because date_ref has no value. Steps to produce: - Open any payment term - Remove example date - Traceback Generated Traceback on sentry: ``` TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta' File "odoo/http.py", line 2106, in __call__ response = request._serve_db() File "odoo/http.py", line 1689, in _ser
Original PR description
Unsupported operand type(s) for +: 'NoneType' and 'relativedelta' occur when we create payment terms without a preview date (date_ref). This is because date_ref has no value. Steps to produce: - Open…
Unsupported operand type(s) for +: 'NoneType' and 'relativedelta' occur when we
create payment terms without a preview date (date_ref). This is because date_ref has no value.
Steps to produce:
- Open any payment term
- Remove example date
- Traceback Generated
Traceback on sentry:
```
TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta'
File "odoo/http.py", line 2106, in __call__
response = request._serve_db()
File "odoo/http.py", line 1689, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1716, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1913, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 708, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 6528, in onchange
todo = [
File "odoo/models.py", line 6531, in <listcomp>
if name not in done and snapshot0.has_changed(name)
File "odoo/models.py", line 6314, in has_changed
return self[name] != record[name]
File "odoo/models.py", line 5920, in __getitem__
return self._fields[key].__get__(self, type(self))
File "odoo/fields.py", line 1209, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4290, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 99, in determine
return needle(*args)
File "addons/account/models/account_payment_term.py", line 95, in _compute_example_preview
terms = record._compute_terms(
File "addons/account/models/account_payment_term.py", line 202, in _compute_terms
'date': line._get_due_date(date_ref),
File "addons/account/models/account_payment_term.py", line 271, in _get_due_date
return due_date + relativedelta(days=self.nb_days)
```
This commit solves the issue by adding a condition if date_ref is not
available, so it adds current date instead of it.
sentry-4068322613
Forward-Port-Of: odoo/odoo#118768
Forward-Port-Of: odoo/odoo#118027The new SampleServer class was introduced in https://github.com/odoo/odoo/commit/c67b9f9907e85019b6adac80976569553f5e6b7a without dedicated tests. We fix this oversight. Forward-Port-Of: odoo/odoo#118914 Forward-Port-Of: odoo/odoo#118775
Original PR description
The new SampleServer class was introduced in https://github.com/odoo/odoo/commit/c67b9f9907e85019b6adac80976569553f5e6b7a without dedicated tests. We fix this oversight. Forward-Port-Of: odoo/odoo#118914 Forward-Port-Of: odoo/odoo#118775
before this commit: record = env['model.name'].browse(id) if record doesn't exist in the database and call record.translated_field_name = value Then _get_stored_translation will raise TypeError: 'NoneType' object is not subscriptable after this commit: like write non-translated field, the value can be written to the cache, but not the database and no error will be raised Note: The feature is only for the original ORM 'write', if the 'overriden write' reads other fields of
Original PR description
before this commit:
record = env['model.name'].browse(id)
if record doesn't exist in the database and call
record.translated_field_name = value
Then _get_stored_translation will raise
TypeError: 'NoneType' object is not subscriptable
after this commit:
like write non-translated field, the value can be written to the cache, but not the database and no error will be raised
Note: The feature is only for the original ORM 'write', if the 'overriden write'
reads other fields of the non-existing record, a MissingError will be raised.
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#118673When we compare majorless scripts we must ignore the Odoo version. Otherwise a module upgrade without major Odoo upgrade would fail to run local scripts majorless scripts. That's what happens for example when users click the upgrade button of a module. Example: upgrade from `11.0.1.0` to `11.0.2.0`, with a local `2.0` folder for upgrades. ``` 11.0.1.0 < 11.0.2.0 < 11.0.2.0 -> False (check before this patch) 1.0 < 2.0 <= 2.0 -> True (check with this patch) ``` While still:
Original PR description
When we compare majorless scripts we must ignore the Odoo version. Otherwise a module upgrade without major Odoo upgrade would fail to run local scripts majorless scripts. That's what happens for example when users click the upgrade button of a module.
Example: upgrade from `11.0.1.0` to `11.0.2.0`, with a local `2.0` folder for upgrades.
```
11.0.1.0 < 11.0.2.0 < 11.0.2.0 -> False (check before this patch)
1.0 < 2.0 <= 2.0 -> True (check with this patch)
```
While still: upgrade from `11.0.2.0` to `12.0.2.0`
```
11.0.2.0 < 12.0.2.0 < 12.0.2.0 -> False (before this patch)
2.0 < 2.0 <= 2.0 -> False (with this patch)
```
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#119027Filtering by binary fields is useful, for example, to find products without image. The feature is available in v15, but in v16 it's disappeared after refactoring. Fix it by adding basic operators for the binary fields: "is set", "is not set" (same as in v15). opw-3084273 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/subm
Original PR description
Filtering by binary fields is useful, for example, to find products without image. The feature is available in v15, but in v16 it's disappeared after refactoring. Fix it by adding basic operators for the binary fields: "is set", "is not set" (same as in v15). opw-3084273 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#109414
Forward-Port-Of: odoo/odoo#119157
Original PR description
Forward-Port-Of: odoo/odoo#119157
Calling `fetch` with computed fields will also check that the dependencies of those fields are fetched, which is good. This commit adds a check that verifies that all the dependencies are already fetched before re-fetching them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119182
Original PR description
Calling `fetch` with computed fields will also check that the dependencies of those fields are fetched, which is good. This commit adds a check that verifies that all the dependencies are already fetched before re-fetching them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119182
In the Dashboard app, expenses KPI amounts are currently expressed in the currency they were made in, but with the currency symbol of the company currency. It also means amounts with different currencies are aggregated. We want the KPI to be expressed in the company currency and not in the expense currency. Note that even with this commit, the amounts are still mixing different currencies if multiple companies are active Task 3266092 --- I confirm I have signed the CLA and read
Original PR description
In the Dashboard app, expenses KPI amounts are currently expressed in the currency they were made in, but with the currency symbol of the company currency. It also means amounts with different currencies are aggregated. We want the KPI to be expressed in the company currency and not in the expense currency. Note that even with this commit, the amounts are still mixing different currencies if multiple companies are active Task 3266092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118537 Forward-Port-Of: odoo/odoo#118017
See accompanying PR: https://github.com/odoo/enterprise/pull/40074 The current view replaces the existing groups attribute of the inventory page in the product template form view with two specified groups (with only one of these groups being newly introduced in stock). This commit changes the product view to utilise an xpath that adds the single new group (stock.group_stock_user), instead of replacing the content of the attributes. Forward-Port-Of: odoo/odoo#119200
Original PR description
See accompanying PR: https://github.com/odoo/enterprise/pull/40074 The current view replaces the existing groups attribute of the inventory page in the product template form view with two specified groups (with only one of these groups being newly introduced in stock). This commit changes the product view to utilise an xpath that adds the single new group (stock.group_stock_user), instead of replacing the content of the attributes. Forward-Port-Of: odoo/odoo#119200
See accompanying PR: https://github.com/odoo/odoo/pull/119200 A previous commit (c090562) added the "group_account_invoice" group to the inventory page of the product view. This meant that, when account_intrastat is installed, users with the account_invoice group would be able to see and edit the weight and volume of a product (on the inventory tab of the product form view). However there is a typo (`seperator` should be `separator`), though this doesn't actually matter since the default v
Original PR description
See accompanying PR: https://github.com/odoo/odoo/pull/119200 A previous commit (c090562) added the "group_account_invoice" group to the inventory page of the product view. This meant that, when account_intrastat is installed, users with the account_invoice group would be able to see and edit the weight and volume of a product (on the inventory tab of the product form view). However there is a typo (`seperator` should be `separator`), though this doesn't actually matter since the default value of the separator in odoo/tools/template_inheritance.py is a comma. This commit corrects this typo (it is better to have it explicitly defined) and an associated commit in stock will prevent this xpath from being replaced (and instead add to the xpath). Forward-Port-Of: odoo/enterprise#40074
The views were split from a single file to a file per model in odoo/enterprise#35602, but the `payslip_run_views.xml` was not added to the manifest. Forward-Port-Of: odoo/enterprise#40046
Original PR description
The views were split from a single file to a file per model in odoo/enterprise#35602, but the `payslip_run_views.xml` was not added to the manifest. Forward-Port-Of: odoo/enterprise#40046
Before, if the private car reimbursed amount advantage was archived, the input would not be displayed in the contract web form. However, `onchangeCompanyCar` and `onchangePrivateCar` both expected the other field to always exist. This would throw a: `Cannot read properties of undefined (reading 'checked')` when trying to evaluate `private_car_input[0].checked`. The solution is to make sure that the jquery request returns something before evaluating. opw-3236066 Forward-Port-Of: odoo/en
Original PR description
Before, if the private car reimbursed amount advantage was archived, the input would not be displayed in the contract web form. However, `onchangeCompanyCar` and `onchangePrivateCar` both expected the other field to always exist. This would throw a: `Cannot read properties of undefined (reading 'checked')` when trying to evaluate `private_car_input[0].checked`. The solution is to make sure that the jquery request returns something before evaluating. opw-3236066 Forward-Port-Of: odoo/enterprise#39971
When the user does not have access to any article or there is no article in the database, the editor view of Knowledge will not be able to load an article and will display a no-content helper to invite people to create a new article. With the recent changes, there are two issues with the interface: 1. A banner appears above the no-content helper saying: "This article is only displayed to its members.". It makes no sens to display this banner as the view didn't load any record/article. 2. Whe
Original PR description
When the user does not have access to any article or there is no article in the database, the editor view of Knowledge will not be able to load an article and will display a no-content helper to…
When the user does not have access to any article or there is no article in the database, the editor view of Knowledge will not be able to load an article and will display a no-content helper to invite people to create a new article. With the recent changes, there are two issues with the interface: 1. A banner appears above the no-content helper saying: "This article is only displayed to its members.". It makes no sens to display this banner as the view didn't load any record/article. 2. When hovering the "New" button of the header, the interface will reveal the buttons to add an icon, a cover or a new property field. Some of those buttons will issue a RPC call on the server using the id of the active record. As the view did not load any record, the id will be undefined and the user will get an error when interacting with those buttons. This commit will hide the banner and the buttons "Add Icon", "Add Cover", "Add Property" when the view didn't load any record. The issue has been introduced unintentionally during the refactoring of the top bar. The view will then look like how it used to be in Odoo 16.1. task-3254882 Forward-Port-Of: odoo/enterprise#39106
### Before this commit: `suitable_sale_order_ids` is populated with all `done` pickings when returning a transfer without a `ticket_id`, which crashes the frontend upon loading. ### Steps to reproduce: 1. Install Stock & Helpdesk 2. Create thousands of sale orders and mark them as done 3. Return a transfer ### After this commit: Similarly to how `suitable_picking_ids` was fixed in [e764792], set `suitable_sale_order_ids` to False when the transfer doesn't have a `ticket_id`,
Original PR description
### Before this commit: `suitable_sale_order_ids` is populated with all `done` pickings when returning a transfer without a `ticket_id`, which crashes the frontend upon loading. ### Steps to reproduce: 1. Install Stock & Helpdesk 2. Create thousands of sale orders and mark them as done 3. Return a transfer ### After this commit: Similarly to how `suitable_picking_ids` was fixed in [e764792], set `suitable_sale_order_ids` to False when the transfer doesn't have a `ticket_id`, as the fields are not used in that case anyway. opw-3277004 [e764792]: https://github.com/odoo/enterprise/commit/e7647925addaad81891745d9e06e86bd8965883b Forward-Port-Of: odoo/enterprise#40015
As gstr2b_json_from_portal_ids attachments are created by odooBot it doesn't allow the user who has access right as Accountant but not administrator to view the document. Hence removing it in the view will solve the issue. opw-3275784 Forward-Port-Of: odoo/enterprise#40014
Original PR description
As gstr2b_json_from_portal_ids attachments are created by odooBot it doesn't allow the user who has access right as Accountant but not administrator to view the document. Hence removing it in the view will solve the issue. opw-3275784 Forward-Port-Of: odoo/enterprise#40014
When 'Download XSD files to CFDI' scheduled action is called it loads all the xsd files from the URL and gets stored in attachment. If a xsd file is not properly loaded, system gives the error. see this traceback : https://tinyurl.com/2fsb23cr steps to reproduce : 1. Install l10n_mx_edi module if not installed. 2. open scheduled actions and run 'Download XSD files to CFDI' this action. 3. the error will occur. Applying this commit will resolve this issue. sentry-403236
Original PR description
When 'Download XSD files to CFDI' scheduled action is called it loads all the xsd files from the URL and gets stored in attachment. If a xsd file is not properly loaded, system gives the error.
see this traceback : https://tinyurl.com/2fsb23cr
steps to reproduce :
1. Install l10n_mx_edi module if not installed.
2. open scheduled actions and run 'Download XSD files to CFDI' this action.
3. the error will occur.
Applying this commit will resolve this issue.
sentry-4032367685
Forward-Port-Of: odoo/enterprise#39010Before this commit, when accessing to an expired share url it raised an internal server error due to a qweb syntax error. This commit fix this bug by including the required variables that led to the error... The variables needed are to construct a share_redirect_URL in case of login or logout. Task-3231376 Forward-Port-Of: odoo/enterprise#38237
Original PR description
Before this commit, when accessing to an expired share url it raised an internal server error due to a qweb syntax error. This commit fix this bug by including the required variables that led to the error... The variables needed are to construct a share_redirect_URL in case of login or logout. Task-3231376 Forward-Port-Of: odoo/enterprise#38237
The cron to automatically reconcile bank statement lines processes statement lines by batch ordered "cron_last_check" NULL first then DESC then update the "cron_last_check". In this way the cron can be "blocked" processing each time the same invalid batch because those lines will stay at the most recent "cron_last_check" and do not process lines with an older "cron_last_check" that could be valid. This commit changes the order we get lines to process to "cron_last_check" ASC and keeps NULL
Original PR description
The cron to automatically reconcile bank statement lines processes statement lines by batch ordered "cron_last_check" NULL first then DESC then update the "cron_last_check". In this way the cron can be "blocked" processing each time the same invalid batch because those lines will stay at the most recent "cron_last_check" and do not process lines with an older "cron_last_check" that could be valid. This commit changes the order we get lines to process to "cron_last_check" ASC and keeps NULL first. This allow to cycle through the lines last checked first. opw-3248777 Forward-Port-Of: odoo/enterprise#39566
Links: The journal dashboard has two links to the bank recon: the journal name, and the reconcile button. Both lead to the same place but don't match in terms of filters and domains. This commits removes the domain filter and applies a search_default instead - aligning to the reconcile button. Table Layout: Prevent the horizontal scroll on the Bank Recons lines when the partner or label are too long. Use Ellipses instead. AML Filters: Combine payable and receivable filters in Customer
Original PR description
Links: The journal dashboard has two links to the bank recon: the journal name, and the reconcile button. Both lead to the same place but don't match in terms of filters and domains. This commits…
Links: The journal dashboard has two links to the bank recon: the journal name, and the reconcile button. Both lead to the same place but don't match in terms of filters and domains. This commits removes the domain filter and applies a search_default instead - aligning to the reconcile button. Table Layout: Prevent the horizontal scroll on the Bank Recons lines when the partner or label are too long. Use Ellipses instead. AML Filters: Combine payable and receivable filters in Customer/Vendor Add a filter for miscellaneous journal entries View Partner: Allow to open the partner form from the Manual Operations tab Rename Statement Line Filters: Received -> Incoming Paid -> Outgoing Remove the tutorial and enhance the noContentHelper screens with rainbow man, and buttons: Before this PR, the tutorial was displayed when there were no transactions visible. Now, the noContentHelper screen is displayed instead. It includes buttons to clear the filters if there are any, and to go back to the previous action or dashboard. When transactions have been reconciled, rainbowman is displayed instead. Task-3221418 Forward-Port-Of: odoo/enterprise#39017
We need to check for the real id in the database, not the NewId. Reproduce: * With demo data: Accounting > Follow-up Report > Deco Addict * Set a level (i.e. 50 days) * Exclude one of the lines from the followup At this point, the level is not there anymore in the view. If we save, it will erase the current level from all the lines. Forward-Port-Of: odoo/enterprise#39961
Original PR description
We need to check for the real id in the database, not the NewId. Reproduce: * With demo data: Accounting > Follow-up Report > Deco Addict * Set a level (i.e. 50 days) * Exclude one of the lines from the followup At this point, the level is not there anymore in the view. If we save, it will erase the current level from all the lines. Forward-Port-Of: odoo/enterprise#39961