It is not possible to import Google Drive slides which are not publicly
shared.
Google Drive requires an access authorization from the user, not a
simple API key. The access token is generated in module `google_drive`,
but the latter is not in the dependencies of `website_slides`.
opw-703750
Before this commit, the field selector had an unique option to filter
the fields it displays: filters.searchable, which tells the widget to
only display the searchable fields (which is the default). Now there
are two more options:
- fields: an explicit list of the fields to use (if null, let the
widget get the fields itself (this is the default))
- followRelations: a boolean which is true if the user can follow
relation to build a field chain (default to true)
These options are needed by Web Studio in enterprise where domain
construction for form view attrs can only use fields which are in the
view and do not follow relations.
The "ModelFieldSelector" widget has a "filters" option which can
customize the fields which are displayed.
The "DomainSelector" widget has of course the same option it can
transmit to its internal "ModelFieldSelector" instance... but it
was documented as "fs_filters" instead of "filters".
Also, let the "ModelFieldSelector" document its own options and
sets their defaults (instead of the "DomainSelector" widget).
Proxy.load is required by the livechat when it is embedded in an
external page, so that it is able to get the static xml files
(with the correct base_url).
opw-706497
The JS module 'web.session' is already defined directly in the template.
When two modules have the same name, the second one that is read is
ignored, and a error is displayed in the console (in debug mode).
The original issue is the following:
- Configure the warehouse in Pick + Ship
- Activate the packs
- Create a SO with a product which is a consumable
- In the picking from stock to out, add the product in a package, and
validate.
- In the picking from out to customer, the previously created package is
not accessible/propagated as it would be with a stockable product.
The core of the issue is that there are no quants reserved for a move
linked to a consumable product. Since the package information is stored
on the quant, the package cannot be propagated correctly.
The fix is therefore to add the quants reservation feature on consumable
products, but only if the move is propagated from another one (i.e. the
move has ancestors).
That solved our issue, but also makes the workflow more logical. Without
the fix, all pickings are "Available" when created, even though one is
linked to another.
opw-702632
1. Activate the variant option on sale settings
2. Create a product and set invoicing on delivered qty and make it a
stockable product
3. Create 2 attributes, like color red and color blue
4. Odoo creates 2 variants
5. Make a BoM on the product with color red (So on Bom select the
product template and the product variant)
6. Set the Bom as "Ship this product as a set of components (kit)"
7. Now create a sale order with sale order line for the product variant
BLUE
8. Delivery order is created, deliver the whole delivery order
9. Go back to sale order and see that delivered qty is not updated and
thus we can not invoice the lines
opw-706423
The 'Start here to discover Odoo' is a data to help users to use Odoo.
Once they have understood, user often delete it but it comes back after an
update. The only way was to archive a record.
Using forcecreate is another way to avoid recreating it after an update.
Fixes#15262
Use case
========
If apply base on a product, it takes only the first line of this product !
Eg: 1 free if 3 buy,
- add 2 line of 2 will not work,
- add 1 line of 1 (eg: discounted, descr, ...) and one ligne with 10... will be ignored
Description of the issue/feature this PR addresses:
This commit adds the recompute conditional clause in the ORM unlink method.
This behaviour is already present in branch 10.0 as it can be seen in line 3431.
With this, the possibility of disabling the automatic recalculation of computed fields is given back to the developer of custom modules in performance critical scenarios. By using the Environment class "norecompute" context manager, the developer can now unlink records in a very fast manner and afterwards, execute the computed fields manually if needed (via an explicit method call or a direct sql update).
Current behavior before PR:
Having this option in the ORM will allow to speed up the system if needed when massive collateral changes must be made. One of this scenarios has to do with the modification of one2many fields and the write_uid and write_date computed fields. In the account module for example, when unreconciling account move lines, the deletion of the partial reconcile records involved in the reconciliation triggers a one by one update of the related account move lines and account moves. If the involved documents are big, such an account move (Journal Entry) with thousands of lines, if one of its lines is reconciled and afterwards unreconciled, the process can take several minutes due to expensive one by one recomputations such as the ones involved in the modification of the write_uid and the write_date in the models.py recompute() method. This modifications can however be enforced later with a couple of SQL update statements, instead of thousands of them executed by a for loop.
Desired behavior after PR is merged:
Developers of custom modules will now have the possibility of disabling the automatic calculation of computed fields, as it can be done in the create method (models.py "_create()" line 4370). This is vital for performance reasons, specially when handling big documents such as thousands of lines account moves or sales orders.
This is basically a backport of revision f259e74f8a
this commit introduces the '/history' command
for an operator during a livechat session.
When the visitor load a page, its url is added in
a cookie (kept only 1 day) in order to track his
visited web pages.
The '/history' command will ask the cookie content
and send it to the operator as a transient message
in the livechat channel.
Replace deprecated options for the updated version of the
bootstrap-datetimepicker lib.
Lazy load the library in the front-end as well in order to avoid loading
it in all the front-end views.
* toggle datetimepicker when field is clicked
* close datetimepicker when a date is chosen
* disable keyboard navigation in the widget to allow modification of input
Complements the patch in 4715d18e12
in order to properly bootstrap a writeable data_dir when it is
(partially) nonexistant.
Depending on the startup parameters the data_dir might otherwise
have ended up read-only, preventing the creation of its necessary
components (session store, file store). Only the `addons` directory
of the data_dir needs to be read-only by default.
When validating a new order in between the create_from_ui RPC call and
the corresponding callback this new order was lost. There were two
reasons for this.
First of all, the Mutex supposed to prevent multiple create_from_ui RPC
calls from happening at the same time did not return a Deferred. This is
problematic because this function gets passed to jQuery.when() which
will consider functions that do not return a Deferred to be resolved
upon return.
Secondly, the resolved callback of the create_from_ui RPC call naively
deleted all paid orders, assuming they were all successfully sent to the
backend. This is not the case when an order is added to the orders array
in between the RPC call and the callback.
Closes#15190
Complements the patch in 8235f03f56
in order to properly bootstrap a writeable data_dir when it is
(partially) nonexistant.
Depending on the startup parameters the data_dir might otherwise
have ended up read-only, preventing the creation of its necessary
components (session store, file store). Only the `addons` directory
of the data_dir needs to be read-only by default.
Complements the patch in 15583a4813
in order to properly bootstrap a writeable data_dir when it is
(partially) nonexistant.
Depending on the startup parameters the data_dir might otherwise
have ended up read-only, preventing the creation of its necessary
components (session store, file store). Only the `addons` directory
of the data_dir needs to be read-only by default.
Before, when you would put a quantity in a BoM line that was not rounded
to its UoM (e.g. use 0.3 piece with rounding 1.0) it would not round this
quantity in the MO also (when exploding the BoM), and the user could also
enter a not rounded quantity himself for the quantity produced or
consumed.
The moves were split with the exact quantities, but the moves were validated
taking into account rounded quantities. This resulted in either moving 2
pieces instead of 1 (entering 0.7 or 1 piece) or raising an error telling
you can not process moves with 0 quantity (0.3 piece).
As product_efficiency and product_rounding was removed from the BoM/BoM
line in v10, if the rounding is correctly handled, the feature could work
like in v9, by e.g. putting 1.03 in the bom line (97% efficiency) and
rounding up when exploding the BoM (e.g. producing 10 pieces would put
it to 11).
When "producing", we round the produced qty to the product uom (it does
not make sense to produce 1.32 if your uom rounding is 1.0). The user
might now change the produced quantity, that's why we round-up when
validating the move: indeed, if the user slightly increase the produced
value (below the uom unit), it actually means he produced more.
This way, instead of not rounding anything and doing rounding behind the
scenes, leading to errors, we round everything and the user sees the
result directly.
When going to the General Settings and clicking a link generating
breadcrumbs, the breadcrumbs would not always read "General Settings".
Not sure why, but Odoo seems to takes the breadcrumb name from the last
ir.actions.act_window with the res_model being "base.config.settings".
In google_calendar: such an action was named API Configuration.
In hr_attendance: the settings wrongly inherits from base.config.settings
without renaming the model.
-> Model is renamed to attendance.config.settings like
in other modules (e.g.: sale) to avoid collision.