This project is mirrored from https://github.com/odoo/odoo.git. Pull mirroring updated .
  1. 22 May, 2022 1 commit
  2. 20 May, 2022 8 commits
    • alt-odoo's avatar
      [FIX] website_hr_recruitment: allow portal users to filter by department · 689a3aa9
      alt-odoo authored
      
      
      Currently, only a public user or an internal user can access HR
      department information. This is causing an access rights error when
      trying to filter job offers on the website if connected with a portal
      user, while there is no error if not connected (public user). We should
      have the same behavior for the two cases.
      
      closes odoo/odoo#91733
      Signed-off-by: default avatarRomain Derie (rde) <rde@odoo.com>
      689a3aa9
    • xmo-odoo's avatar
      [FIX] auth_oauth: restore fetching uid from user_id · a787a2f6
      xmo-odoo authored
      In discussing 56fe16bd
      
       I was reminded to re-set the `user_id` from
      `sub` in case an override / other client would be using it, but we
      didn't think that an override might also be *setting* this work key,
      which apparently is the case.
      
      Therefore restore the old behavior of *getting* the user_id from the
      response object, migration to using `sub` (and removal of compat with
      `user_id` and `id`) will be done when the module is reworked and the
      flow compatibility, nonce, etc... are all fixed.
      
      closes odoo/odoo#91941
      Signed-off-by: xmo-odoo's avatarXavier Morel (xmo) <xmo@odoo.com>
      a787a2f6
    • Touati Djamel (otd)'s avatar
      [FIX] mrp_account: access product variant without traceback · ba548ac9
      Touati Djamel (otd) authored
      
      
      Steps to reproduce the bug:
      - Create a storable product “P1” with BOM
      - remove MRP access to Marc Demo
      - connect with Marc
      - Go to inventory > Master data > product variant > product “P1”
      - try to open the product variant view
      
      Problem:
      Traceback is triggered, because we use the "bom_count" field in the domain
      without checking if the user has access to MRP
      
      opw-2856146
      opw-2842434
      
      closes odoo/odoo#91886
      Signed-off-by: default avatarWilliam Henrotin (whe) <whe@odoo.com>
      ba548ac9
    • William Braeckman's avatar
      [FIX] website_sale: allow calling _cart_update when product is already · 754d4edd
      William Braeckman authored
      
      
      in cart
      
      Due to a recent change in eCommerce the products that can be added to
      the cart have been more restricted.
      However some modules, for example sale_coupon, add some lines regardless
      of those rules.
      This commit allows these lines to be kept when there is a pricelist
      change.
      
      closes odoo/odoo#91901
      Signed-off-by: default avatarYannick Tivisse (yti) <yti@odoo.com>
      754d4edd
    • qsm-odoo's avatar
      [FIX] base: remove branding on nodes whose inner content is removed · 1d86f5e3
      qsm-odoo authored
      Parent view:
      ```
      <hello>
          <world></world>
          <world></world>
      </hello>
      ```
      
      Child view:
      ```
      <data>
          <xpath expr="/hello/world[1]" position="replace"/>
      </data>
      ```
      
      => There are two <world/> in the original view, the first one is removed
         by a child view.
      
      In that case, the branding was still distributed on the <hello> element.
      This is a problem as it meant that in edit mode you were able to edit
      the whole content of that <hello/> element... breaking the xpath made by
      the child view.
      After this commit, in that case, the branding is rightfully distributed
      on the remaining <world/> element (just like it would have been if the
      inheriting view had added an element instead of just removing one).
      
      This is a follow-up of the parent commit (of the same PR at [1]).
      
      [1]: https://github.com/odoo/odoo/pull/91015
      
      
      
      Related to opw-2811674
      
      closes odoo/odoo#91015
      Signed-off-by: default avatarRomain Derie (rde) <rde@odoo.com>
      1d86f5e3
    • qsm-odoo's avatar
      [FIX] base, tools: properly distribute branding around removed elements · f67832a3
      qsm-odoo authored
      When branding was added on items which follow an element that is removed
      by an inheriting view, the branding was incorrect. Indeed, it supposed
      the removed element does not exist in the original view. E.g.:
      
      Parent view:
      ```
      <hello>
          <world></world>
          <world></world>
          <t t-esc="foo"/>
      </hello>
      ```
      
      Child view:
      ```
      <data>
          <xpath expr="/hello/world[1]" position="replace"/>
      </data>
      ```
      
      => There are two <world/> in the original view, the first one is removed
         by a child view. The data-oe-xpath set on the remaining <world/>
         should still be /hello/world[2] and not /hello/world[1] to target the
         right element in the parent view.
      
      This of course induced edition problems where a saved area was not saved
      inside the right element of the parent view or, more likely in normally
      complex arch, just crashed on save. As an example, with 14.0 enterprise:
      
      - Install website_appointment
      - Go to a page with a calendar to schedule an appointment
      - Enter edit mode, try to add something in the area *below* the calendar
      - Save => crash
      
      Commit [1] already fixed similar problems when an element was *replaced*
      by something (especially, when replaced by an element with the same tag
      name). This commit actually reviews what was done to fix both problems
      (replacement and removal) at the same time. It also makes it so the xml
      that `apply_inheritance_specs` produces has no "Element" part impacted
      when used with "inherit_branding=True", which seems better... although
      the notion of inheriting branding should probably be independant from
      this function (maybe something to do in master).
      
      [1]: https://github.com/odoo/odoo/commit/c077ef05575d9677bce284195683f96c68386788
      
      opw-2811674
      
      Part-of: odoo/odoo#91015
      f67832a3
    • xmo-odoo's avatar
      [FIX] core: _get_external_ids to behave better in onchange context · 5797fd80
      xmo-odoo authored
      
      
      If `_get_external_ids` is called in an onchange context on a newid
      wrapper, the result map uses NewId keys but the assigned data uses
      real ids, which leads to a mis-setting, and usually the call blowing
      up immediately as `data['res_id']` is not one of the preallocated dict
      entries.
      
      Update the code to better handle this possible difference.
      
      closes odoo/odoo#91878
      Signed-off-by: xmo-odoo's avatarXavier Morel (xmo) <xmo@odoo.com>
      Co-authored-by: default avatarRaphael Collet <rco@odoo.com>
      5797fd80
    • mafo-odoo's avatar
      [FIX] website_sale: add the terms and condition to sale order for website · 3defd7d1
      mafo-odoo authored
      
      
      Explanation:
      The code used deprecated variable names for the system parameter and value of the
      terms and conditions. If the system still has the old system parameter name set
       it can lead to errors. We remove this line as it seems the terms and conditions
       are added somewhere else in the code to the sale order.
      
      opw-2846046
      
      closes odoo/odoo#91089
      Signed-off-by: default avatarWilliam Braeckman (wbr) <wbr@odoo.com>
      3defd7d1
  3. 19 May, 2022 7 commits
    • Florian Damhaut's avatar
      [FIX] sale_coupon: max value for % coupon is now capped · ce67e260
      Florian Damhaut authored
      
      
      Current behaviour:
      - If you have a fixed amount coupon applied on an order which
      remove 50% of the value
      - If your then apply a percentage coupon
      - The percentage coupon doesn't check if the value removed from
      the sale order is greater than the remaining value
      
      Behaviour after PR:
      - % coupon only remove the remaining value
      
      closes odoo/odoo#88393
      Signed-off-by: default avatarRomain Derie (rde) <rde@odoo.com>
      ce67e260
    • Florian Damhaut's avatar
      [FIX] sale_coupon: Apply taxes to fixed_price discount · ea73ca4d
      Florian Damhaut authored
      Step to reproduce:
      - Create a promotion with fixed price discount
      - Create a SO where the promotion can apply with taxes on the
      products
      - Trigger the computation of the taxes
      
      Current behaviour:
      - No taxes are applied on the fixed price discount
      
      Behaviour after PR:
      - Taxes are applied on the fixed price based on their
      proportion to the total amount.
      
      opw-2806780
      
      Part-of: odoo/odoo#88393
      ea73ca4d
    • Florian Damhaut's avatar
      [FIX] sale_coupon: add SOL to SO in one single write · 9f1d01ce
      Florian Damhaut authored
      Part-of: odoo/odoo#88393
      9f1d01ce
    • Soukéina Bojabza's avatar
      [FIX] web_editor: resolve bug of focused input element in edit mode · a745af0f
      Soukéina Bojabza authored
      In the Firefox browser, when in edit mode, if we click on an input
      element, a traceback sometimes appears for no apparent reasons.
      The error comes from the fact that when calling the getRangeAt function
      on the selection, it sometimes returns a "restricted" range.
      Ex: Range { commonAncestorContainer: Restricted, startContainer:
      Restricted, startOffset: 0, endContainer: Restricted, endOffset: 0,
      collapsed: true }
      And so, trying to access a container property (ex: nodetype) will
      trigger a "Permission denied to access property "nodetype"" error.
      
      This commit provides a solution to bypass the error. It consists in
      redefining the getRangeAt function as the following:
      
      - A range is created by calling the original function that was saved
        beforehand
      - We check if the range is restricted (the same way as what was done in
        this issue: https://github.com/tinymce/tinymce/issues/2194
      
      )
          - if it is not restricted, the range is simply returned
          - otherwise, a new range is created manually, based on the selection
      
      Steps to reproduce the bug:
      
      - Install website
      - Drop a form snippet
      - Click on the input fields
      -> Sometimes a traceback appears
      
      task-2810365
      
      closes odoo/odoo#90595
      Signed-off-by: default avatarQuentin Smetz (qsm) <qsm@odoo.com>
      a745af0f
    • Pierre Masereel's avatar
      [TEST] point_of_sale: test fixed tax included · ac9cd476
      Pierre Masereel authored
      After a fix made in rev:bd621fd4
      
      
      
      It was not possible to generate an invoice from the POS when you have a
      fixed tax included applied on a base amount with tax included.
      
      As it was not detected by a test, we are now creating a test with this
      use case.
      
      closes odoo/odoo#91803
      Signed-off-by: default avatarMasereel Pierre <pim@odoo.com>
      ac9cd476
    • Federico (fega)'s avatar
      [FIX] account: multi-company error bill created by email with alias · 2802fd2a
      Federico (fega) authored
      
      
      Steps to reproduce:
      - Set up an alias to receive vendor bills to company 2
      - Forward a mail to this alias from an internal user
      - The mail should have the email address of a partner belonging to company 1 in it
      
      Current behavior:
      - The partner from company 1 can be set as vendor even tho the vendor bill will be from company 2 (inconsistent)
      - This leads to a multi-company error, and you can't open the bill as an user who can see it but not the partner.
      
      Intended behavior:
      - Partner from company 1 shouldn't be set as vendor if the vendor bill has been created from email alias of company 2.
      
      As the intended behavior says, the code avoids to set the vendor if the bill is created through an alias.
      
      opw-2587047
      
      closes odoo/odoo#83604
      Signed-off-by: default avatarWilliam André (wan) <wan@odoo.com>
      Co-authored-by: default avatarAndrea Grazioso (agr-odoo) <agr@odoo.com>
      2802fd2a
    • Víctor Martínez's avatar
      [FIX] hr_holidays: Allow employee to add attachments on validated time off · 723fe143
      Víctor Martínez authored
      
      
      Purpose
      =======
      
      Allow to add attachments in leaves if they don't have officer permissions.
      
      closes odoo/odoo#91776
      Signed-off-by: default avatarYannick Tivisse (yti) <yti@odoo.com>
      723fe143
  4. 18 May, 2022 5 commits
  5. 17 May, 2022 4 commits
  6. 16 May, 2022 3 commits
    • Yolann Sabaux's avatar
      [FIX] web: fetch right company_id · a2fba13f
      Yolann Sabaux authored
      Steps to reproduce:
      - Have two companies set up
      - In settings, check for company 2 the Files Centralization
      - For a Product, upload a document
      
      Issue:
      The document will not appear in Documents.
      It will only appear if the option is checked for company 1
      
      Cause:
      The company_id is not fetched correctly throughout the process.
      There is a similar solution for the specific `documents` upload route:
      https://github.com/odoo/enterprise/blob/bdf712d66c3e5cee70a6b424b69a618fe655a39f/documents/controllers/main.py#L147-L149
      
      
      
      Solution:
      Get the id directly from the cookies
      
      opw-2774365
      
      closes odoo/odoo#88745
      Signed-off-by: default avatarNicolas Lempereur (nle) <nle@odoo.com>
      a2fba13f
    • xmo-odoo's avatar
      [FIX] auth_oauth: google rejects nonce if response_type=token · 1fd738d9
      xmo-odoo authored
      
      
      I apparently missed this case in #88871: Google's legacy
      flow (response_type=token) explicitly rejects a `nonce` parameter
      being passed in the authentication request. The nonce parameter is
      only accepted for an OIDC-conformant implicit flow request (aka
      `response_type=token id_token`).
      
      The specific endpoint doesn't seem to have any bearing on this, v1 and
      v2 authentication endpoints result in the same behavior.
      
      Drawback: Okta isn't supported anymore, as it requires the nonce, no
      if, no but, even on "legacy" auth requests, possibly others. However
      since these already weren't supported that's considered less of an
      issue than possibly breaking compatibility with existing IDP.
      
      Rejected alternative: adding `id_token` to the `response_type` to come
      closer to OIDC-conformant request, however that was considered too
      risky: Odoo clients could be using legacy IDP which also reject the
      nonce parameter but don't have a magic "OIDC conformant" trigger.
      
      closes odoo/odoo#91443
      Signed-off-by: xmo-odoo's avatarXavier Morel (xmo) <xmo@odoo.com>
      1fd738d9
    • Hubert Van de Walle (huvw)'s avatar
      [FIX] web: boolean_toggle widget ignores readonly attribute · 8021562b
      Hubert Van de Walle (huvw) authored
      
      
      The boolean_toggle should only be disabled when there is a readonly
      modifier, not when the view is in readonly mode.
      
      Cause of the issue
      
        The input was disabled but the `_onClick` was registered on the
        widget root node.
      
      Solution
      
        - Listen for clicks on the input element
        - Override the render method to set the disabled prop according to the
          readonly modifier.
      
      opw-2739468
      
      closes odoo/odoo#86542
      Signed-off-by: default avatarMichaël Mattiello <mcm@odoo.com>
      8021562b
  7. 13 May, 2022 5 commits
    • Miquel Raïch's avatar
      [FIX] account: draft move lines shouldn't be marked as reconciled · c8c3aa96
      Miquel Raïch authored
      
      
      closes odoo/odoo#91306
      Signed-off-by: default avatarWilliam André (wan) <wan@odoo.com>
      c8c3aa96
    • qsm-odoo's avatar
      [FIX] website_sale: allow to use the searchbar snippet in mega menus · 3bc2ce2d
      qsm-odoo authored
      
      
      Before this commit, when searching something via the searchbar snippet
      when it is in a mega menu, the dropdown that appears could not overflow
      the mega menu dropdown and thus was mostly hidden.
      
      opw-2779432
      
      closes odoo/odoo#91193
      Signed-off-by: default avatarRomain Derie (rde) <rde@odoo.com>
      3bc2ce2d
    • Jeremy Kersten's avatar
      [FIX] website_slides: avoid redirect to /web/signup?redirect=undefined · 3283aef1
      Jeremy Kersten authored
      
      
      This commit fixes the Signup link under the quiz validation.
      widget.url is not defined in widget.
      Now we use the redirectUrl from the widget as redirect after the signup.
      
      It has been detected by a number of hit on /web/undefined
      
      closes odoo/odoo#91342
      Signed-off-by: default avatarRomain Derie (rde) <rde@odoo.com>
      3283aef1
    • Victor Feyens's avatar
      [FIX] sale_management: admin doesn't have access to sale.order.template model · 74857e31
      Victor Feyens authored
      
      
      If a default template is specified in a given database (it is the case by default
      on runbot databases because of sale_quotation_builder), the webclient will
      try to fetch its display_name (through a name_get rpc).
      
      As this happens even if the default_sale_order_template_id field is hidden
      in the view, administrators without sales rights were not able to open the settings,
      because they didn't have read rights on sale.order.template model.
      
      This commit makes sure that settings users are able to open the settings
      independently of their level of rights for the Sales scope (salesman/sales manager).
      
      Fixes #84597
      
      closes odoo/odoo#91312
      Signed-off-by: default avatarVictor Feyens (vfe) <vfe@odoo.com>
      74857e31
    • momegahed's avatar
      [FIX] account_analytic_default: fixing restrictions on analytic tags · e97f2cc6
      momegahed authored
      If applied, this commit will fix the following bug by adding some
      restrictions on the creation of analytic default
      and the uses of tags in account.move
      
      Steps to reproduce:
      1- install account.accountant, account_analytic_default
      2- Accounting --> Configuration --> Analytic Tags, analytic accounting
      3-  Create an Analytic Tag, with no Analytic Distribution.
      4-  Accounting --> Configuration --> Analytic Default Rules.
      Create an Analytic Default Rule, using the Analytic Tag above
      and select a Partner
      5- Create a Vendor Bill on that partner. The Analytic Tag is added to
      the invoice, as expected
      6- However when selecting Accounting --> Reporting --> Analytic Report,
      the report is empty and does not contain the Analytic Tag. Adding the
       Analytic Tag to the filter has no effect.
      Bug/Issue:
      An analytic tag is meant to be an additional dimension of analysis.
      Dimension which is only worth/valid when an analytic account is
      specified.
      
      An analytic default rule should never be applied without
      - either an analytic account
      - or analytic tag used for distribution
      Fixes:
      1- changing the error condition on creating analytic default
      2- changing the error message accordingly to better explain the issue
      3- raise an error when the user creates an account.move with analytic
      tags without (analytic tags + analytic account) or (analytic tags with
      analytic distrubtion)
      
      Please refer to the ticket for the whole discussion on this
      
      corrects https://github.com/odoo/odoo/issues/91177
      
      
      
      OPW-2766749
      
      closes odoo/odoo#91211
      Signed-off-by: default avatarWilliam André (wan) <wan@odoo.com>
      e97f2cc6
  8. 12 May, 2022 6 commits
    • William Braeckman's avatar
      [REV] website_sale: Avoid traceback when adding deleted products to cart · db50b2f7
      William Braeckman authored
      This reverts commit c3b8018d
      
      .
      
      closes odoo/odoo#91244
      Signed-off-by: default avatarYannick Tivisse (yti) <yti@odoo.com>
      db50b2f7
    • Hubert Van de Walle (huvw)'s avatar
      [FIX] account_accountant: writeoff date should be off type date · 668a3080
      Hubert Van de Walle (huvw) authored
      Steps to follow
      
        - Have unreconciled entries
        - Go to General Ledger
        - Filter -> Unreconciled
        - Select one, action -> Reconcile
        - Manual operations -> click on write-off date
        - Hit enter while there is calendar
        -> TypeError: value.isSame is not a function
      
      Cause of the issue
      
        The Writeoff Date field is declared as type char
        FieldDate._onKeyDown calls _parseValue and returns a string
      
      opw-2820370
      https://www.odoo.com/web#view_type=form&model=project.task&id=2820370
      
      
      
      closes odoo/odoo#91119
      Signed-off-by: default avatarWilliam André (wan) <wan@odoo.com>
      668a3080
    • William Braeckman's avatar
      [FIX] website_sale: Avoid traceback when adding deleted products to cart · c3b8018d
      William Braeckman authored
      
      
      Prior to this commit an user could try to add a product to cart that does not
      exist anymore because it was deleted while the user /shop page wasn't refreshed.
      
      This commit avoids this (rare) use case to happen.
      
      TaskId-2835736
      
      closes odoo/odoo#90159
      Signed-off-by: default avatarYannick Tivisse (yti) <yti@odoo.com>
      c3b8018d
    • William Braeckman's avatar
      [FIX] base: fix file extension when using default name · 1a75900b
      William Braeckman authored
      The file extension detection previously used to determine whether a
      filename required an extension was not very smart and in fact only
      checked for a dot in the filename.
      `mimetypes.guess_type` is now used on the filename to better determine
      whether the filename still needs a file extension or not.
      
      This commit is a follow-up to: https://github.com/odoo/odoo/pull/90614
      
      
      Which aimed to fix the same issue.
      
      TaskId-2826061
      
      closes odoo/odoo#90855
      Signed-off-by: xmo-odoo's avatarXavier Morel (xmo) <xmo@odoo.com>
      1a75900b
    • xmo-odoo's avatar
      [FIX] auth_oauth: improve implicit flow implementation / compat · 56fe16bd
      xmo-odoo authored
      The current implementation is rather non-standard and largely an
      ad-hoc pre-RFC implementation, with a number of incompatibilities with
      the standard & actual real-world identity providers (IDP).
      
      Tested with the following IDP:
      
      - google oauth v1
      - google oauth v3
      - auth0
      - okta
      
      Add support to bearer Authorization
      ===================================
      
      Sending the access token via "Authorization: Bearer $TOK" is strongly
      recommended by the RFC, and required for all IDP to support. The query
      parameter method is a legacy compatibility method and should be
      avoided.
      
      Query parameter access tokens are supported by Google (both v1 and
      v3), and auth0, but not okta. All three support bearer tokens. However
      making this the default is complicated by compatibility issues with
      current behavior.
      
      Use standard `sub`ject for identity
      ===================================
      
      The specification defines `sub` as the userinfo key providing the user
      identifier at the IDP.
      
      - auth0, okta, and google v3 use `sub`
      - google v1 uses `id`
      - google v1's `tokeninfo` (possibly v3 as well, not tested) uses
        `user_id`
      - odoo replicates the google v1 tokeninfo behavior, using `user_id`
      
      All the code is now standardised on `sub`, with `_auth_oauth_validate`
      performing unification under that key.
      
      Support non-json error bodies and WWW-Authenticate
      ==================================================
      
      Per-spec, there is no requirement for error (userinfo) responses to
      return any body, and all error information can be returned via
      `WWW-Authenticate`.
      
      Both auth0 and okta return empty bodies on error, though only okta
      returns a useful www-authenticate, or relevant 40x statuses (auth0
      seems to always return 400, okta has been observed to return both 400
      and 401 depending on client error).
      
      Error handling in `_auth_oauth_rpc` has been updated to only parse the
      body as json on success (200), and fallback on a generic error payload
      if `WWW-Authenticate` doesn't contain relevant information.
      
      Nonce
      =====
      
      Okta requires a nonce to be provided.
      
      Misc
      ====
      
      A few improvements which are in no way required but should make things
      simpler / clearer:
      
      - update the default scope to match the standard for the implicit
        flow's values (intersected with our requirements)
      - update the default google configuration to use the v3 endpoints and
        drop the tokeninfo request, remove the explicit scopes
      - update the label of `validation_endpoint` to match the official
        terminology, same with `auth_endpoint`
      - add a label to `body` in order to explain what it's for (as that's
        really confusing when the form just says `body` until you hover the
        field)
      
      Expected future updates
      =======================
      
      These issues were left out and may lead to degraded security, but were
      considered too large changes fora stable compatibility-oriented
      update:
      
      * store and validate the nonce
      * request and properly validate the id token, as well as validate the
        access token (implicit guide sections 2.2.1, 2.2.2)
      * implement "basic" flow[^basic], and / or "hybrid" flow, the implicit
        flow[^implicit] is intended for purely client-side applications
        (SPAs), the "authorization code" flow is intended as the primary
        flow for normal web applications involving a server component,
        the main advantage of the hybrid flow is that the id token *can*
        contain the claims selected by `scope`, avoiding the need for the
        userinfo request[^idtoken]
      * remove support for query parameter requests
      * remove support for Google's v1 oauth and subject identifiers other
        than `sub`, facebook has not been tested but looks to support that
        key as well in the OpenGraph API[^fb], this will require migrating
        existing google providers to v3 implicitly (but would allow
        simplifying their configuration)
      
      References: RFC 6749, RFC 6750, Implicit Client Implementer's Guide
      1.0 draft 23[^implicit]
      
      Closes #88618, closes #64348, fixes #63963, closes #63970,
      closes #69568
      
      [^implicit]: https://openid.net/specs/openid-connect-implicit-1_0.html
      [^basic]: https://openid.net/specs/openid-connect-basic-1_0.html also
                known as "authorization code" flow
      [^fb]: https://www.facebook.com/.well-known/openid-configuration
      
      
      [^idtoken]: during testing, only auth0 returned the additional claims
                  as part of the id token, but this may be a configuration
                  issue
      
      closes odoo/odoo#88871
      Signed-off-by: xmo-odoo's avatarXavier Morel (xmo) <xmo@odoo.com>
      56fe16bd
    • Touati Djamel (otd)'s avatar
      [FIX] mrp: add the `stock.move` company in the context · 86bd229a
      Touati Djamel (otd) authored
      
      
      Steps to reproduce the bug:
      - Create the storable  product “P1”
          - tracking by a unique serial number
          - update the qty:
              - serial number: S1, qty: 1, company: Company A
              - serial number: S1, qty: 1, company: Company A
      
      - Create the storable product “P2” with BOM:
          - Component: “P1”, qty:1
      
      - Create a MO to produce one unit of “P2”:
          - Click on “Mark as to do”
          - Then, “Produce”
          - In the view form that opens:
              - You can choose the product "P1" with the serial number “S1” or “S2”
              - use the “S1”
          - Confirm the MO
      
      - Unlock the “MO”
      - Edit
      - Click on the product “P1”
      - add a new line:
          - Select the product “P1”
          - The serial number "S2" is not proposed, while it was not used
      
      Problem:
      The new stock.move.line is created without company_id,
      so when comparing the serial number one (‘company A’)
      with that of the line(False) it will not be similar.
      
      Solution:
      The `stock.move.line` must always have the same company as its `stock.move`
      
      opw-2845049
      
      closes odoo/odoo#91122
      Signed-off-by: default avatarArnold Moyaux <arm@odoo.com>
      86bd229a
  9. 11 May, 2022 1 commit
    • Pouya Malekinejad's avatar
      [IMP] account_invoice: prevent erasing of a tax line entry if there is a tax... · ac3cf2ed
      Pouya Malekinejad authored
      
      [IMP] account_invoice: prevent erasing of a tax line entry if there is a tax related to it in the invoice
      
      This is actually checking if for each tax of each line of invoice in the move, there exist a tax entry.
      This will prevent the users from accidentally or dully erasing tax lines which includes 0% taxes.
      If the users delete the line containing tax, it will be added again the same way as the counterpart line
      for an invoice line is being added.
      
      Also, fixes the following:
      Recalculating all invoices if a single invoice in a batch has a line with `recompute_tax_line` set should not be allowed.
      Deleting a tax account entry of a posted move should not be allowed.
      
      task ID:2834679
      
      Pr: #90834
      Signed-off-by: default avatarWilliam André (wan) <wan@odoo.com>
      ac3cf2ed