Now we use the same decimal precision for cost in table 'Historization cost'
and 'product'.
It is one fix, but that will not fix the case where decimal precision has been
updated between 2 historizations.
This commit closes#12861
Posted moves are not protected from modification if the journal is set
to 'autopost'.
If an account move is posted in a journal with 'Autopost' set, it is
possible to modify the associated move lines without any restriction.
This can for example lead to the creation of unbalanced moves.
The original issue fixed by this extra condition
(https://bugs.launchpad.net/openobject-addons/+bug/615268) does not
occur if the commit is reverted.
This reverts 4e95e4223Closes#12014
opw-683165
Old check was always ignored since 0 is False.
This commit closes#12715
Other fix; when we detach an event, we reset the rrule_type to avoid to have a
warning popup (about empty final_date) if the old one value was end_date.
"total_invoiced" must only take customer invoices into account because
when you click on the button "invoiced" in the partner view form
you just see the customer invoices.
Adaptation for 8.0 of 9.0 fix made at 37569695
Closes#12044
The pricelist report might show price incorrectly rounded. For example,
a calculated price of 20.625 will be displayed as 20.62 in the report
since `formatLang` does not apply a rounding but simply truncate the
value.
Fixes#12875
The name field is the name of the product.template while the display_name will
contains the variant description and product code to allow to identitfy which
product.product is moved.
Closes#11311
The onchange should have the signature with `ids` instead of `id` for a proper
guess.
Without this, the method can not be overriden with an api.multi (the return
result is a list of dictionnary which is not understood by the ORM as a proper
return format).
Fixes#12856
The fith arguemnt of the search method in count in new API.
Passing all arguments as positional arguments will make the context passed for
the value of the `count` argument.
bbc67ec is a similar fix in 9.0
Closes#12830
When the schema of a view change (e.g. drop of column), the "CREATE OR REPLACE"
will not be enough and dropping the view is required.
Fixes#12754Closes#12756
Steps to reproduce:
1. Activate the following options
** Settings > Warehouse > Products > Manage different units of measure for products
** Settings > Accounting > Accounting & Finance > Analytic accouting
2. Desactivate the following option
** Settings > Accounting > Analytic accouting > Sale > Use multiple analytic accounts on sales
3. Create a Sale order
** Add 2 qty of the product iMac
** Add in quote the delivery method "Normal Delivery Charges" and set 2 qty
** Set an analytic account under Contract/Analytic
** Set the field Create Invoice to "On delivery Order"
4. Deliver only 1 quantity of the iMac and then create the invoice
5. Deliver the last quantity of the iMac and then create the invoice
Behavior before the fix:
The first invoice contains 2 qty of the Transport
The second invoice contains 1 qty of the Transport, has no analytic account set, has no UOM set
Behavior after the fix:
The first invoice contains 2 qty of the Transport
The second invoice contains 0 qty of the Transport because it has already been invoiced
Closed#12644
opw:682284
In case of a move where source location = destination location, the result of
SUM(quantity) would be 0 and ending up with a division by zero.
Closes#12247Closes#12423
The view yields one line per stock move, with a price/unit on each line.
It doesn't make sense to sum price/units, the avg will be only meaningful when
grouping per product but it's correct in the default state.
Closes#11309
We don't mount /boot in fstab to prevent systemd-udev looking for
corresponding kernel modules in /lib/modules. We need to do this
because the modified kernel-qemu image we use for emulation is usually
not 100% the same version as in the Raspbian image. Therefore
systemd-udev won't be able to find the 'correct' kernel modules in
/lib/modules.
This causes issues when the raspberrypi-kernel package is updated
however. apt will update /lib/modules and will write the new
kernel{7,}.img files to /boot. Before this patch /boot was just a
directory on /dev/sda2, not the 'real' /boot which is on /dev/sda1. So
you'd end up with old, not updated kernel images but new, updated
kernel modules in /lib/modules.
This mounts /boot after the system booted. /boot gets mapped to
/dev/sda1 by /etc/udev/rules.d/90-qemu.rules.
Fixes#12650
opw-682320
When an applicant is moved from a stage to another, an email is sent to the
applicant(s) if an email template is specified on the stage.
The active_ids is correctly set in the compose context to be used by the
send_mail method to send a message to all the applicants in the new stage.
However, a potential active_id may be propagated from a previous action.
This is the case when a user goes from a Job Position record to the list of
applications and change the stage using the kanban view (active_id & active_ids
is the id of the hr.job).
The default_get method of mail.compose.message will use the active_id as the
default value for the field res_id which is wrong as it is the id of another
record).
Forcing the value at False instead of ids[0] as it would not work in batch mode.
The list of records is correctly used in send_mail anyway.
Closes#12494
When a product is a kit and a discount is applied thanks to a pricelist,
the discount is counted twice if the invoice is created from the stock
picking.
This is because the pricelist will modify the price unit, but moreover
the discount will be applied a second time by the method
`_compute_price` of the account move line.
opw-676838
Do not redefine the view arch but do a proper inherit.
It was a problem as the redefinition removed some fields (headers,..).
It was also a problem if crm_profiling was uninstalled as the redefinition was
not removed.
Closes#12454
The group_lines method didn't make the sum of the quantity field, hence resulting in incorrect results when making product based statistics from the account.move.line records.
Courtesy of Luc De Meyer. Was PR #10551
The `related_usage` field of `purchase.order`
is a related field to the location `usage` field,
which is defined in order to display/hide
some other field in the PO according to the location usage
This is purely a technical field, which is set only
to change the form view according to the location
usage.
This is not expected to change the location usage
through this field, this field must therefore
be set to readonly.
A change on the location usage could happen because
of the `onchange_picking_type_id`:
If the user changed the picking type, and then the location,
the usage returned by the `onchange_picking_type_id` was
applied on the location, and this must not have happened.
In addition, since `related_usage` is a related to the location
usage, it should be changed as well when the location is changed.
(in the new api, this is no longer required, the related field
is updated automatically).
This revision therefore adds an onchange on the location as well,
to handle this.
opw-676428
[FIX] anonymization: default anonymization fields
res_partner.name was twice : remove one
res_users.name doesn't exist (now, it use the partner name) : remove
remove training.* fields that do not exists
Closes#11806
Partial backport of ef19830. The error message cannot be included for
compatibility reason, but the browser will highlight the field in red,
which should be enough to locate the error.
opw-677121
Fixing the error ValueError: "name 'date_from' is not defined"
while evaluating '[date_from, date_to, employee_id, contract_id]'
This commit close#12383, close#8883, close#3116
To match the behaviour on sale.order.line.
Purchase line form is expected to be open in popup (where parent is defined),
not individually when creating a line alone is not useful.
Fixes#6644Closes#12325
* v5.2: Añadida retención 19,5% arrendamientos.
* v5.1: Renombrado todo lo relacionado con arrendamientos para no incluir la
palabra "IRPF", ya que no es como tal IRPF.
* v5.0: Se ha rehecho toda la parte de impuestos para dar mayor facilidad de
consulta de los datos para las declaraciones de la AEAT y para cubrir todas
las casuísticas fiscales españolas actuales. Éstas son las características
más destacadas:
* Desdoblamiento de los impuestos principales para bienes y para servicios.
* Nuevo árbol de códigos de impuestos orientado a cada modelo de la AEAT.
* Nuevos códigos para los códigos de impuestos para facilitar su
actualización.
* La casilla del modelo viene ahora en la descripción, no en el código.
* Posiciones fiscales ajustadas para el desdoblamiento.
* Nuevo impuesto y posición fiscal para retención IRPF 19%.
* Nuevo impuesto para revendedores con recargo de equivalencia.
* Nuevas posiciones fiscales para retenciones de arrendamientos.
* Pequeños ajustes en cuentas contables.
Closes#8453
The hw_scanner module not only supports barcode readers (although that
was it's original intention). It also happens to support certain card
readers (like the MagTek Dynamag we use for Mercury) because they act
the same way as barcode scanners (like a keyboard and end sequence with
ENTER).
Before we supported Mercury there was no real reason to support multiple
devices on the POSBox, because it didn't make much sense to attach >1
barcode reader to the same POSBox. With Mercury however, this is a real
use case, as users want both a barcode reader and a card reader.
This commit implements support for this, while keeping the functionality
as close as possible to how it was before (eg. care was taken to not
break plug and play support).
When an invoice is created automatically thanks to the cron task, the
superuser is used. However, this implies that the company of the
superuser will be used for the account invoice creation, leading to
potentially incorrect taxes and fiscal positions.
opw-669714
The test `test_balanced_exchanges_gain_loss`
failed on Jun 6, because it created a specific rate
for today's date at midnight
(e.g. on Jun 6, 201x-06-06 00:00:00) for the test purpose,
but a rate is created in the demo data for Jun 6 midnight exactly:
`base.rateUSDbis`, making the test confused about which rate
to use.
We solve this by making the test use the rate `base.rateUSDbis`,
modifying the rate for its own need, instead of creating a new
rate.
HTML content should be escaped before being sanitized. Any content (link, image,
code,...) that is acceptable in usual mail.message but should not be interprated
when posted on a comment of the forum.
Fixes#3737
If we take the below facts:
- The country select is set as disabled
when Shipping is set to "Ship to the same address"
- The disable property of select inputs is
removed when shipping is set to
`create a new address`:
In `website_sale.js`:
```
$selects.attr("disabled", value <= 0 ? null : "disabled" ).prop("disabled", value <= 0 ? null : "disabled" );
```
We can safely assume that the select input "State / Province" was supposed
to be set as `disabled` in the first place, not as `readonly`
Before this revision, State / Provice was greyed when choosing
"Create a new address" for shipping, and selecting the United States
(but the select input was still usable, though, it was just greyed)
opw-675739
When subscribing a user to a mailing list, the `mail.mass_mailing.contact`
created is processed to identify it's name and email from the address (method
`get_name_email` called in `add_to_list` and `name_create`).
For a better consistency, the search of existing contacts should also be done
using the method `get_name_email`.
This avoids that subscribing twice `Example <example@example.com>` fails to
detect duplicates and creates two subscriptions.
Closes#12265
xml template was using color name, because color index was empty.
It works in English, but once translated (in french e.g.) we have background-color:noir
Fix#12251
The field generation is most of the time following the pattern
`field_<table name>_<field name>`
but in case of name clash (e.g. res.partner.category - id and res.partner -
category_id), the id of ir.model.field is added at the end of the external id
during the field creation.
The more flexible way to link to an ir.model.field is to use the syntax
`search=[('model', '=', <model>), ('name', '=', <field name>)]`
to avoid errors as in #12192 when the "first" external id no longer exists.
Fixes#12192Closes#12198
By default, when reading a m2m field, entries that are
deactivated in the destination table are not included.
This behavior is desirable in some cases (e.g. for
"tags" or "categories", but not for entries that
significantly impact other field values in the parent
record, such as taxes.
The problem is rather obvious: when displaying a
paid invoice that used taxes that are now deactivated,
the taxes are hidden while they still affect the
computed amount. And after cancelling + resetting
to draft, the tax is not taken into account anymore,
while still being linked.
Forcing the field-level (python) domain to include
both active and inactive entries solves the problem:
- when reading, displaying and recomputing values,
deactivated taxes will be included.
- when trying to pick a tax, deactivated entries
will still be ignored, as expected.
This commit applies the technique to all m2m
fields that refer to taxes.
Fixes#12066
opw-677751
'foo %s bar' % 'alice' if False else 'bob' returns 'bob', not 'foo bob bar'
The previous strings returns '>=' when the direction is future while it should
be 'COALESCE(l.date_maturity,l.date) >= %s'
Fixes#10654Closes#10695
9f0120d73b solved this issue already, but
it was only applied to POS orderlines. There is other data on the
report (eg. payments, taxes, ...) that should also correctly respect the
user time zone as well.
opw-678748
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
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
This revision is related to 99d8cd6
Avoid to check the journal centralization
mutliple times, for each move lines.
Checking the journal centralization
for each journal for each period just
before the call to `super` is enough.
Before this revision,
if a large number of move lines
was passed in the `ids` parameter
of the `write` method, with all
the same journal / period, this
could lead to huge performances issues,
the `_check_moves` being called
a large number of times for the same
journal and period couple, uselessly.
opw-672797
When attempting to pay a cart in the ecommerce,
if the customer went on the payment acquirer site
(meaning, the `payment.transaction` is created
in the database), then come back to the checkout form
using the browser back button, and changed his customer
details (address, email, phone,...),
these changes in the details were not applied
in the `payment.transaction` record that was being
re-used.
e.g.
Checkout > Confirm > Choose Paypal, Pay Now
> History back to the checkout and apply changes
in the address > Confirm > Pay Now.
Commit 4a0b6f6 slightly improves the performances of `action_assign` by
skipping moves which already have pack operations. However, if the move
is not completely assigned, it prevents the possibility to search for
new quants to assign to the given move.
opw-672069
When adding new lines to an existing statement,
the order of the lines was not kept,
due to the re-sequencing operation done in the
override of `write` in `account.bank.statement`:
```
for statement in self.browse(cr, uid, ids, context):
for idx, line in enumerate(statement.line_ids):
account_bank_statement_line_obj.write(cr, uid, [line.id], {'sequence': idx + 1}, context=context)
```
as the lines order was based on `statement_id desc, sequence`,
which is the same for all lines added,
(except if the order is forced in the web client,
using the handle widget)
and, therefore, the order
of the lines returned by `statement.line_ids` was
not determinist.
Adding the `id` to the lines order
(as it's done in `sale.order`, for instance),
solves the issue, as the lines will then be fetched
in the order they were created.
opw-667541
When validating a payment transaction,
if the cart (order) cannot be confirmed or
the email cannot be sent for any reason
(instance, the email template is broken),
the transaction must continue, so the payment
transaction can be set to `done` or `pending`.
In other words, not sending the confirmation
email or not confirming the sale order must
not be blocking to mark the payment
transaction as done.
opw-672486
Commit 7b7f3fa filters out the special periods. However, the filtering
should be done only for the display in the form view, nto for the
reporting which is actually correct.
opw-672531
In v8.0 and saas-6, the PoS does not support the concept of fiscal
position. Therefore, the invoice generated should not use it, otherwise
there might be an inconsistency between the PoS order and the invoice.
FORWARDPORT TO SAAS-6 ONLY!
Fixes#11299
opw-671743
When using sequences per fiscal year,
the sequence used to build the bank
statement name must be the according fiscal
year sequence.
opw-671937
Closes#11185
There are 2 journal items missing on the accounting entry that
represents the assignation of the landed costs (for a product that has
already left the stock!) => expense account at the debit and stock
output account at the credit (amount is equal to the cost of the landed
cost)
opw-671311
When checking the route of a product, if the product is set with route drop shipping
then the product is available.
Inspired from 14fd46c0d59dbb0365019a21bf1263b17ab99dbb
opw:672392
POSBoxes will be registered with the government. If a POSBox is not
registered it won't load the blackbox driver, preventing communication
with the Fiscal Data Module.
When computing the balance, debit and/or credit, the opening period must
be filtered out. Otherwise, the invoices which are still opened at the
time of the period closing will be counted twice.
opw-670584
When transfering the pack, the priority to the moves in state "assigned"
or partially_available(=true) must be given.
Used case (steps):
-set warehouse with three steps to delivery
-create one product A with qty on hand 10
-create sale order with first line product A by qty 2 and the second line with product A with qty 10
-confirm sale order
-check availability
-transfer pick by qty 10
-transfer pack by qty 10
The pack couldn't be transered
Now the pack is transfered.
Closes: #10764
opw:668682
When using the left/riht arrow to switch of record
in a form view,
the rendering of the `char_domain` widget was done too
early, before all fields are ready / set, and if the
domain of the previous record could not be applied
on the current record, it leaded to a traceback.
This revision introduce a new deffered,
because I coudln't find one that was doing
what I was looking for:
- `is_initialized` is a defferred which is
resolved when the form view has finished
its rendering for the first time
- `reload_mutex` is a mutex used only when reloading or
switch to left/right record.
While the one needed in this case is a deferred
which is resolved when the record has finished
being rendered, wether when its when coming
from the list view to the form view (and it's
not the first time the form view is loaded,
e.g. list view -> form view -> list view -> form view, another record),
or on the switch of left/right record.
opw-671594
When a "Drop Shipping" route is used on a product, the origin document
is duplicated on the PO created. This is because in this case,
po_rec.origin and procurement.origin are the same.
opw-671039
Introduced by eefc76f
Only the supplier taxes of the company set in the procurement
must be set in the PO.
Backport from f5989bc3d8f10a0354a7d085576276d4e1778fbd
opw:671449
When creating work center, a resource.resource record is created.
Then a member of group_mrp_manager is allowed to create resource.resource record.
opw:671218
Edge >=12 throws an error (code 800a025e) when calling the select()
method on an input element that is not currently part of document and
has a non-empty value.
When adding a paymentline a "change:selected_paymentline" event gets
triggered which in turn triggers the focus_selected_line function before
the actual paymentline gets rendered.
opw-671426
When creating thousands of production lots in batch, the
extra call to write() cuts performance in 2, and can be
replaced by an appropriate context when calling super(),
as all the default values are computed correctly.
The only case that could possibly fail is when the product_id
is not passed to the create() call but comes instead from
defaut values (ir.values).
This case is very rare and considered a manual exception
where the expiry dates can be input manually.
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
Up to this revision, barcodes set in reports are generated
using the controller `/report/barcode`,
using a `img` HTML tag, e.g. (from `report_location_barcode`)
```
<img t-if="not o.loc_barcode"
t-att-src="'/report/barcode/?type=%s&value=%s&width=%s&height=%s'
% ('Code128', o.name, 600, 100)" style="width:300px;height:50px"/>
``
This `/report/barcode` route is set as `auth='user'`, meaning
the route can only be accessed by signed in users.
When wkhtmltopdf prints a report containing such a barcode,
it calls this `report/barcode` route, making sure to pass
the request session in the cookies, so wkhtmltopdf
uses the same session than the one of the user. This is
needed, as only users can access this `report/barcode/` route.
This session is passed in `report.py`, in the method
`_run_wkhtmltopdf`, thanks to the --cookie wkhtmltopdf
parameter.
Nevertheless, if a report is printed through the website
front-end, as public (without a signed in user), the request
session is not associated to a signed in user, and therefore
the route `/report/barcode` refuses the access / redirects
to the login, making it impossible to print a report
containing a barcode without being signed in. This even
if the report is printed as `sudo` through a controller
(as this is the session of the not signed in user which is passed,
not a session associated to `sudo).
Fixes#10621
opw-667797
It looks like reportlab doesn't handle well
UPC-A barcodes.
As UPC-A barcodes became EAN13 barcodes when
adding a `0` to the beginning of the barcode,
and the render is the same, we ask reportlab
a EAN13 barcode type when a UPC-A barcode is asked,
making sure to add the `0` automatically first.
From Wikipedia:
```
The EAN was developed as a superset of UPC,
adding an extra digit to the beginning of every UPC number.
[...]
the original rules for UPC are treated as a '0'
if read as EAN-13.
A UPC barcode XXXXXXXXXXXX therefore is the EAN-13 barcode 0XXXXXXXXXXXX.
It is possible to prefix a UPC barcode with a 0;
they become EAN-13 rather than UPC-A.
This does not change the check digit.
All point-of-sale systems can now understand both equally.
```
opw-670560
I'm not sure why the serial timeout is so aggressive, but I assume there
is a reason for it. During probing however, we shouldn't use such an
aggressive timeout because if we miss the device during initial startup
we'll never find it since we only probe devices once.
After plugging in multiple identical serial to USB interfaces, only the
last one will be available under /dev/serial/by-id/ because they'll have
identical IDs. Instead use /dev/serial/by-path/ which does not have this
issue.
We support the Mettler Toledo scales which have their own built-in USB
to serial interface. Due to continuing issues with that built-in
interface we will also support the scale configured in raw RS-232 mode
which seems to be more reliable.
This means that in order to connect the scale you'll need a third party
USB to serial interface (unless you have built-in serial interfaces, but
the POSBox doesn't).
The main difficulty this poses is that using this approach we cannot use
the name of the interface to find the device. When using the built-in
interface of the scale the interface would identify with an ID
containing 'mettler' and 'toledo'. When using a third party interface
the ID will instead contain information about the third party
interface. To fix this we use a probe-based approach, probing every
available serial interface until we find one that returns a response to
our probe. This approach will work with both third party interfaces and
the built-in interface of the scale.
Contrary to probe-based approach used in hw_blackbox_be this one is
slightly more complicated because hw_scale is written in such a way that
it is 'plug and play', which means that as long as the module is running
it will continually try to find a scale. This is fine, but we don't want
to keep sending probes to eg. Fiscal Data Modules, which could lead to
issues. Therefore we will only probe every device once. When we lose an
existing, confirmed connection to a scale we will however keep retrying
to connect to that particular device.
The alternate languages links set in the page `<head>`
were not translated in each language, but within the language
the user is browsing the website.
This leaded to SEO referencing issues, as these links leaded
to (30x) redirections if followed, to translate the URL slug
within the new current language.
e.g.
`/fr_FR/shop/product/bose-mini-bluetooth-speaker-7`
automatically redirected to
`/fr_FR/shop/product/mini-haut-parleur-bluetooth-bose-7`
And it was the first link which was displayed as alternate link
when being in another language than French, while it should
be the second (to avoid the useless redirection).
opw-669979
When we render the payment screen the current value of the current
paymentline is rendered to a string using
Paymentline.get_amount_str(). This conversion always rendered numbers
with a decimal separator of '.' because it just used
Number.toFixed(). This used to be fine but
5a10903e9b made the POS adhere to the set
decimal and thousands separator. Because of this, the POS now has to
parse the input with web.parse_value() which takes into account these
separators. When parse_value() parses a float it first deletes the
thousands separators and then replaces the decimal separator with '.'
before it gets cast to a Number.
In German (and other languages), the '.' is used as a thousands
separator which means that it will get deleted by parse_value() so
you'll end up with '12.34' being interpreted as '1234'. Because of this
it is important that we ensure that the default value that appears in
the input uses the correct separators.
The aforementioned issue only occurs when the user changes the default
value in the paymentline. Only then does a conversion take place from
String to Number. So just clicking on a payment method of type 'Bank'
and validating it would work fine, only when the payment amount was
updated would the issue occur.
Fixes#9395Closes#10952
note: this should not be forward-ported to >8.0 because later versions
use the rewritten payment screen which is completely different from the
one in 8.0.
When delivering a delivery order (`stock.picking.out`),
which generates accounting entries
e.g. thanks to the real-time stock valuation,
the date of the move set was the UTC today date, while it must
be the user's today date, using the timezone passed in the
context.
This prevented the delivery of the `stock.picking.out`
when the `Check date in period` boolean was checked
in the stock journal, and the user date is in the previous
month compared to the UTC date, as the date set on the move
entries were not in the selected period for these move entries.
e.g. When the user timezone is UTC -8, and his current time is
2016-02-29 18:00:00, the UTC date is 2016-03-01 02:00:00, the
period chosen is February (correct), but the date on the move
entries were set to 2016-03-01.
opw-670820
The intrastat report period should match the accounting period of the
invoice. This might not be the case if the user manually chooses an
accounting period which does not match the invoice date.
opw-668827
In an environment where multiple database are available the company_logo
controller in the web module will return a placeholder logo (the Odoo
logo) if it can't figure out what db the request belongs to. This logo
is used on the ESC/POS receipts.
Because we load the logo with an anonymous CORS request there is no
authentication on the request. This is necessary because the POS tends
to not be served over HTTPS whereas the rest of Odoo is. Without this
crossOrigin attribute we could potentially end up in a situation where
the canvas is considered tainted by the browser which would prevent us
from extracting the canvas' data with toDataURL(). So removing the
crossOrigin attribute is not an option, specifying the db is the next
best thing.
opw-670471
note: in >=9.0 session is a variable defined in the js module instead of
a property on PosModel, so 'self.session.db' should become 'session.db'.
From issue 660592. (already fixed in v9) When products are received from a purchase line
with taxes included, the cost for the stock valuation (on the stock move) on reception
should be without these taxes included.
Checking url_list for duplicates is O(n).
Use url_set instead of url_list to improve to O(1).
Otherwise sitemap generation even for a million products will never finish.
Close#11106
If an event is private, a bunch of fields
are hidden for the users not being
the owner of the event, even for sudo.
The fields on which depends the `rrule`
computation were part of the hidden/private
fields.
In addition, the `rrule` is always computed
as sudo. See `_get_rulestring`.
Therefore, the `rrule` of recurrent private events
was not correctly computed when the owner wasn't
the administrator.
opw-670295
Iterator was consuming the first 45k records.
So don't need to specify an offset, because that will ignore the next 45k.
Eg: if step of 5, and range(1,13),
it will only use [1, 2, 3, 4, 5, 11, 12, 13]
Cherry-pick/backport of de8296c3a86da5e4ae35edcdb563d317dac32e76
The Sales Details report wizard gives the possibility
to print the details of the POS orders between two dates.
The fields in the wizard are of type `date`,
while the orders dates are of type `datetime`.
`00:00:00` and `23:59:59` were naively added
to the `date_start` and `date_end` (respectively) to
handle the case.
But, this doesn't take care of the user time zone:
When a user choose between February 24th and February 25th,
it's within his time zone, and therefore, for the search,
where the datetime are in UTC, adding `00:00:00` isn't enough,
the dates have to be converted from the user time zone
to UTC.
opw-6698831
CSV export was added in f146e2a and since then newline were not
exported.
But new line should be allowed if the string is quoted by " characters
which is done in Odoo.
closes#11005
opw-667853
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
The product price unit should be rounded before being used in any
operation. The PoS calls the method `read` in order to get the necessary
fields. However, the product price is a non-stored calculated float. In
old API, such a field is not rounded by the `read` method. It means that
a product price of 28.067 (for example thanks to the use of a pricelist)
will be rounded to 28.07 at the server level but not rounded in the PoS
JS layer.
To lower the impact of the fix, the rounding is done at the JS level,
and not in the `_product_price` method.
opw-669024
The month used for an intrastat.report record must be the same as
the invoice_date set on the invoice.
Backport of d1d896621fffc79c73aeee07c8cb1c7a49a36411
opw-668827
In the base model `account.voucher`, in the module `account_voucher`,
the field `number` is set with `copy=False`, to avoid
copy the voucher number and force to re-use the voucher sequence.
The module `account_check_writing` redefine this column,
but forgot to set the `copy=False`. Therefore, once
this module installed, the voucher number is copied
on the voucher duplication.
opw-669154
DO NOT FORWARD-PORT: the functionality is not used anymore in v9
Commit aaf9badb filters the returned ids by keeping the domain in the
request. However, `this.dataset.domain` might be empty, while
`self.dataset.get_domain()` will retrieve it from the model.
Since `get_domain` is not always defined on the dataset, we keep
`this.dataset.domain` as a fallback. The fix is not great, and a better
solution should be found in master branch when the web refactoring is
done.
opw-666755
When an "hr.holliday" record is created or modified, the employee_id
linked to this record has to be added in the followers.
Inspired from ff1d384
opw:668515
It was like that for the date field, which is taken into account for the forecast quantity,
but in the view the scheduled date field is shown. We put the scheduled date equal to the date.
That way it is clear to the user when the products are foreseen to be consumed.
The revision 29bd622521
aimed to improve the performance by changing
the view index, to use a BIGINT instead of a text.
It was assumed that the index used
(`stock_move.id`) could not appear
multiple times with the JOINs and
group bys defined.
This was in fact possible, if a
stock move is associated to
several quants with different costs,
because of the JOIN on the many2many table
`stock_quant_move_rel`
linking quants to moves,
and the GROUP BY
`price_unit_on_quant`
that caused the different moves/quants association
not to be merged within one unique line
if the costs on the quants are different.
Instead of the group by, we now aggregate the quants
costs, using the weighted average, so the index
used can be unique, as expected.
From now, the inventory value per line in
this report view can therefore
be different than what can be found on the quants,
but this report view is based on the stock moves
rather than the stock quants, and this is therefore accepted.
In other words, the inventory value is computed for the stock move
rather than for the stock quant.
opw-658903
Use the same factor than the one used when
computing the products to consume at confirm.
Before, the quantity of products to consume was wrong
when using a different unit of measure in the BOM
than in the production order.
e.g.
- BoM defined as:
- 1 dozen of milk
- BoM lines: 1 cow
- Production order:
- 1 unit of milk
- BoM: The above one
At confirm, the quantity to consume is 0,083 cow (1 cow / 12, this is correct)
But, when updating the quantity to 2.0,
it updated the quantity of cow to 24.0, instead of 0,16.
opw-669447
The POSBox attempts to maintain whatever Wi-Fi connection it has as best
it can. When it loses it's current Wi-Fi connection it will attempt
to recreate it every 30 seconds. This works well, but a side-effect of
this is that it'll also print a 'Could not connect to LAN' ticket every
time it fails. If you where to leave the POSBox with Wi-Fi on for an
extended period of time you could return to a lot of 'Could not connect
to LAN' tickets.
This makes it so that the 'Could not connect to LAN' ticket only gets
printed once upon connection loss. Although it would be simpler to just
not print this ticket at all when losing connection, it is very useful
to know when the POSBox has lost connection. Otherwise when it loses
connection it would stop working and noone would know why.
When converting a new API call to an old API call,
the context is expected to be found within the kwargs
argument. If not, it is seen as a regular argument.
See `get_context_split` in `openerp/api.py`
As it was not the case in the overidden method
`search` in `marketing_campaign.py`, if a module
overriden the method `search` of
`ir.actions.report.xml` using the new API, the
context wasn't treated as such correctly, and it leaded
to wrong number of arguments passed.
I take the opportunity to pass all arguments
that are passed as kwargs in the base `search`
as kwargs as well, to be clean.
opw-668471
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
Apply the same behaviour as the unlink done on account.invoice.line.
This should properly be implemented with a ondelete=cascade but this is not
possible in stable version as it requires an update.
The kanban CSS applies both a 90 degree rotation and a top-bottom rtl
writing mode to folded kanban group titles. This was initially fine
because browsers didn't support the (SVG) "tb-rl" value for writing-mode
and the property was thus ignored. Firefox 43 (December 2015) and Chrome
48 (January 2016) added support for this value, and thus now end up with
a 180 degree rotation on the title.
Issue #7955 fixed it in 8.0 due to MSIE impact, this is essentially a
backport to 7.0.
close#10687
This controller was very slow as not providing a pricelist computed the price of
all products of all pricelists.
Instead only fetch the prices for the useful products.
Could incorrectly rename the stock.location.path objects, and in case
the route has push_ids but no pull_ids would crash the method entirely.
closes#10747
The margin in a SO line is the difference between the price unit and
the cost price of this SO line. In function "_product_margin" in model
"sale.order.line", the cost price is equal to the purchase_price or
the standard_price of the product. Then the cost price in the SO line
must be set with the same value when creating SO line linked to the delivery.
opw:668090
The order of a bank statement lines is entirely done on the sequence:
`_order = "statement_id desc, sequence"`
The `create` method of `accounT.bank.statement` is overriden
to handle the sequences of each line.
The `write` method as well, except that the set of the sequences
lines is done after the call to `super`. So, if you add
several new lines to a bank statement, the order of the line
you just added can be different before and after save,
as the sequence of these new lines are not set before
actually writting them on the bank statement.
The widget `handle` serves this sequencing purpose. The
fact it isn't used here is most-likely because
it did not exist at the time this was designed.
Besides, this gives the possibility to the user
to add a new line and re-order it where he wants.
For instance, when manually entering a bank statement,
a user could skip unintentionally a line. If he would
like to add it at the right place, before this revision,
he would have to delete all the lines coming
after the line he skipped. Now, he can add
it at the end, and re-order it where he wants.
What is done in the overriden `create` and `write`
is now useless, but we left it for retro-compatibility
purposes, for databases updating their sources without
updating their views.
opw-667541
The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created
When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)
This is why this fix is required.
opw:660658
Usually when setting up a POSBox you want it to have a static IP. The
best way to do that is by configuring whatever DHCP server is
used (usually just on the router) to always assign the same IP to a
certain MAC address (naming depends on what is being used, sometimes
it's called static DHCP but it's also known as DHCP reservations and a
bunch of other names).
The process of setting this up is complicated for a non-technical user,
and this attempts to make it a little bit easier to do by immediately
giving them the correct MAC address they should use. To avoid confusion
this only prints the MAC addresses for interfaces which have an IP
address.
With 003d85b instead of getting the name of the relation
field_relation we get field_relation/id which will get us an xmlid
instead.
But the data about related fields are not gotten all at once when
opening the export modal. They are gotten by clicking on the arrow of
the related record.
It is in this data that the /id will be appended for the field, but when
getting a saved export list, this data may not be available.
This commit immediately add the `/id` when a field is put in "Fields to
export" column, so this inconsistency is no more.
closes#10640fixes#10327
opw-665994
Copy the structure of the sale order report regarding the
partner, invoice and shipping address.
Besides, on a repair order, this is possible
to set a shipping address without setting
an invoice address (if no invoicing is set).
In such a case, the `Invoice address:` must be hidden.
opw-666506
This is possible to unreconcile and then remove journal
items associated to `account.voucher.line`.
When it's done, the voucher is within a corrupted state,
with debits and credits lines without journal item, which
is required.
Because the journal item of this line is empty,
while required, this is no longer possible to use
the "Unreconcile" button, because the form is invalid.
In order to allow to unreconcile a posted customer/supplier
payments with missing journal items, we set
the journal items as required only when the payment
is within the `draft` stage.
opw-667232
Because otherwise a user who has access to a view displaying
supplier_invoice_count will get an access error if he doesn't also have
access to purchase.order, even if that wouldn't have been displayed.
opw-666935
When creating a XLS file with more than 256 columns, the library used
(xlwt) fail since it is targetted to support MS Excel 97 up to
Excel 2003.
But Odoo doesn't has no check and in this given instance (an error
happening in a controller generating a binary filte) the real error
message is lost.
This commit check if the to-be exported data has more than 256 columns,
and if this is the case display an error message without even trying
the export.
closes#10630
opw-660474
When performing a stock valuation at date,
the stock valuation total wasn't equal
to the sum of each line of the report.
This is because the domain forcing the
date wasn't passed to the `search` call
when no group by was applied.
Indeed, when calling
`read_group` with a group by, the lines in the results
contains the domain used for each line, but when
there is no group by applied, this is not the case, the domain
is not included in the line dict returned by `read_group`.
In such a case, therefore, we must use the domain that was passed to
the `read_group` call.
opw-667761
In a survey question of type `matrix`,
nothing prevents to remove a row from the matrix,
even if there are already answers for this line.
If the case happens, the row is deleted, but
not the answers. The answers are therefore orphan.
The answers should probably be deleted when the
row is removed from the survey, but this is a risky
change, and, even, users might want to keep track
of the answers given even if the line doesn't exist
anymore in the survey.
Therefore, we just handle the case when displaying
the survey results,
we ignore matrix answers for which the row no longer
exists.
opw-666393
Suggested alternative descriptions spill out of the boxes if the
description is too long.
PS: same fix as in saas-6 with f7110b46bef2d84cd2ce864f5bdd747457099e1e.
This fix doesn't have to be forwrad ported.
opw:667343
When writing several times on the same record in the same transaction,
the orm raise a Missing error because the rowcount only gives one
difference.
opw:666470
The `stock.picking`.`state` field is set
to track the change of values
(`track_visibility='onchange'`)
It's supposed to write the state changes
within the picking thread.
It does not work properly for function fields,
as the onchange tracking is designed to work
only with direct user changes, direct
`write` operations on the record, while,
here, the state value changes according to the
picking moves changes, for instance.
To solve this, the tracking changes have to be
hooked within the `create` & `write` methods
of the model on which this function depends on.
Therefore, from now, when changes are
performed in the moves, on the fields that
could lead to the picking state change, we
force the tracking of the picking state.
In addition, we had the `mail_notrack` key
in the context when creating back orders,
to avoid displaying the back and forths
in the state
e.g. when transferring 9 units on 10, the
changes were displayed as below:
Draft -> Waiting availability
Waiting Availability -> Ready to Transfer
Ready to Transfer -> Draft
Draft -> Partially available
Partially Available -> Waiting availability
Waiting Availability -> Transferred
opw-666317
When doing a copy of a google drive spreadsheet (in google_drive.py's
copy_doc method, using the following google API call
https://developers.google.com/drive/v2/reference/files/copy). Google
server return an error if we used the old spreadsheet KeyId.
The new FileId is available in the AlternateLink and this commit updates
it.
similar-to: 00c2a99
opw-647222
Jeremy Kersten
Martin Trigaux
Stefan Rijnhart
Olivier Dony
Pedro M. Baeza
Nicolas Martinelli
Odoo Translation Bot
Goffin Simon
Ronald Portier
Denis Ledoux
Daniel-CA
Lionel Sausin
Laetitia Gangloff
Alex Comba
Joren Van Onder
Anton Engelhardt
Alexis de Lattre
Christophe Matthieu
Josse Colpaert
jeffery chen fan
qdp-odoo
luc-demeyer
Simon Leblanc
Jordan Vrtanoski
Shelton Freddy
Peter Hahn
Adrien Peiffer (ACSONE)
Christophe Simonis
Jairo Llopis
Kinner Vachhani
65HQqp5QTq8QwA3f
Nicolas Lempereur
Nicolas Seinlet
Holger Brunn
Ludwik Trammer
Levent Karakas
Levent Karakas
oihane
Simon Lejeune
Xavier Morel
Manuel Vázquez Acosta
eLBati
Anton Chepurov
Stéphane Bidoul
Atchuthan
Daniel Dico
MORIN Fabien
Raphael Collet
Antonio Espinosa
Denis Leemann
bima
xmo-odoo
David Monjoie
Christophe Combelles
