It could happen in some cases that a rpc coming from a view was not made
with the context of the view (and from the action). For example,
- enable "Lots & Serial Numbers" in the inventory settings
- create a stockable product tracked by lot
- go to the inventory dashboard, on the "receipts" card click on the
three dots and then on "planned transfer"
this link forces the context key "planned_transfer" in the action
https://github.com/odoo/odoo/blob/11.0/addons/stock/views/stock_picking_views.xml#L725
- now add a stock move to move some quantity of the product you just
created
- see that no button appears on the one2many list
- save
- see that a button appears on the one2many list
This is an issue because the read on the o2m at the end is made with the
wrong context. The reason is that when we fetch x2m, we create a new
datapoint of type 'list' which did not reuse the context of its parent.
When we have two moves of the same product and procurement method
different on both, we don't want to merge them, because if a mto and a
mts move are merged together, it is possible to wait for an incoming
that will nerver come as a part the merged move should be taken from
stock
Purpose
=======
Utm links are really useful for website owners but this feature is hidden in Odoo apps. There is nothing pointing to that.
Specification
=============
- Add new module to generate utm pie chart in website_sale dashboard to track website utm link
- Add new option in website settings to install "website_links"
Title: Link Tracker
Subtitle: Track clicks on UTM links
Tooltip: Analyze the efficiency of your marketing campaigns by using trackable UTM trackers (campaigns, medium, sources). Create trackers and follow clicks from the Promote menu of your website. Those trackers can be used in Google Analytics or in Odoo reports where you can see the opportunities and sales revenues generated thanks to your links.
- Add utm chart to dashboard, using nvd3 such pie chart should be easy to implement
- If no data to display > Display a default picture with "There isn't any UTM tag detected in orders".
- Set a real icon to app "utm" since it shows up in homepage debug mode
Use case to reproduce
- Set a product to be expensed
- set the expense_policy to something else than no
- Do a delivery order with a picking
- Validate the picking
-> Delivered quantity to 0 and impossible to create an invoice
if the invoice_policy is delivered_quantity
It happens due to this commit 48ea59d46e
What does it do:
- The move could be generated by an expense.
- If the move has 'no' as expense policy thus we won't add it in the invoice
Problem we can't guess if the move come from an expense or not (limitation).
This commit increments the delivered quanity if the product can
not be expense anymore
opw-777139
The 'new views' refactoring introduced the usage of the "disabled"
attribute in addition to the associated bootstrap class. As a
side-effect, tooltips are never rendered when the mouse is on a disabled
button, since disabled elements do not fire mouse events.
In particular, no tooltip is shown when hovering over a disabled button
of the statusbar in debug mode. This can be observed when opening the
form view of a Manufacturing Order.
We fix this issue by requiring that disabled buttons in a status bar
never be the target of mouse events, triggering them on their
respective parent elements instead.
Before this commit, creating a base_action_rule with model X from module
A and then uninstalling module A would make the database crash because
the algorithm would look for an uninstalled model during the Registry
reinitialization.
i.e. Install project and base_action_rule, create a base_action_rule
depending on model project.task, try to uninstall Project -> BOOM!
This is fixed by checking if the model obtained is None, in which case
we log a warning (for cleanup) and skip to the next iteration (continue)
opw-777301
The image of the form view is set to be `image_medium`. However, the
method `image_resize_images` which is called during create or write
won't resize the image provided.
Therefore, the `image_medium` is not resized, leadnig to potential
issues if the user uploaded very large images.
We change the view to `image`, so that all images are properly resized.
opw-776943
When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
PURPOSE
=======
Provide import templates to ease the import process
Specification
=============
SPECIFICATION
==============
1/ Add specific templates to import screens: e.g. for product.template, res.partner and bank statements
2/ Replace import files suggested in planners (sales & website) by those ones.
3/ Add import template to bank statement import wizard for CSV, OFX, QIF and CODA files
Fixed issues
* Tasks link redirecting to a Task reporting view not allowed
to project user; link is not available only for project
managers;
* Whole : trigerring the menu that should be displayed only
for project managers as it is displayed empty otherwise;
This commit is XMO approved.
In 9.0 and 10.0 if anglosaxon accounting is active, creating a vendor
bill should generate the following entry :
Debit:Stock Input
Credit:Payable
But due to this fix: e9d6dcf16f
Debit:Expense
Credit:Payable
This reverts commit e9d6dcf16f to keep the same behavior in 11.0.
opw:777837
Suppose a bank statement of 11$ and a tax 10% price_included.
The result shown by the reconciliation widget is
D | C
11 |
| 10
| 1
that is correct. However, after clicking on validate, the result is
D | C
10 |
| 9.09
| 0.91
because the taxes are recomputed python-side and the values of the account.move.line are
amount = 10, tax_id = 10% incl. Then, the tax is recomputed on 10 instead of 11$.
-opw: 776644
5afb5ecd04 rewrote the tax computation
in both account and point_of_sale to fix complex tax computations but
it no longer allowed negative prices in the point of sale.
opw-778013
For instance, open a list view with enough records so that there is
a scrollbar, scroll, open a record of the bottom of the list and go
back using the breadcrumbs: the scroll position should be restored.
Before this rev., it wasn't the case: the scroll position was reset
to the top of the list (i.e. to 0).
This was due to the form renderer which manually triggered the event
DOM_updated on the main bus to ensure that textareas were correctly
autoresized. However, this wasn't done at the right place, and it
impacted the way scroll positions of views were saved/restored.
Indeed, this was only necessary when switching from readonly to edit
mode, i.e. when the form view was actually already in the DOM, but
not at each rendering as they may be performed outside the DOM (and
in this case, the DOM_updated event is triggered by the view_manager
when the view is really appended to the DOM).
Note that this whole scroll mechanism relying on the DOM_updated
event will probably change soon in master, with the refactoring of
the upper part of the webclient.
Set the round_globally method on the company.
Have an invoice with several lines and some of them having two (or more) taxes.
See the OPW 775501 for exact numbers.
It is a practical example case where
round(0.003 + 0.004) = 0.007 ~ 0.01
BUT
round(0.003) + round(0.004) ~ 0.00 + 0.00 = 0.00
Before this commit there could be a difference between amount_residual and amount_total on invoices.
This was because the two amounts are based on something different:
AMOUNT RESIDUAL
It computed in function of account_move_lines of the invoice.
For such an invoice the structure of those lines would be 1 line per tax + 1 line in the receivable account
Here the amount tax of each line is rounded before the addition.
In summary, the total amount of each tax are rounded and then added to each other
AMOUNT TOTAL
It is computed in function of the on-the-fly computation of the taxes with two cases:
- round per line: obviously each invoice_line gets its taxes rounded before addition, which isn't problematic as regards to the previous paragraph
- round globally: Here lied the problem. the rounding of the tax_line_ids was made **after** each tax amount was added to each other, which contradicts the above argument
After this commit, we round tax_line_ids before their addition, it is rather logical and matches the expectation one can have reading the tooltip of the rounding method field
>> If you select 'Round per Line' : for each tax, the tax amount will first be computed and rounded for each PO/SO/invoice line and then these rounded amounts will be summed, leading to the total amount for that tax.
If you select 'Round Globally': for *****each tax*****, the tax amount will be computed for each PO/SO/invoice line, then these amounts will be summed and eventually ***this total tax amount*** will be rounded <<
OPW 775501
After this commit, it is expected that the behavior of sale.order and purchase.order won't be the same as the invoice in the same conditions.
See PR #20349 for an explanation
Before this commit, switching chart of accounts (namely from SKR03 to SKR04 in german accounting), "old" values of the res_config_settings were kept, including default taxes.
These default taxes being inexistent in the target chart of account, the installation crashed.
After this commit, the installation succeeds as the wizard responsible for the installation is updated
OPW 777217
closes#20323
This commit is related to enterprise commit adding crm_track option to routes.
Before this commit:
We could not get template's name after dispatch() had been called. Indeed,
it will remove the template name from the response (response.flatten()) to
make it not considered as 'qweb' anymore (is_qweb()).
In some case (e.g. website_crm_score), we still need the template's name later.
(Eg: to retrieve the route's view being rendered and check if trackable or not)
Add view-id in template, when main_object is not an ir_ui_view, it avoid to
make extra rpc to get the view_id.
this commit closes#20313
Purpose
=======
Mailing lists are not flexible. It should be possible to merge mailing lists and remove duplicates when doing it.
Specification
=============
- When selecting records, in the action menu, add "Merge selected mailing lists"
- A modal will open :
- There's the choice between merging the contacts into a new mailing list or an existing one
- There's the choice to archive the source mailing lists or not
- The duplicates are avoided in the destination mailing list
- Opt-out contacts are not copied in the destination list
issue: When reorder each line trigger an onchange on the line (if they are an
onchange linked to the field) and one onchange per line on the parent.
Adding an option doNotNotifyChange to avoid the trigger on the parent.
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
The button "Pay Now" is clickable by default. So each time a new delivery carrier is selected,
the button "Pay Now" will be cickable when the delivery carrier is updated.
Before the fix, the button "Pay now" was available even the checkbox "Policies and conditions"
were not checked because the deleted code was applied after the one checking the policies and conditions.
opw:771418
Géry Debongnie