Before this commit: links like `tel:+1-555-555-5555` were being replaced
both in javascript (prefixing `http`, when using the summernote editor)
and python (prefixing the base url, when they were added directly to the template).
After this commit: the replacement is avoided on links with `tel` scheme.
This is related to commit: 8b97a39
Have a model A with a o2m to B.
In the list have a field B > m2o > C
Also have a sequence field (widget handle) on B
Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty
Resequence those two B lines with the handle
Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get
After this commit, there is no traceback, the name_get is avoided when no data is to be fetched
OPW 1853088
closes#24988
Steps to reproduce:
- Enable multi currencies
- Make sure that the current rate of a foreign currency (i.e. $) is not 1.0 (i.e. 0.5)
- Create a purchasable product with a cost (i.e. 100€)
- Create a vendor bill in a foreign currency (i.e. $)
- Add the product on the invoice
Bug:
The unit price was equal to 25$ instead of 50$
Technical reason:
The function "_onchange_product_id" was called twice (the second time by function
"_onchange_uom_id") and the price unit was converted twice in the currency of the vendor bill.
The idea of this fix is to only convert in the currency when the unit price is set
by the system.
Fixes#24751
opw:1849212
To compute the week number, the fullcalendar.js library uses the locale.
It depends on the day on which the week starts (usually Sunday in the Americas,
Monday in Europe), as well as which week is considered the first of the year.
In commit:
https://github.com/odoo/odoo/commit/717b472ef9ad6d2998cbefb4aafe2d1199e6235d
the starting day was explicitly added, however it was computed as isoWeekday.
The ISO first day of the week is always on Monday.
It resulted that if the locale used Sunday as first day of the week, the
calendar would consider it to be of the previous week, and thus displayed
(weeknumber - 1).
The fix does the same thing as was done in v10, taking the locale into account:
https://github.com/odoo/odoo/commit/df124080b624a8bdb86fec352fe690725ed36bac
opw 1853745
The new route make_event_ics_file received a list of attendee ids and was sending
the emails associated with these in an ics file, this could potentially
give out some information about the attendees.
(see commit 7862b2b71c)
Also the method get_ics_file had no reason to be public and so is now
private.
Closes#24711
Let's consider a Sales user U with no access to Purhcase
Steps to reproduce the bug:
- Create a SO with one line with the drop shipping route
- Validate the SO
Bug:
A access error was raised because the user has no access right on
Purchase.
opw:1851301
Before this commit:
* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other
If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.
This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.
To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.
Fixes#24958
When archiving a product template P with one SO linked to it,
- Going to P by Accounting > Configuration > Products > P shows 1 sale
in smart button
- Going to P by Accounting > Sellable products > P showed 0 sale in smart
button
Now it shows 1 sale in these two cases.
opw:1852948
Make one Payment
Reverse the entry of this payment.
Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports
After this commit, the four lines are reconciled two by two, even in the liquidity
account
OPW 1816641
closes#25026
- Create a picking, set as 'Carrier': 'Free delivery charges'
- Enter a 'Tracking Reference'
- Validate the picking
The tracking reference is removed.
opw-1849279
If the `web.base.url` contains a trailing `/`, the replacement of the
`/unsubscribe_from_list` link won't work since the string to replace
will be `my_url//unsubscribe_from_list` instead of
`my_url/unsubscribe_from_list`.
Fixes#24731
opw-1848572
When a line in a editable tree view has no acivable element
(readonly or toggle_bollean fields only) the currentFieldIndex
will be null after selecting the row, and when trying to edit a
field (boolean field_toggle in this example) an error will be
thrown when trying to put focus on currentWidget.
We need to check that the currentWidget is not undefined.
In the portal module,
the `index` method from the `web` module controllers
is overriden to redirect `/`
to the portal `/my` for the portal users,
instead of the regular backend `/web`.
However, when `website` is installed,
this behavior should not happen,
as you would like the signed in portal users to
be able to see the website homepage,
and not to be redirected to `my` when
they try to access `/` root path of the website.
Because the override in the website module was done on the
`index` method coming from the `web` module instead of the `portal`,
according in which way the Python module were loaded,
it sometimes redirected to `/my`, sometimes it correctly
displayed the homepage. This is because the modules are not
loaded in a determinist order.
To summarize, on runbot, if you logged as portal/portal,
one time on two you were redirected to `/my`, and the other
time you saw the homepage correctly.
As `website` depends on `portal`,
we have the possibility to override the `index` method
of `portal` instead of the one of `web`,
to force the determinist order,
and therefore the determinist behavior of the homepage for
portal users.
When installing the `account` module, some of its master data is
installed as `l10n_generic_coa` data.
During the uninstallation of `account`, `l10n_generic_coa` is
uninstalled first since its a dependency of `account`, but some of its
master data cannot be uninstalled yet as its still being referenced in
some `account` et al tables.
When `account` is being reinstalled, the datas will be updated instead
of created since they were left intact in the database, this proves
troublesome as the code YAML interpreter adds some context variables
when creating records but not when updating records, these context
variables are necessary in order to trigger some onchanges and defaults
for fields that are required, since this does not happen we get a `NOT
NULL CONSTRAINT` error when re-installing the `account` module.
This patch solves this issue by adding an uninstall_hook that will
delete all ir_model_data that belongs to the module `l10n_generic_coa`
upon its uninstallation.
Fixes#25005
- Create the following BOM for Product A:
Comp 1: 1 Unit(s)
Comp 2: 5 Unit(s)
- Update on-hand quantity:
Comp 1: 10 Unit(s)
Comp 2: 30 Unit(s)
- Create a MO for 10 Unit(s) of A
- Check the Quantity on report 'Stock Level Forecast':
Comp 1: 0 Unit(s)
Comp 2: -20 Unit(s)
- 'Check Availability' on the MO
- Check the Quantity on report 'Stock Level Forecast':
Comp 1: 0 Unit(s)
Comp 2: 30 Unit(s)
The `partially_available` state has been added with Inventory
refactoring in v11, and needs to be taken into account.
opw-1849556
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
10.0 version of 9.0's #24966
opw-1851622
closes#24991
Before this commit, some values of res.config.settings were saved
(e.g case of website settings were some fields are related)
After this commit, they are not saved
OPW 1853230
closes#24972closes#25028
- Create a BOM for Product A, using Component B
1 Unit of a is built with 1 Unit of B
- Update on hand quantity for B to 3.0
- Create a MO for 5 Units of A
- Update the quantity to produce to 3.0
The button 'Check Availability' never disappears.
The core of the problem is that the move remains "Partially Available".
Indeed, if there is no product available (`available_quantity <= 0`),
the stock move is skipped and its availability status is not updated.
We slightly change the logic by first checking if we need any quantity.
If not, the move can be considered as assigned.
opw-1850499
The website_event_questions override EventRegistrationForm's method
on_click and expects the returns is a deferred.
This commit provides a deferred in all instances avoiding an error.
Also what was done in e9454e79 and enables back the Register Now
button if no ticket was selected.
opw-1850527
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
Also if website_event_questions was installed there was an error
preventing an error message to be displayed.
saas-15 version of 9.0's #24966
opw-1851622
closes#24967
These commit allows users to create sales order, and invoice
from the project overview. To do, the overview is now refreshed
when naviguating throught the breadcrumb, and supports action
buttons on its control panel.
Also, some stat buttons are added on the overview (sales order
and invoices).
The process of invoice creation is the same wizard than the one
from the sale order.
Thoses actions are only available when there is no ambiguity
to determine the SO from the project, or for non billable project
(to create the SO).
Task #49213Closes#24280
On sales order form view, we display a "project overview"
stat button. It redirects to the overview of the only
billable project of the SO.
To avoid access error, and because this dahsboard is usefull
only for project manager, only those ones will have access to
this overview. So, stat button (Sales order) and label on
project kanban are aonly visible for manager.
Now that the overview is refreshed when it is displayed and that we
can create SO/INV from it, it is usefull for the users to have
a stat button displaying those new documents directly from
the overview.
This commit use the already existing mecanism to display
Sales Order and Invoices stata buttons.
Thoses 2 stat buttons are only visible for salesperson seeing
all document, to avoid access errors.
Task #49213
We want to invoice from the project overview. To do so,
a button can help people: it is only visible when an order
linked to task in that project has something to invoice
Any sale order line, even the ones with no service product
will be invoiced.
However, the user will have to choose which SO (involved in
the project) to invoice. Then the "invoice order" wizard
takes over.
This commit makes the project overview handle action
button in its control panel. When calling server to get
overview HTML code, we also get a list of actions to display
in the control panel. Those are rendered client side.
Since when an action is done, we usually don't want the button
to be display anymore, reloading the overview is required.
The overview is now refreshed when navigating with the breadcrumb,
so each time the overview is displayed, an RPC call to the server
is done (`do_show` method override).
Task #49213
This commit provides a wizard to create a SO from
a non billable project. It sets sale_line_id on the
project, and the project on the SO line to simulate
the project was created by the SOL.
The created SO contains one line with a selected
service product, with ordered qty set as the total
of planned hours of all task in projects.
The wizard also links all non billable active
tasks of the project to the SO line (and its
timesheet entries).
The context was containing a dictionary under the key `install_mode_data`,
which was informing about the model, xml_id, module, filename. Actually only
the module and filename were necessary, and the others were slowing down the
import because of generating artificially different environments.
The context now has two entries `install_module` and `install_filename`.
Tomas Alvarez