Give the same as access rights to the employee as for the public user.
This patch is needed to allow a user to access the partner form.
Same for portal.
The list of grades in not a confidential information.
Fixes#7719
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
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
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)
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
The widget selection only shows the first 120 results.
The selection was most likely set to avoid creating new entries but it can be
done with an option tag. This allows to use the search on many2one fields.
opw-677908
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.
related to opw-671793
backport of 8.0's dd714ac
note: no need to forward-port
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
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
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
- 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
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.
When "Filter by Periods" is choosen in the wizard, the right periods
must be set in ctx to filter the account moves according to the right periods
opw:674593
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
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
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
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
The user performing reconciliations may not always
have the right to update the corresponding partners,
for example if a partner is also a system user.
Doing it as super-user after verifying that the
user is indeed allowed to reconcile journal items
works around the problem.
Fixes#11931
Without the proper decorator, the method is matched as `cr_ui_context`.
This is because the `guess` mechanism expects a name `res_id` instead of
`record_id`.
For stability reason it is better to add the decorator than modify the signature
of the method.
Closes#11735
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.
We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.
opw-673453
The dates of an event on the website was always
within the user timezone. If not signed in,
it was within the public user timezone
(which is quite not user-friendly to change)
For this purpose, we weed get the context
from the record (the context used when using
`record.with_context`), and therefore
the QWeb field
`ir.qweb.field.datetime` is slightly altered,
to use the context from the record.
opw-675427
The stock history doesn't take into account internal moves. For example,
in the following situation:
- Receive 1000 products to Internal Warehouse 1
- Move these 1000 products to Internal Warehouse 2
The 1000 products are still recorded on the Internal Warehouse 1.
opw-672277
Oversight of commit bd025cda.
I'm an idiot, I should have checked that another solution was applied
from 9.0 with accounting refactoring. We apply it here as well.
When stock landed costs are divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when several products are bought, but
these products leave the stock one at a time.
A numerical example is the following: a landed cost of 15.00 is applied
to a purchase of 13 units. An amount of 15.00 is recorded when the
products enter the stock. If the product leave the stock one at a time,
13 entries of 1.15 are recorded (15.00/13 = 1.153846... ≈ 1.15), which
is then equal to 13 * 1.15 = 14.95. In this case, All the products have
left the stock (stock valuation is zero), but 5 cents remain on the
account.
This is of course even worse the higher the ratio is. For example, a
landed cost of 4.00 split into 1000 units sold piece by piece will never
be recorded when a product leaves the stock.
The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost
opw-675222
When the product price is divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when a product is bought in a UoM
different from the standard UoM of the product.
A numerical example is the following: a box of 13 is bought for 15.00.
An amount of 15.00 is recorded when the products enter the stock. If the
product leave the stock one at a time, 13 entries of 1.15 are recorded
(15.00/13 = 1.153846... ≈ 1.15), which is then equal to
13 * 1.15 = 14.95. In this case, All the products have left the stock
(stock valuation is zero), but 5 cents remain on the account.
This is of course even worse the higher the ratio is. For example, a
box of 4.00 split into 1000 units sold piece by piece will never be
recorded when a product leaves the stock.
The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost
opw-675222
The precision of `former_cost_per_unit` should not be set. Indeed, a
stock move can contain several quants with different unit prices.
Therefore, we should not round the field when stored, otherwise the
difference per unit will not be calculated correctly.
This is a workaround since we cannot change the DB structure in stable.
opw-675222
Makes the fix in f992c8ee19
specific to the view manager of the main oe_application
container, in order to avoid disrupting other view manager
occurrences (such as the ones in modal windows or x2many
list views).
Fixes#11629 (again)
Note: Hopefully the Blink team will fix Chrome so we can
get rid of this hack in the future:
https://bugs.chromium.org/p/chromium/issues/detail?id=603507
When setting rules on models having o2m/m2m relationship
between each other
e.g.
- `res.partner`:
o2m `sale_order_ids` to `sale.order`
- `sale.order`
o2m `message_follower_ids` to `res.partner`
an infinite loop could occur if records
of these models referenced records of the
other models in their o2m relationships
e.g.
- `res.partner` ID 68:
`sale.order` ID 9 in its `sale_order_ids`
- `sale.order` ID 9:
`res.partner` ID 68 in its `message_partner_ids`
This revision solves this use case, by passing the already
treated records in the context and checking that the records
haven't yet be treated before making the recursive call.
This revision makes sure to not break the API of methods
`get_data_context` and `prepare_audittrail_log_line`
(a new parameter had to be introduced for the above purpose)
opw-670904
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset was created twice.
After the fix: A warning is raised if an asset already exists for the invoice.
opw:674674
Chrome 50 treats percent-height divs inside of auto-height cells as
auto [1]. So from now on it's important that an explicit 'height: 100%' CSS
property is set on parent tds, otherwise you'll end up with elements
with a height of 0.
An extra difficulty is that this new height property on
subwindow-container will result in the element being as high as his
parent table. So the collapsed trick doesn't work anymore in the
customer list.
This has to be done conditionally. The proposed workaround of adding
100% height to parents of affected elements causes issues in IE/Edge
because the effect of adding a height in percent to a table-{cell,row}
element is not defined by CSS [2].
DO NOT FORWARD-PORT!
[1] 8876584335
[2] http://stackoverflow.com/a/27384730
When canceling and clicking on "reset to draft" button a PO with
invoicing method = Based on generated draft invoice, the purchase
workflow led to a shipping exception.
To be in state done the PO must have:
All its PO lines invoiced with _set_po_lines_invoiced
All its incoming shipments done with test_moves_done
opw:673561
Chrome 50 treats percent-height divs inside of auto-height cells as
auto [1]. So from now on it's important that an explicit 'height: 100%' CSS
property is set on parent tds, otherwise you'll end up with elements
with a height of 0.
DO NOT FORWARD-PORT!
[1] 8876584335
A 100% height is not distributed anymore to the children of a table-row
if they are not themselves table-cell in Chrome 50. This breaks the
indenpendent scrolling of the menu and the view manager.
However, setting the `table-cell` display breaks the layout in Internet
Explorer.
When the webclient is loaded by Chrome 50, we load a stylesheet
forcing a `table-cell` for display.
Seems to be related to https://bugs.chromium.org/p/chromium/issues/detail?id=353580
and 8876584335
Related to e1a99192bdFixes#11629
Catching and hiding database transactional errors can
sometimes cause a POS order to be entirely lost.
When it occurs, the transaction won't be committed
into the database, and if there is only one order
in the batch, the server won't return any error to
the frontend POS which will consider the order saved.
This is very unlikely to be exploitable because the
alt-field usually comes from master data (e.g. product
names) that can't be injected.
Courtesy of Naglis Jonaitis
When creating an invoice from a contract with button "create invoices",
the description linked to the contract has to written in the comment field
of the invoice.
opw:671660
When the POSBox boots without a network cable attached it will
automatically launch a wireless AP that people can connect to. This
allows them to configure what wireless network the POSBox should connect
to.
This wireless AP was configured to use the 10.10.0.0/24 subnet. The AP
itself was on 10.10.0.1. Although this is fine if used as intended it is
a quick way to take down an existing network if you where to plug in an
ethernet cable after the wireless AP has started. 10.10.0.1 is commonly
used by routers all over the world and plugging in a booted POSBox into
their networks will cause serious issues because the POSBox will share
the same IP as the router.
This moves the POSBox AP to the 10.11.12.0/24 subnet, with the AP on
10.11.12.1.
This also makes the DHCP server listen only on wlan0 because otherwise
you can end up with two DHCP servers on the same network which would
still break stuff.
Useful when updates to the initialization scripts don't go as
planned. This leaves something to inspect.
The initialization script already automatically stops (because of 'set
-o errexit') but it was a bit tricky to actually see what went wrong
because scrollback in QEMU isn't great.
The main reason for doing this is supporting the new Raspberry Pi 3. No
functional changes where made.
For Raspbian Wheezy we used to download the full image and strip it as
best we could to obtain a reasonable image size for people to
download. Since Raspbian Jessie the Raspberry Pi Foundation has started
releasing an official minimal image (Raspbian Jessie Lite) which we will
use from now on to build our image. One downside of this is that the
minimal image is a 1.3 GiB image which is too small for our
purposes so it has to be resized.
Because Raspbian Jessie migrated to systemd we cannot rely on
/etc/init.d/rcS to set up the ramdisks anymore. Jessie provides a
compatibility layer so old SysVinit scripts still work but rcS does not
block like it does in a SysVinit system, it is run in parallel with
other startup services. In our case this is a bad thing as setting up
the ramdisks has to be done before any other services are started. To
accomplish this the rcS hack has been migrated to a systemd service
running before basic.target and with DefaultDependencies=no. This has a
similar effect as the rcS hack because normal systemd services (with
DefaultDependencies=yes) all require basic.target by default.
When processing a payment transaction, double-check the
match between the amount of the transaction and the
amount of the SO, to be sure that we won't be validating
a SO that has been modified since the payment.
Such cases have to be double-checked manually.
Also add a bit of extra logging to make auditing ecommerce
transactions easier.
In addition to being mostly useless because Paypal's API
changes are supposed to be backwards-compatible, this
warning was using inconsistent version numbers.
Switched to a simple INFO line with IPN version.
Current behavior before PR: if you create a new record within a one2many
field and the model's form has a clickable status bar defined, clicking
this status bar will raise an exception because the virtual id
(one2many_v_XXXX) will be passed to the model's write method
Desired behavior after PR is merged: clicking just changes the cached
value
The SQL view `crm_partner_report_assign`
makes a join on `account_invoice_report`
A column is added to
`account_invoice_report` in the module
`sale` (`section_id` is added to the view),
making the SQL view `account_invoice_report`
replaced automatically at the install/update
of the `sale` module, which leads
to the automatic deletion of the SQL
view `crm_partner_report_assign`,
because the SQL view `account_invoice_report` is
altered.
Therefore, after the install/update of the `sale`
module, the view `crm_partner_report_assign` was
deleted, and the "partnership anaylsis" unusable.
This revision makes sure to init the
`crm.partner.report.assign` report after
every init of the `account.invoice.report`.
opw-674177
request.website.get_languages returns a list of tuple in the form:
(`language code`, `language name`)
With this commit the code first check if there is a language exactly
matching, and only if failed check if there is a match on the short
form.
closes#11613
opw-672412
If the costing method of the product is "average", the price unit
of the stock move is set in the currency of the field "price_currency_id"
with the function "do_partial" (addons/stock/stock.py).
opw:672552
When checking `Attach Google documents to any record`
in the general settings, if you are not redirected
to a module, but, instead, the current page is refreshed
(the wizard is reloaded instead of creating a new
configuration wizard),
the default value for `google_drive_uri` was not correctly
loaded, the `client_id` in the URL
remained `False` because the wizard was not being
re-created, but reloaded,
and therefore `default_get` hasn't been re-called,
and the `client_id` changed
(it was added to the system parameters after
the installation of the module)
Therefore, the link did not include the correct
`client_id`, and it leaded to the inabibility
to use the URL:
401. That’s an error.
The OAuth client was not found.
Replacing the simple char fields by a function
field, with the correct store trigger,
force the URL value to be reloaded
when the system parameter is inserted.
opw-673274
This revision is related to 9752aedb4e
It looks like in some cases, the user cannot read the
partner associated to his own cart.
This is the case when shopping without being signed in.
opw-673187
Add `display_start` and `display_stop` to the fields
which are public even if the event is marked as private.
There is no reason it should be public,
especially if `start` and `stop` are. Besides,
this leads to issues in
`get_search_fields`, when doing:
```
sort_fields['sort_start'] = browse_event['display_start'].replace(' ', '').replace('-', '')
```
opw-672997
Commits 7b7f3fa and d6c88b8 filter out special periods from the account
balances. However, this filtering is not necessary anymore for a closed
fiscal year. The result is that the opening balance becomes wrong as
soon as the previous fiscal year is closed.
This commit fix this by computing the balance over all fiscal years.
Closes#11515
Martin Trigaux
65HQqp5QTq8QwA3f
Jeremy Kersten
Denis Ledoux
Goffin Simon
Joren Van Onder
Odoo Translation Bot
Nicolas Lempereur
Alexis de Lattre
Nicolas Seinlet
Nicolas Martinelli
Olivier Dony
Adrien Peiffer (ACSONE)
Holger Brunn
Christophe Simonis
Ludwik Trammer
Levent Karakas
Levent Karakas
oihane
Stefan Rijnhart
Simon Lejeune
Xavier Morel
Manuel Vázquez Acosta
Peter Hahn