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.
The tests constits of creating an employee and give him a contract.
These are not smart tests. This module uses many base action rule,
but they are already tested in base_action_rule module, so removing
the tests seems better.
Following commit 8276fb585, the data exported should match the data
displayed on the list view. Therefore, we need to make sure that the
context used match the context of the list view.
When a filter is applied in the list view, the context is evaluated
thanks to pyeval (see the call to `/web/dataset/search_read`). The fix
is to evaluate the context in a similar way.
opw-674473
- Fix for status widget (b25c054c93) moved
to appropriate file: addons/web/static/src/js/views/form_widgets.js
even though the problem is less severe in 9.0 (no crash but triggers
form save, which is unnecessary)
- Fix for website_event_sale ignored (880e951f34)
because the problem does not exist anymore in 9.0, probably due to
refactoring 66871ee65b
When deleting the analytic account of an account move line(aml),
the analytic lines linked to this aml must be unlinked even if
the aml is not linked to another account analytic.
Used case:
Once a analytic account is removed from a journal line, the analytic line
created for this journal line has to be removed from this analytic account.
Inspired from 8.0
opw:673803
The short code is always required for the following reasons:
- The auto-generated code is useless for search purpose because user
cannot choose it (BNK or CSH is maybe not meaningful for him)
- If the system cannot generate an unused journal code, the user is
stuck since the field is read-only in the interface.
However, the code can still be auto-generated, although it is required
in the interface. This is to avoid breaking modules that would expect
this feature. At the same time, the logic has been improved to reduce
the number of search requests.
opw-674485
When the warning on form view is closed by cancel or OK button, all is
well. But if the modal is closed by any other way the def will stay pending
blocking next operations.
This commit set the deferred as dejected if not resolved when the modale
is closed.
closes#11688
opw-671371
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.
/!\ This commit must not be forward-ported on saas-10 (the file that
is modified here does not exist anymore anyway).
Since the website/web_editor split, the mt/mb definitions were not
included in reports anymore. Those were not the only rules that
were forgotten.
As it would be tricky to add the whole files where those rules are
defined now in the assets of stables branches, this commit only
restores the missing css rules by adding them in the report.css file.
Note: after the assets refactoring that has been done in saas-10, this
problem will no longer appear.
Since the website/web_editor split, the mt/mb definitions were not
included in reports anymore. Those were not the only rules that
were forgotten. In 9.0, as a fix, those rules were added back in the
report.css file.
As the assets have been refactored in saas-10, the fix here is to
link the missing file (unique in saas-10) in the report assets.
- Rewrite the code to new api without changes
business behavior
- Remove old v7 backward compatibility method
- Regroup view definitions in the same xml file
- Use read_group for computed fields
This inheritance wasn't working till the commit of rco, modifying
models inheritance.
Anyway, `website_message_ids` field is already defined on several
models (product, slide, forum questions, blog post, ...), and each
of them have a different domain attribute.
So making the mail.thread mixin providing this field is not so
interessting since it will be overrided for specific behavior.
We remove this field as it can't be usefull and generic.
The introduction of the new pos.config dashboard at
48ab50ed0d does not filter non-active
pos.configs. There are no constraints against opening sessions on
inactive or deprecated pos.configs so after deprecating/inactivating
users could still open new sessions through the dashboard.
opw-673020
When a lead is set to 'Won', the date_closed is defined. However, the
user might have clicked by mistake, and he might want to change the
state back. We need to take this into account, otherwise the lead is
considered as closed although it is not.
opw-674226
The POS generates journal entries for both the amount of money the
customer pays and the amount of money the POS user returns to the
customer (the 'change'). Whether or not this is the correct thing to do
is up for debate, but we can't change that in stable anyway.
One of the main issues is that in 9.0 accounting will propose
unreconciled payments belonging to the customer on open, unpaid
invoices. This does not work well with the account entries generated by
the POS. Accounting will propose the amount the customer paid, without
taking into account the change.
Example: a customer buys $7 worth of products and pays with a $10
bill. The customer gets $3 change. The invoice will propose the $10
payment.
When you add that payment to the invoice a residual amount ($3 in the
example) will remain on the paymentline, complicating everything even
more.
Although we cannot change how the POS does accounting in a stable
release, we at least want people to be able to easily handle invoices
generated through the POS. To achieve that this patch will make the
backend match the payment to the total amount of the invoice removing
any potential change.
opw-671486
Joren Van Onder