1. 26 May, 2016 5 commits
  2. 25 May, 2016 5 commits
    • Jeremy Kersten's avatar
      [FIX] web: fix backport #4c7a9bda · 9772bbef
      Jeremy Kersten authored
      9772bbef
    • Denis Ledoux's avatar
      [FIX] calandar: all day events email notification · 4176030c
      Denis Ledoux authored
      When sending a notification email to an event attendee
      for an all day event, the timezone must be ignored
      as the `start` and `stop` datetime are stored as
      the day date + '00:00:00'. If the timezone is applied,
      for users being in a negative timezone (such as an American
      timezone), the day displayed would be the day just before.
      
      opw-677019
      4176030c
    • Goffin Simon's avatar
      [FIX] web: raise a warning for bad domain · 4c7a9bda
      Goffin Simon authored
      When a user wrote a wrong value in char_domain field it should raise a warning
      message instead of a traceback.
      
      Backport of b3a88b6ed846a13c0cd07cc25ea49bccbdf84aa8
      
      opw:676783
      4c7a9bda
    • Martin Trigaux's avatar
      [IMP] gamification: prevent misconfiguration · 97492a12
      Martin Trigaux authored
      Prevent selecting wrong field or models or computed fields
      
      Fixes #8545
      97492a12
    • Joren Van Onder's avatar
      [FIX] hr_payroll: avoid infinite recursion · be48a140
      Joren Van Onder authored
      The get_recursive_parent function seemingly depended on the ordering of
      the rule_categories recordset which happens to work fine in most cases
      because all data first defines the parent before defining the children
      rule categories. But if you happen to do it the other way around it
      won't work and it will infinitely call itself because:
      
      if rule_categories[0].parent_id:
          rule_categories = rule_categories[0].parent_id | rule_categories
      
      won't change the value of rule_categories[0].
      
      opw-673222 (loosely related)
      be48a140
  3. 24 May, 2016 1 commit
    • Goffin Simon's avatar
      [FIX] account: partner_id set on a bank fee · 08416b23
      Goffin Simon authored
      Used case:
      
      -Create several customer invoices and validate them
      -Register a payment without any partner_id and in a bank statement for an amount
      a bit lower than the total of the invoice (the difference is the paypal fees)
      -Reconcile the invoices with the payment and create a write-off for the paypal fees
      -When you close the bank statement, check the journal items, the paypal fees are
      automatically assigned with a partner.
      
      Fix:
      
      -When creating the account move line for the fee, if all the account move lines
      linked to the move are for different partners then you cannot determine the partner
      of the fee.
      
      opw:674822
      08416b23
  4. 23 May, 2016 1 commit
    • Martin Trigaux's avatar
      Revert "[FIX] res.currency: allow duplication" · 0af32f3f
      Martin Trigaux authored
      This reverts commit d780f947.
      
      Did not work due to the size=3 on name field that strips the code to the first
      three letters only (removing the " (copy)" part).
      Copying a currency has a few business cases as the rates are not copied.
      As can not increase the size of a field in stable, remove the method that had no
      effect.
      
      Fixes #11036
      0af32f3f
  5. 22 May, 2016 1 commit
  6. 20 May, 2016 1 commit
  7. 19 May, 2016 3 commits
  8. 18 May, 2016 1 commit
    • Goffin Simon's avatar
      [FIX] mail: receiving a notification without notifying the parent message. · fac04424
      Goffin Simon authored
      Used case:
      
      If you add a user which has no acces on a model(ex:purchase.order)
      as follower on a record of this model. When someone responded by email on
      this record, and when a message is sent on this record, an exception is raised
      at the connection of the user added as a follower.
      
      Fix:
      
      To have the rights to read the message, a read notification for this follower must
      be added to all parents of this message.
      
      Closes #11902
      
      opw:676699
      fac04424
  9. 17 May, 2016 3 commits
  10. 15 May, 2016 1 commit
  11. 13 May, 2016 1 commit
  12. 12 May, 2016 7 commits
    • Alexis de Lattre's avatar
    • Goffin Simon's avatar
      [FIX] website: URL of website_published is wrong when using next/previous · 746cda7f
      Goffin Simon authored
      Steps to reproduce:
      
      -go to runbot 8.0 and connect
      -go into human ressources/job positions
      -pass into list view and click on the first item
      -click on the url to open this record into the website (website_published)
      -go back (back into the browser)
      -you're now into the form view again and then next step is to click on the button
      "next" to access the following record
      -click on the url of website_published
      
      Before the fix:
      
      wrong record, this is the previous one that is into the href
      
      After the fix:
      
      correct record with the correct id into the href
      
      Closes #11800
      opw:675832
      746cda7f
    • Goffin Simon's avatar
      [FIX] purchase: fiscal position from onchange_partner_id · 7061acd2
      Goffin Simon authored
      Used case:
      
      -Configure admin as multi-company user
      -Create 2 fiscal positions (one for company "Odoo BE" and one for company "Odoo US")
      -Set admin on company "Odoo BE"
      -On supplier (Asustek) configure fiscal position Odoo BE
      -Set admin on company "Odoo US"
      -On supplier (Asustek) configure fiscal position Odoo US
      -Configure a product (Laptop E5023) with:
         *route "Buy"
         *supplier (Asustek) without company
         *reordering rules (min qty: 20, max qty: 40)
      -Set admin on company "Odoo BE"
      -Run scheduler via the cron
      
      Behavior before the fix:
      
      -Fiscal position on the created PO is the fiscal position for "Odoo BE" (and PO is for the company "Odoo US")
      
      Behavior after the fix:
      
      -Fiscal position on the create PO is the fiscal position for "Odoo US".
      
      Closes #11537
      
      opw:673288
      7061acd2
    • Nicolas Seinlet's avatar
      [IMP] models: mark records as recomputed as soon as they are · 3a320211
      Nicolas Seinlet authored
      When recomputing stored function fields, the `write` may trigger a
      cache invalidation which lead to a recompute of all the recordset
      values, even the ones already saved in database.
      3a320211
    • Nicolas Seinlet's avatar
      [IMP] account: improve reconciliation speed · f207ef5f
      Nicolas Seinlet authored
       - Only invalidate cache for fields and records we modify
       - Rewrite query to be more efficient
       - Avoid o2m commands to be more efficient; write directly on reverse m2o
      f207ef5f
    • Nicolas Seinlet's avatar
      [FIX] mail: remove unneeded call to `refresh()` · 6f29bfc1
      Nicolas Seinlet authored
      With new api, this call is not wanted anymore. The cache is cleared
      automatically, no need to clear the whole cache; that's a little bit
      overkill and reduce performances.
      6f29bfc1
    • Nicolas Martinelli's avatar
      [FIX] purchase: date planned · 52948199
      Nicolas Martinelli authored
      When a PO is copied, the date planned of the order lines should be
      recomputed based on the order date.
      
      opw-675480
      52948199
  13. 11 May, 2016 3 commits
  14. 10 May, 2016 2 commits
    • Olivier Dony's avatar
      [FIX] http: clear environment/caches on transaction rollback · ac8b7e90
      Olivier Dony authored
      Backport of 8423a0df
      
      Clear the cache/environment in addition to rolling back
      the cursor, in order to retry the transaction with fresh
      data, not partially stale data.
      ac8b7e90
    • Denis Ledoux's avatar
      [FIX] google_calendar: do not copy user Google info · a0366b3a
      Denis Ledoux authored
      If a user syncs his calendar with Google,
      and a second user is created in the database by copying this first
      user, the Google information of the first user was copied
      (The Google account to sync, the token to use, the last
      syncrhonization date, ...), which is obviously wrong.
      
      On calendar syncrhonization, which can be done
      manually or automatically with the according cron, all
      events of the first user were created a second time,
      as a second user synchronized the same Google Calendar.
      
      opw-674141
      a0366b3a
  15. 09 May, 2016 5 commits
    • Denis Ledoux's avatar
      [FIX] account_anglo_saxon: default account value · 3954affc
      Denis Ledoux authored
      The default account value set for purchases invoices
      lines for product of type Service was wrong: It used
      the stock account, which is wrong as a Service
      as no stock. Instead, it should left the product
      expense account, as usual.
      
      opw-676110
      3954affc
    • Martin Trigaux's avatar
      [FIX] sale: outdated .pot file · 88749790
      Martin Trigaux authored
      Was having content of website_quote
      88749790
    • Raphael Collet's avatar
      [FIX] fields: invalidate x2many fields with a domain · 5676d812
      Raphael Collet authored
      Invalidate the cache of a x2many field when any of the fields appearing in its
      domain is modified.  Use the invalidation triggers mechanism for that purpose.
      5676d812
    • Denis Ledoux's avatar
      [FIX] google_calendar: user invited to one recurring event occurence only · 7923999f
      Denis Ledoux authored
      When a Google user was invited to one occurrence of a recurring event,
      but not to the recurring event itself (and the other occurrences, therefore),
      and the user owner of the recurring event did not sync his calendar in Odoo,
      the event occurrence could not be synced in Odoo, because it attempted
      to attach it to the parent/main recurring event, which was not present
      in Odoo.
      
      In such a case, Odoo now syncs the event occurrence as a simple classic
      event. In addition, if the owner of the event sync his calendar with Odoo
      afterwards, or if the user is invited later to the main/parent recurring event
      and then sync again his calendar,
      it then attach the event occurrence that was previously
      synced to this main event, to avoid events duplication.
      
      opw-676535
      7923999f
    • Nicolas Lempereur's avatar
      [IMP] web: multi-click on save on view form (no fp) · dd714ace
      Nicolas Lempereur authored
      When clicking on save several time when editing a view form it can be
      saved several times which can be an issue for one to many.
      
      The normal happenstance when saving should be as follow:
      
      -> save (click)
      -> wait write result
      -> received write result
      -> reload the form with updated data and updates buttons
      
      But when clicking several time, it could become:
      
      -> save (click)
      -> wait write result
      -> received write result
      -> save (click)
      -> wait write result
      -> received write result
      -> reload the form with updated data and updates buttons
      
      This commit only reinstate the saving feature once the form is reloaded.
      
      closes #11926
      opw-671793
      
      note: no need to forward-port
      dd714ace