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
From 94ed4ce8c8
The original issue is the following:
- Go to the journal item creation
- Choose a partner
- Add a line => the partner on the journal item is removed
This is because `partner_id` on the account move is a related to
`partner_id` on the account move lines. This is likely to cause errors
during the manual encoding of a journal item, since the relation will
link the partner of the account move to the partner of the first account
move line only.
opw:672354
- The button 'Receive Product' is highlighted and hidden after all the
products are received
- The draft state is name 'RFQ' and not 'Draft PO'
- Do not display 'Re-print RFQ' in state 'sent', as it is not always the case
For some reason this made it into a stable release. Although you can set
a background image on a floor this image never actually got displayed on
the floor in the POS. Only the background_color field is respected.
Something like this is always a bit tricky, because you would either
have to scale the image to fit on the floor (ugly if the user uploads a
low-res image or an image with the wrong aspect ratio), or you would
have to tile the image (also ugly in most cases).
Because of the above and because this has never worked and because I
don't consider it a particularly useful feature we will remove it
completely in master.
opw-674031
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
Related and function manual fields may not be loadable during initial
setup (partial=True) due to dependencies being not loaded. Ignore
theses fields during partial loading.
qsm-odoo