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
- Activate Sub-tasks in projects
- Create a sub-task
An `AccessError` is raised in `check_access_rule` of `mail.message`.
The context is 'polluted' with a `default_parent_id` key, which is not
necessary anymore at this point.
opw-1924899
closesodoo/odoo#31022
Let the database be in multi-company without a shared contact book.
Have user U in company B, OdooBot in company A.
From a record R created by U, have a message sent by OdooBot fail to be sent.
A new failure notification failure should be displayed for U in company B.
Have U switch from and to company B.
The failure notifications are fetched, with their info.
Commit 10d558ef2b made sure that the user had access to the record
before trying to display the notification.
However in that case U has access to R, but trying to access the mail sender
violates the inter-company record rule, since OdooBot is in another company (A).
opw 1928100
opw 1935303
opw 1939352
closesodoo/odoo#30364
- Set your company to USD
- Create an expense in EUR:
Amount: 100
Tax: 15% Excluded
- Validate, post the journal entries
It crashes because of a missing `.id`, but on top of that... not a
single AML is correct.
opw-1938570
closesodoo/odoo#30959
In multi-company, create a new company C.
Set the chart of account in settings, save.
You get an access right violation on account.reconcile.model.template
because you need account_user.
Since this group is supposedly dependent on another module,
a user is supposedly never in this group without that module.
Obviously, this should supposedly not happen.
opw 1938539
closesodoo/odoo#31003
On a view, define a timerange for fetching data
Save as favorite
Before this commit, the time range description were not transmitted as
strings for the creation of the filter
So, when loading the filter back, there was no description for column headers
resulting in displaying "Object [Object]" as their title
After this commit, we save in the context of the filter the description of the title
OPW 1930582
closesodoo/odoo#30992
When a bank statement reconciles its lines with payment using a foreign currency,
there is a mix up of values between the currency set in bank statement and payment against the company currency.
Current Behavior
Company Currency: MXN
Bank Statement Currency: USD
Payment Currency: USD
Current Rate 0.05130836
1) Generate a bank statement with 990 USD.
2) Generate a payment with 1000 USD.
3) Reconcile the bank statement against the payment.
The reconcile process generates a payment with the difference (10 USD)
Before this commit, this automatically created payment took an erroneous amount,
Taking a currency-converted amount where it should not have
It was happening because the reconcile process uses the debit or credit value(Local Currency)
against bank statement line amount (Foreign Currency).
After this commit, the amount set in the generated payment because of the difference is 10 USD.
closed odoo#30623
closesodoo/odoo#30779
- price_unit is wrong because Facturx only provide the price_total and then,
we need to divide this amount by the quantity.
- the partner detection using its name was buggy due to the 'elements' variable
that was overrided.
-opw: 1938648
closesodoo/odoo#30998
When the mail_service is started, if there are any running chat sessions,
Chat_windows are created and opened on the point_of_sale frontend.
They also appear in the printed receipt.
To remove them from display we create a new pos_assets_backend template,
which inherits the web.assets_backend and removes the odoobot related assets.
opw 1878185
If no journal is set for the POS, the session creation would crash.
We add raise an explicit error asking the user to configure either the payment
method or the chart of accounts.
opw 1878185
This commit fixes two untranslated terms in the activity view.
From the cohort view, when clicking on a cell to see details, the title was not
translated (missing _t call).
The content was not translated either as the language was not present in the
context.
36d45175b0 was a first step to fix it but while self.record contained data,
self.record.getContext() returns an empty dictionnary (no context is set in the
cohort view).
When computing the context, check that it is not empty, otherwise, fallback on
the session context.
opw-1936855
closesodoo/odoo#30942
journal items does not create Tax Cash Basis Journal Entries.
[IMP] Test Case for Fully reconciling multi-currency lines and one or
more are Exchange Rate Differences which are not creating Tax Cash
Basis Journal Entries if there were any Taxed line.
Main
-
Tax Cash Basis Journal Entry creation shall not be prompted by the
reconciliation of exchange rate difference journal items.
Explanation
-
Company's Currency EUR
Having issued an invoice at date Nov-21-2018 as:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Expenses 5,301.00 USD 106,841.65 0.00
Taxes 848.16 USD 17,094.66 0.00
Payables -6,149.16 USD 0.00 123,936.31
On Dec-20-2018 user issues an FX Journal Entry as:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Payables 0.00 USD 167.86 0.00
FX Gains 0.00 USD 0.00 167.86
On Same day user records a payment for:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Payables 6,149.16 USD 123,768.45 0.00
Bank -6,149.16 USD 0.00 123,768.45
And then reconciles the Payables Items which shall render only one Tax
Cash Basis Journal Entry because of the actual payment, i.e.
amount_currency != 0:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Tax Base Acc. 0.00 USD 106,841.65 0.00
Tax Base Acc. 0.00 USD 0.00 106,841.65
Creditable Taxes 848.16 USD 17,094.66 0.00
Taxes -848.16 USD 0.00 17,094.66
closesodoo/odoo#30130
Create a new vendor bill.
Choose a vendor with a "supplier currency" different from the company default.
The currency on the vendor bill does not change to the currency of the vendor,
unlike when a purchase order is created.
We set the currency in the partner_id onchange.
opw 1932683
closesodoo/odoo#30961
Try to access a recurring event.
The _search function defined in mail_message tries to read records,
building a list of ids.
They are given to the _search of calendar, which builds its custom SQL query
using the data it received.
Since it got recurring ids instead of real ones, we get:
SELECT id, ("calendar_event"."id" in (101,'101-2019011118000...
Bug introduced in f74f5edc77.
If we get such a request, we convert the virtual ids back to real ids.
Note that a similar conversion was done in calendar's override of "mail.message"
_search method, 'in the case it was asked on virtual ids'.
Note that as of this commit making messages on virtual_ids doesn't even work,
so it is possible that this mess was introduced for the chatter feature,
which has been broken before, and so all of it is useless.
closes#27474closes#28288closes#28621
opw 1928562
opw 1930763
opw 1935148
closesodoo/odoo#30827
When retrieving the BOM lines in `_get_bom_lines`, we check the product
attribute values to know if the BOM line should be taken into account or
not. However, we do not do such a check when we retrieve the price in
`_get_price`.
It can lead to an inconsistency between the sub-lines displayed and the
total price.
We need to apply the same filtering logic when getting the price.
opw-1932437
closesodoo/odoo#30917
Inspired by l10n_multilang
When a theme is installed, the theme.* records are used to generate actual records.
The same was as we use account.account.template to create account.account, the
translations of the theme records should be propagated to the new records.
opw-1918120
closesodoo/odoo#29748
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28900
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28895
Before this commit, when having a calendar notification, the buttons to snooze/cancel
This was because the API of the widget notification changed with 07cd24b1ec
The widget "text" has been changed to "message"
After this commit, the buttons are present and work
OPW 1923132
closesodoo/odoo#30946
In following configuration:
- We have two companies: A and B
- We have a shared product X
- We set a BOM of type KIT for this product X for company B only (the field company on a BOM is mandatory)
- We set no BOM for product X for company A because in company A we sell the product as a regular product
When we sell product X in company A, as a normal stockable product, the invoicing behavior is the same as
when we would sell KIT products. This is because we don't check the SO company when searching the associated
BOM.
closesodoo/odoo#30927
Commit bfb0f1e2a5
did a very good job not seeing that the lines only used move[0],
and called move.field directly.
This could result, for certain BoMs, in traceback.
opw 1928677
closesodoo/odoo#30938
Before this commit, the website menus were created only on write on an event
After this commit, the menus are created at create time too
OPW 1914343
closesodoo/odoo#30919
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28909
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28902
Nicolas Lempereur