The structure of the product.{product,template} form is the following:
product.product_template_form_view* (both)
|-- product.product_template_only_form_view* (template)
| \-- stock.product_template_form_view_procurement_button
|
|-- product.product_normal_form_view* (product)
| \-- stock.product_form_view_procurement_button
|
\-- stock.view_template_property_form (both)
Previous view was adding weight, volume fields on both view with a attrs that
applies only to the product.template (display only if no template).
This means that the weight was not displayed on product.product form if opened
from a Many2one (using the default product.product view) while the attrs should
not hide it.
Closes#16541Fixes#16428
In a scenario with the following views:
Mod A, view 1*
|-- Mod B, view 2
\-- Mod B, view 3*
view 3 can not rely on the elements added by view 2 in xpath
If view 3 is a primary view, view 1 must be fully resolved first (apply view 2)
before resolving view 3.
Next commit describes a real use-case with product.
Linked to #16541 and #16428
When a membership is created, a redirection is done to the tree view of
the vendor bills. It should be the tree view of the customer invoices.
opw-743241
The prettifying of html when editing sources (user need to be in debug
mode to see the button) was removing too much spaces in some instances.
For example if someone got in a case such as:
<span>hello<b> cruel </b>world!</span>
The spaces between text and tag would be removed (this would work fine
with the space outside of the tag).
This code add a special case so this doesn't happen anymore.
opw-743565
closes#17142
Before this commit data-precision='0' was ignored by qweb rendering.
Now we force the data-precision to be set even if 0. (cast in str)
And add a temporary fallback JS side to catch this case while people don't
update the qweb template.
This commit closes#17050 and closes#17046
With the settings:
- Anglo saxon accounting
- real price on product, perpetual accounting,
- multicurrency
- a product with a very small uom (like gram or kilograms and you want to sell many of them, like 500kg)
Flow: purchasing something in another currency
Before this commit, the rounding of the unit price took place right at the conversion level
which led the rounding errors to be amplified by the quantities when the total price was computed
After this commit, the conversion is done on the unit price but is not rounded yet
Only the prices are rounded, as late as possible
OPW 742293
Closes#17015
The cash_control flag on a session will be true if at least one payment method
is cash and the config has cache control.
However, the prevents to enable the flag on the config if one session in the
past had no cash method. As the field is not stored, it will be recomputed if
displayed (or prefetched) and raise an error, on a past session.
If the session is already closed, never raise an error
opw-744314
The previous trigger would recompute all sessions of a config when modifying
the cash_control flag on the config.
It was not possible to enable cash_control if a previous session wasn't in
cash control mode.
Recompute only when changing the config.
`_cart_find_product_line` can return more than 1 order line . Since it
might be necessary in `website_sale_options`, just prevent the crash.
opw-743805
The maintenance.request "active" field was renamed to "archive" for some
strange reason by commit 9a20c6556f.
The value was also inverted.
Unfortunately, "active" was not replaced in a search filter.
opw-744168
Introduced at 0570033ae7. Normally not a
huge issue (you just end up with a '>' character). But unfortunately
in this case it crashes the hw_escpos driver since it tries to parse
the content of that element as a float.
opw-744222
7836a83b3b was implemented for 9.0 and
uses the pos property. It was forward-ported to saas-11 and up. This
particular property was removed in saas-11 at
467ba386f4 because it was unused.
opw-744222
- Create a contact
- Create a lead
- Convert lead to opportunity w/ link to existing customer option
Salesperson on the lead to opportunity merge overrides the salesperson
in the contact record.
Link with existing customer should not override salesperson on contact
record. The two fields should be independent of each other unless you
are creating a new contact.
opw-659028
opw-740526
When making a quick create for a crm.lead record, the field user_id is set
with its default value (introduced by aa44700dcc)
But the date_open('Assigned') was not set.
When creating a challenge with goal="New opportunities", the new opportinities
are counted with date_open. But when creating an opportunity with the quick create,
it was not counted as date_open was empty.
opw:742751
When creating orders from the interface, all the orders of the current session
are in the cache and slow compute methods are recomputed.
Clear the cache before evaluating to execute _compute_amount_all on the current
order only.
The cache mechanism has changed in v10 and no longer contrains all orders.
opw-741442
Let's consider a stockable product P with a product category PC with costing method = real price,
valuation = perpetual, stock valuation account = SVA and price diff account = PDA.
The cost defined for P in product.template is equal to 1$.
Steps
-Create a PO for P with a price unit = 5$
-Confirm PO and generate the invoice
-Update the qty for P in the invoice and validate it(price unit is still 5$)
Bug:
In the general ledger: a move with a debit of 1$ is created for SVA and a debit of 4$
is created for PDA which is wrong. The expected result is: just a move of 5$ created
for SVA and nothing for PDA because the difference between the purchase price and the
invoiced price is 0.
This commit fixes this problem.
NB: in real price and average price, the considered cost must be the purchase price
and not the cost defined in the product template.
opw:740879
Was removed at 173b76c7bb but was used in pos_blackbox_be (and maybe other
custom modules)
Restore the previous method that will call a read on the computed fields
Getting the recurrent event in an order that make
sense for this model.
`self` is mail.message model, so this order can cause
crashes, since calendar.event and mail.message have
many different fields.
opw-743265
amount_tax compute method uses `price * (1 - (discount or 0.0) / 100.0)`
_create_account_move_line method used `price * (100.0 - discount) / 100.0`
with price = 9.95 and discount = 0.1 it makes a difference
>>> 9.95 * 0.9
8.955
>>> 9.95 * 90.0 / 100.0
8.954999999999998
Cumulative errors makes a 1 cent difference between totals of the orders and
computed amounts.
The session could not be closed as debit != credit
opw-743188
When removing a move previously linked to a bank statement, the move_name value
must be removed too.
This field is set when reconciling the entries.
When move_name is set, it is not possible to delete the bank statement line,
even if the refered move no longer exists.
opw-741205
The context key `from_date` can be retrived from `self.env.context,
while the context key `to_date` can be defined for each procurement
group.
We extend the code so that `from_date` can also be defined for each
procurement group.
Closes#16803
opw-743013
Following bee3253b44, this commit is made
to increase the mail clients compatibility for the mails that are
created with the odoo mail editor.
Three new problems are handled:
- Font family of titles had to be forced too as outlook was not
inheriting parent font family on those either.
- Default text font-size had to be forced as was not detected in
transcoding correctly.
- text-decoration rule was decomposed in text-decoration(-line,
-style and -color) in transcoding. Outlook is ignoring those
three rules for some reason. As the decomposition is useless,
the transcoder now forces the recomposition of these three rules.
The '/point_of_sale/display' controller is added in the hw_screen module.
This module is not loaded if the init scripts are not modified.
This means that updating a posbox with the internal update feature will not work.
This adds the link only in hw_screen and display an information message for old
versions.
Fields translated with function such as `xml_translate` or
`html_translate` have translations such as:
lang=fr_FR, src="Tree", value="Arbre"
when the value directly stored in the table could be:
<strong>Tree</strong>
The code to copy translations when duplicating a record did not take
this into account and when not in english, would add previously not
existing translations such as:
lang=fr_FR, src="<strong>Tree</strong>", value="<strong>Arbre</strong>"
This is wrong since for example after a copy in french, what is in the
database is:
<strong>Arbre</strong>
This commit change this so that the translation in the database stay the
same:
lang=fr_FR, src="Tree", value="Arbre"
This translation will still not apply (if the base language is different
and a translation different than the source exists) but it is more
logical to have this.
This change also magnify an issue that was that if a translation was:
Tree -> Arbre
and the content `<strong>Arbre</strong>`. The translation doesn't happen
in one way, but does when doing the reverse translation.
So:
translation (Tree -> Arbre):
`<strong>Arbre</strong>` -> `<strong>Arbre</strong>` <= FAIL
reverse translation (Arbre -> Tree):
`<strong>Arbre</strong>` -> `<strong>Tree</strong>` <= WORKS
this broke the test that something reverse translation of a translation
got the original. But testing this if the translation did not work seems
to make little sense.
opw-740213
closes#16984
Before this commit, we compare in some case False != u''
Commit #56c798a fix u'' != False but in case of the partner has been
edited from front end, partner.vat will be u'' and not False
There was two main problems with the feature
- The author name was not properly fetched so the feature which was
supposed to add the author of the blog post in the tweet never
worked -> this commit simply deletes it
- The code was considering the url length in the size of the tweet,
so if the url was 135 characters long, it considered that only 5
characters have to be taken in the selected text... which is wrong
as twitter URL are all shortened to 23 characters by twitter
opw-741530
Nothing prevents the deletion on invoice line at the Python level. Other
modules might give access directly to the invoice lines, and make their
deletion possible when the invoice is not draft.
opw-743154
The license entry in the manifest files for these modules were
leftovers from previous versions.
Once integrated in Odoo Community they share the same license as all
other modules, as mentioned in the LICENSE notice at the top of the
files.
opw-743686
- Sell a product in the POS
- Go back in the backend
- Return the product
- Click on "Payment"
The user is allowed to select any journal. It should be restricted to
the payment method available in the POS.
opw-743585
Martin Trigaux