To edit a view on the website, we use the branding mechanism.
This mechanism adds informations to node which can be edited about how
or where the change should be saved, for example:
```
<template id="a">
<div><b>hello</b></div>
</template>
```
might be rendered to someone that can edit it:
`<div data-oe-model="ir.ui.view" data-oe-id="5" data-oe-field="arch"
data-oe-xpath="/div[1]"><b>hello</b></div>`
when something is changed: we will send the modified content, the view
id (eg. 5 for view `a`) and the xpath in this view of what is replaced.
If a view is overridden, there is mechanism to distribute the branding
to children, for example:
```
<template id="b">
<div>
<b>hello</b>
<div>
</template>
<template inherit_id="b">
<div position="inside">
<b>world</b>
</div>
</template>
```
The branding can't be on the parent div that will contain other content,
because the other content is in another template and should not be saved
in template `b`, so this would be rendered like this:
`<div><b data-oe-model="ir.ui.view" data-oe-id="6" data-oe-field="arch"
data-oe-xpath="/div[1]/b[1]">hello</b><b data-oe-model="ir.ui.view"
data-oe-id="7" data-oe-field="arch" data-oe-xpath="/div[1]/b[1]"><b>
world</b></div>`
This changeset fixes two issues:
- if we have a primary inheriting view: the xpath are wrong in the
primary inheriting view part, they are computed on the view applied on
its inherit_id; the part of the inherit_id view have the primary
inheriting view ID instead of inherit_id view id.
- if we have `<div t-call="..."/>` in a view, the branding of view
should be distributed to children and not affect t-call part: this was
done for `<t t-call="..."/>` but not for `<anyothertag t-call/>`.
The added test failed on all assertions before the change:
- "test_branding_primary_inherit" would not distributed
- "test_call_no_branding" would distribute branding on `t-call`
opw-1937757
closes#31039
The Actions/Print dropdowns may overflow the screen in case of very long
lists of menu entries, when based solely on the default BS4 styles for
`dropdown-menu`.
The `o_dropdown_menu` class forces a vertical limit and a scrollbar when
this happens, and should be applied to those control-panel dropdowns to
prevent this UI glitch.
See also 1c1c0897e8 which adapted
dropdowns to BS4.
closesodoo/odoo#31251
The `company` context is explicitly set by `action_send` while the
template previewer doesn't set it. This inconsistency leads to
error when previewing the digest template.
opw-1939007
closesodoo/odoo#31195
When duplicating a project, every task linked to the project is
duplicated too but the link between sub-tasks and their parent
task is not updated thus they are left linked to the task of
the original project.
opw-1937371
closesodoo/odoo#31154
When duplicating a journal, the alias is kept. Therefore, when the user
tries to change it, it updates the value on both records.
opw-1941717
closesodoo/odoo#31242
If the stage breadcrumb on the portal view is too long, it could get on
two lines but since they are righ-aligned in inversed order, the second
line (or more) will be the first stages.
With this fix, the breadcrumbs are left-aligned so on two line the
second line are the last breadcrumbs.
Also there was possibly a different order than backend since the order
is on "sequence, name, id" in backend but was just "sequence" here.
opw-1934497
closes#31237
- For 'res.config.setting' view, when there is a field with
'many2many_tags' widget, a drop-down is not displayed
properly. (For example, see 'default_cashbox_lines_ids'
field from point_of_sale module)
- This commit fixes the above visual glitch by properly displaying
the field having 'many2many_tags' widget on settings view.
Task id - 1935608
closesodoo/odoo#30956
The date picker should be displayed when clicking on the fa-calendar
when creating a note from activity systray.
The test was missing the assertion checking that the date picker was displayed,
but fixing this issue breaks the test. The datepicker looks to be
asynchronously initialized, and the blur event raises an error because of
that. Since it is difficult to test external libs behaviour, this
step is simply removed from the test.
Task: 1942850
closesodoo/odoo#31241
This fix prevents the chatter and attachment box
from assuming that there is a mail_thread on the record;
Reason: if a chatter is set on a record that doesn't inherit
mail_thread, the attachment box will generate errors.
closesodoo/odoo#31206
With Italian localization, the length of zip must be 5 for Italian buyer.
If the buyer is not Italian, we doesn't check his zip length.
closesodoo/odoo#31205
Some elements in the eCommerce are styled using the 'border_primary'
class. The color used by the class is however the wrong one, as it was
set to the odoo purple while it was meant to be the theme primary color.
This commit fixes the color.
Note that BS4 has an equivalent for that class (.border.border-primary)
but as this is a stable fix, it was not changed. It will be adapted in
master with https://github.com/odoo/odoo/pull/31147closesodoo/odoo#31214
- Set a barcode for a product A
- Open the POS interface
- Click on a product B => it is added to the order
- Scan product A
Product A is added to the order, but a unit of B is also added.
Commit 9de1bc0eef introduced keyboard shortcuts in the POS
interface. In particular, when a product is selected, pressing the SPACE
or the ENTER key adds it in the order. Since the barcode scanner sends
an ENTER key as a final character, it triggers the addition of both
products.
opw-1934520
closesodoo/odoo#31185
- Have a slow network
- Click multiple times on the 'Check-in' button
Multiple attendances are created.
The view refactoring introduced in 9de1bc0eef changed the
element to a `<a>` tag, on which the `disabled` attribute has no effect.
We introduce a `debounce` instead.
opw-1941647
closesodoo/odoo#31178
When the Payroll precision is higher than the currency precision,
accounting entries are inconsistent: debit or credit fields use the
payroll precision, while the balance uses the currency precision.
We make the AML consistent by forcing the currency precision.
opw-1924360
closesodoo/odoo#31131
Now that we have proper support for RTL language, add an Arabic language with
code "ar" (while the only possiblity before was ar_SY).
Use ar_AA code as Arabic unitag.
In master, the ar_SY could be removed as no need to have both.
Add Bengali language
Fixesodoo/odoo#31165closesodoo/odoo#28640
If that storage is destroy-able (aka RamStorage), storage objects are
created "inline" without attachment (as they may or may not be parented)
and this means those created implicitly in tests can't be tracked and
cleanly destroyed even by destroying the storage service object.
closesodoo/odoo#30790
In a multi-company environment, the creation of a purchase requisition
fails in a company with ID != 1 because of an empty name.
This is because the sequence is created for the company with ID = 1
only.
opw-1941552
closesodoo/odoo#31153
When there are lots of lines to be considered, the rpc can come in the wrong order, causing the client to not display the wanted lines. By asking the user to hit enter or leave the input field, we reduce the number of requests and we get rid of the concurency of rpc
closesodoo/odoo#30280
The formatting of very big numbers (like
1.0045e+22) was not handled adequately by
the function 'human_number' in web.utils.
For those numbers, it seems more appropriate
to use the scientific format. The only
difference introduced here is the following.
Beyond a magnitude of e+21, we represent the
numbers by themselves but we keep the
number of decimals provided as parameter
(or zero by default) and we remove useless
zero decimals like in the other cases.
For instance, 1.0045e+22 is replaced by 1e+22
instead of 1.00e+22 if ask 2 decimals of
precision (and by 1.005e+22 for 3 decimals).
We have also fixed a small bug occuring in the
previous version of the function: the symbol
'E' was never used. So by the past the above
number would have be represented as
10045000P and, even worse, 1.01e+45 by
1.012e+28P.
closesodoo/odoo#31140
On a product page on the website, with website_sale_stock there may be
an information about the product being out of stock or not.
This information is loaded on the fly for the current variant (switching
variant will reload it) and so this should not be modified with the
editor because:
- the saved edition would appear on all product (even if those in stock)
- the saved edition is replace quickly with the real state
So if we want to change the content, there is no other way than a custom
change on JS template website_sale_stock.product_availability or
modifying translations.
opw-1936179
closes#31135
* Form would entirely mis-interpret the server's response to some
results: for unmodified o2m records the server sends a (4), which was
un-interpreted by Form, leading to the o2m record being lost entirely
(as it rebuilds the entire o2m on setting)
* on record creation, every field (except id) is considered modified not
just the fields set by default_get
* Form diverged from actual client in that it would send (1, id, {}) for
unmodified o2m records, actual client sends (4, id, False)
* datetimes should be sent stringified
* onchange should not be triggered when none of the modified fields is
flagged as an onchange trigger
* the default value for numerical fields is 0 not False
* convert m2m onchange results to (6, False, ids) instead of (6, 0, ids)
for ease of diffing with actual client's data
There are still a few odd divergences in the actual invocation of
onchange when attempted on an SO, but they look to be of low relevance
/ risk.
Note: making integer fields "required" has pretty much no effect
anymore. This is in line with (my understanding of) the client's
behaviour, but required the alteration of test models as the
specific test on required... was using an integer field.
closesodoo/odoo#31064
The commit 6d3ada1
aimed to solve problems occuring whith (single or
double) quotes when creating new custom filters.
Unfortunately, the point was missed and bugs were
still present. The present commit solves the
orginial problem satisfactorily.
There was also a problem in the management of
backslashes. Type '\\' in the search bar would
lead to a domain like
[('...', 'ilike', '\\\\\\\\\\\\\\\\')].
This has also been fixed. Note that it is
necessary to input "\\" if one is looking for a
backslash in db (as before).
A remark on the _formatAST function (py_utils.js):
We deescape only the chars `'`, `"`, and `\`
because it does not seem possible to produce a
string in the search view that would intend a
search for a line return or a tab for example.
A general remark:
Domains should always be in normalized form.
In that way they could be manipulated and combined
together without a tokenization/parsing!
closesodoo/odoo#31025
1) Configure both an incoming mail server and an outgoing one.
2) Install CRM.
3) Create a sale team, use the incoming mail address as mail alias.
4) Add a user with a valid email as follower of that team in the
chatter.
5) Enable developer mode, become super user via the developer tools.
6) Change the language of the super user to french.
7) You may want to modify the default gather/post time interval.
to receive/post email more regulary in the scheduled action.
8) Using an external mail client, send a mail to the incoming mail
address.
9) Let the two scheduled actions run by themselves.
10) The mail sent to the user has the "Lead/Opportunity" in english
wheras the rest of the email is in french.
opw-1917993
closesodoo/odoo#31034
This is a fixup of:
- original commit: 0d48056d63
Fixed the execution of no-chart tests in sale_timesheet standalone
i.e. launching odoo with `-i sale_timesheet --test-enable`
- commit 6eed6a503b omitted those fixes
This commit put them in the parent class, since it is always useful to have
sale journals
OPW 1939361
closesodoo/odoo#31119
- Set a blocking message on a product
- Buy this product from the eCommerce
A 500 error is raised.
The underlying error is a SQL constrain raised because the `name` field
of the SO line is empty.
It happens because the warning is returned too early.
opw-1934386
closesodoo/odoo#31120
Using chrome, the design was not pixel perfect (letting a white bar
appear around the switch). Replacing the linear gradient color by a
simple color fixes that particular problem. The design is still not
pixel perfect but those are meant to be replaced in master anyway.
Part of https://github.com/odoo/odoo/pull/31117
task-1941156
* web_editor
BS conflicts with our UI again: btn sizes and form controls are
more difficult to force with BS4, this commit adapts the controls to
use less problematic sizes, and adds/adapts some more forcing rules.
Part of https://github.com/odoo/odoo/pull/31117
task-1941156
The graph view displaying a line chart has had some recent changes in
b23a981320. Now it is of the full width of container but when there is
less than 4 labels (thanks to c4937132a3) the first and last labels may
be cut because they are by default aligned on the middle with its tick
(so for the first label, the half left may be missing, and the last the
half right may be missing).
With this change, we align labels as expected. This could be done in CSS
sheet (with `.nv-axisMin-x > text { text-transform: start!important; }`)
but here it is done only in the given instance.
opw-1917560
closes#31116
Commit ec35eca7c6 added the tracking on CRM description field.
However the description field changes frequently, making the tracking generate
too much (noise) messages.
Furthermore, the description field tends to be very long, cluttering the chatter
to the point of unusability.
opw 1936070
closesodoo/odoo#31112
There is an onchange on payments that, when the currency is modified,
sets the journal to the first available one whose currency matches the
selected one. However, if a journal is already set, its value is
overwritten, even if its currency matches the new one.
To replicate:
- Create two banks in EUR
- Create an internal transfer from the second bank
- Set the payment currency to EUR
When you follow the above steps, the payment journal will be incorrectly
set to the first bank.
Other possible ways to replicate the issue are:
- When editing a payment already created whose journal is correct but
whose currency is not
- When creating a payment and the journal is set before the currency
This commit fixes that issue by preventing the onchange from modifying
the journal, when it's already set.
Closesodoo/odoo#30967closesodoo/odoo#30969
Since AST was introduced to compile Qweb templates, the reset templates
functionality is not working anymore.
Actually, it does not even appear anymore as the conditions to trigger and show
the reset view behavior can't be True anymore.
Indeed, the code is still importing the old QWebException from odoo.exceptions
which is now just an empty class.
The QWebException that should now be used is the one from odoo.base.models.qweb
More than just a wrong import, the QWebException properties have completely
changed.
Since its last working version (Odoo 9.0), a lot of changes occured, mostly:
- Odoo 11.0: new model website.page, which completely changed the pages
behavior and changed the models.
- Odoo 12.0: multi-website, which introduced the Copy On Write (COW) that
redefined how we write on view in a website context. We now need to reset
copied/specific views that have no model_data_id.
This fix is for a stable version. There is some flows that can't be fixed
without a refactoring or new fields (mainly because of the arch_fs being
erased when writing on `arch`, plus we can't introduce a module reload in
stable).
The goal of this commit is to fix the basic and standard case of broken views,
which is when non-technical users are breaking the views through HTML editor.
To reset the views, we will read the original arch in the XML file, as the
dev mode is doing.
To be eligible for the reset, the broken view need an `arch_fs` set. If the
view arch has been modified anywhere else than the frontend, the `arch_fs`
will be erased and the view wont be able to be reset.
As the broken views will be specific views, we will simply read the generic
view in the XML file and write it on the specific. We can't simply remove the
specific view as we might be on a specific tree.
Specific case, in case of custom views create dropping a snippet in an oe_struc
we just delete this inehrited view to allow end user to have their page back.
In some case of bad compilation in sub template, we try to guess which inherited
view, t-called view is broken by string matching based on 'last_path_node' xpath.
Add new module test_website to add tests, it will be usefull for futur test of
install/uninstall and ...
Todo in master:
- try to track on QWebException the real template that is broken and not only
the last node from the main template.
Co-authored-by: "Romain Derie <rde@odoo.com>"
Co-authored-by: "Jérémy Kersten <jke@openerp.com>"
closesodoo/odoo#29957
Once `website` module is installed, the `save` method will always write on the
specific view or create it if it does not exist yet.
This means that actually, the generic view will never have his `arch` modified
through the `save` method.
Thus, there is no need to flag it as noupdate as we want to receive update for
that view (that might be used by other website without a specific view).
The access token is automatically generated when calling `_get_share_url` but
for the cart recovery we don't use that standard method because we need to send
the user to a specific route, so we need to generate the access token manually.
Without this fix, the user will receive the link with access_token=False which
would lead to a 404 page.
Also added a test for the cart recovery flow.
PR: #30000
Before this commit, the website selection was not working when a scheme or port
was encoded in the domain field. This was not obvious or natural for the user,
because the easiest way to fill it was to copy/paste the URL from the browser.
Now it works when scheme or port are encoded, it is even strongly recommended to
actually encode them if they don't take a default value because they will be
used when creating full URL to the website (typically when sending emails to
clients where a link back is necessary).
PR: #30000
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
The sale.order.line model has a 'display_type' field since 762adedece
that specify if the line is a dummy line used for presentation purposes.
These dummy lines are 'section' lines or 'note' lines.
If it is the case, the line does not have a product_id.
The sale_margin module overrides the create method of lines to add the margin
computation, assuming there are no dummy lines since that part of the code
is older than the new feature.
As a result the line creation would crash on a key error on dummy lines.
We now skip the margin computation if the line has a display_type.
opw 1939881
closesodoo/odoo#31035
- Generate e-invoice in xml when validating invoice
- e-invoice is sent via PEC mail and attached to the invoice
- electronic vendor bills and error/receipt messages can
be received through an IMAP incoming pec server
(configured in settings > technical)
We use the pec mail system to send invoices. We don't manage
signed invoices for B2G.
Configuration is done on the company and the receiving partners
should have the correct codice fiscale / TVA. On the taxes,
you might need to configure the exonerations.
You will need to configure the government mail address on the
company. (sdi01...) You might need to modify after the first
incoming message.
closesodoo/odoo#30845
- Set a product barcode to a 8 letters value, e.g. 'AAAAAAAA'
- Print 'Product Barcode (PDF)' (or any other report containing the
barcode)
The barcode doesn't print.
All templates assume that:
- a 13 characters barcode is EAN13
- a 8 characters barcode is EAN8
But this assumption is too restrictive: one could want to generate
barcodes with such length without following the EAN13 or EAN8 structure.
We fall back on Code128 when the barcode generation fails.
opw-1937858
closesodoo/odoo#30912
Nicolas Lempereur