Button to create new opp are reserved to graded partner.
Employees will use backend crm, and classis portal user cannot create lead for them.
+ fix 403 when create an opp because no access on crm activities.
This opw fixes#21222
Before this revision, it was not possible to display a chatter inside a <sheet>.
As the chatter is reused (when switching in edit, records, etc.), it is detached
(to keep its handlers) before updating the form $el.
The problem here is that the chatter was detached in `_updateView` from
`$form.contents()` where the chatter is a root element ; when setting the form
view html, the chatter was thus still present. This was thus only working
correctly if the chatter was a direct child of <form>.
To keep it displayed in all cases, we now detach it at the chatter node
rendering.
Closes#20032
When launching in an empty db the following command:
./odoo-bin --addons-path=../enterprise/,addons --db-filter=11ent -d 11ent -i sale_timesheet --test-enable --stop-after-init
it raised a traceback because no sale journal was defined.
opw:783489
related to rev 0d19ee989d
It was broken following the refactoring done in saas16, resulting in
barcodes being handled on all the displayed forms and it was problematic
in the case of a form dialog openned over a "fullscreen" form view.
This was particularily problematic for the scrap dialog in the
stock_barcode module.
Before this commit, it was not possible to choose the user you want to
chat with in a chat window anymore. This was because the dropdown that
suggest the users appeared under the chat windows since commit
https://github.com/odoo/odoo/commit/7b965a9673a9124e6e045b8a290a156eed402ad5
Indeed, the mentioned commit changed the z-indexes so that chat windows
are still usable when a modal is opened. This was done by making the
chat windows always have the greatest z-index... forgetting this would
make them appear on top of their own autocomplete dropdowns.
This commit restores the feature while keeping the ability to talk while
a modal is opened. See code comments for details.
opw-785162
When expensing a service product, an SO line is created
on the SO from the hr expense. This creation triggers
the service object creation (task and/or project), and
should not.
To avoid this, we check if the ordered quantity
is not zero to avoid use the expense policy (or
any expensable product will not be able to create
task/project).
The same mecanism is used in stock to avoid picking
creation when expensing stockable product.
When we create an analytic account, a project is automatically
generate, and it should not. This is a bug coming from
the removal of 'use_tasks' field. See eb4ad33513.
We can now remove all the 'project_create' and
'project_creation_in_progress' context key.
When searching a SO line, we want to search on its own
description in case of 2 product with the same name
are present on the SO. This help user to differenciate
them.
When a datetime was selected in a search filter, the time wasn't
converted to UTC to the server.
So, there were unexpecting records due to the wrong query domain.
When we retrieve the value from the datepicker, we need to convert
it to UTC before sending it to the server.
Steps to reproduce the bug:
- Login as demo user on runbot 11.0e
- Open a contact
- schedule an activity, "todo" , assigned to Administrator
- Clicking on the "i" icon next to the planned activity,
you see that the "Created by" is "Administrator" , which is incorrect
Since this commit: 53ad585bfc, the field
create_uid is always 1.
opw:783650
It could happens that an SO is canceled once the
associated PO has been confirmed/shipped.
In this case it could be usefull for the end user
to notify him in order to process manual actions.
Use case to reproduce:
- Create a SO with a product MTO and confirm the PO
-> PO -- Stock -- SO
- Cancel the SO
-> PO -- Stock canceled SO
- Set the quotation to draft and confirm it again
-> PO -- Stock
RFQ -- Stock -- SO
- If the user cancel the RFQ we will get this diagram:
-> PO -- Stock
Stock -- SO
The user can't reserve the chain correctly. Also a new RFQ will be
generated each time the user delete the existing one even if the PO
already exists.
It happens because the move keep the procure methode MTO although
the moves origin and destination links are broken.
This commit changes the move destination from purchase order
line to MTS if the RFQ is deleted. This implies that RFQ are
not automatically generated by the scheduler.
Purpose
=======
Currently if a project doesn't use pads, the created and duplicated tasks will initialize/copy them. That could be a real issue when migrating customers if we create a task for all the existing issues, since the models have been merged.
Specification
=============
Avoid this falsy behavior. We're forced to crappy fix with a context key as the project.task model 'inherit' from pad.common.
Before this commit, saving a file being watched by watchdog
(--dev=reload) with vim (and possibly other text editors) would
crash the server via a KeyboardInterrupt error.
This happens because vim, emacs cause multiple filesystem events to
happen when saving a single file, the FSWatcher registers these events
as multiple SIGHUPs which in turn calls restart() multiple times in a
very small amount of time which makes the KeyboardInterrupts completely
shut down the server
This is fixed by only calling restart() if odoo.phoenix is False, since
catching a SIGHUP sets it to true.
Fixes#21178
Special thanks to @odony for the help :)
* In Python 3 xlwt apparently does not support writing bytes values ->
try to decode assuming the value may be base64-encoded, this is more
or less the behaviour for CSV exports.
This will most likely not allow the export anyway as Excel cells are
limited to 32k data characters, which accounting for base64
expansion means ~24k worth of data, but that is a pre-existing
issue.
* Also removed support for way outdated browsers from
content_disposition: the Safari case is for Safari 5 (circa 2012)
but versioning apparently changed since then and modern Safari
report their "external" version number rather than the webkit
version number => the current Safari reports version 11, and gets
routed to the "does not support unicode file names", which is
further bugged in Python 3 as it %s's bytes, leading to a resulting
filename of e.g. `b'res.partner.csv'.csv` (with the prefix and
quotes).
* The IE case is for IE8, which has long been unsupported by the web
client.
Before this commit, when reconciling with a tax included line,
the journal entries were wrong as the amount taken into account was the one that was **already** computed with tax
e.g:
TAX: 20%
amount of the line (tax included): 1
tax amount: 0.17
base amount: 0.83
what was sent to the server was the basea amount, and since python re-computes the taxes
it reapplied tax included 20% on 0.83 instead of 1
After this commit, we send the right amount to the server,
at the small price of semantics change in the meaning of "amount"
OPW 783933
closes#21189
This commit implements the same fix already made in commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df, but this time applied to the tree view of the sale order lines, instead of the form view.
Without this fix, if you add new lines in the sale order by using the tree view (instead of the form) you can get the following error:
```
Odoo Server Error - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: product_id - product.id]
```
The error is because the "product_id" value is not sent to the server. The "product_id" value is mandatory for sale order lines.
To reproduce the issue, you need to reproduce the following scenario:
- create a new sale order and save it
- edit the sale order; you should be able to edit inline the sale order lines (by the tree view)
- create a new product, being sure that the field 'product_id' is readonly (field 'product_updatable' is False).
- try save the sale order
See detailed explanation of the issue in description of commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df.
PR #21211
This commit implements the same fix already made in commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df, but this time applied to the tree view of the sale order lines, instead of the form view.
Without this fix, if you add new lines in the sale order by using the tree view (instead of the form) you can get the following error:
```
Odoo Server Error - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: product_id - product.id]
```
The error is because the "product_id" value is not sent to the server. The "product_id" value is mandatory for sale order lines.
To reproduce the issue, you need to reproduce the following scenario:
- create a new sale order and save it
- edit the sale order; you should be able to edit inline the sale order lines (by the tree view)
- create a new product, being sure that the field 'product_id' is readonly (field 'product_updatable' is False).
- try save the sale order
See detailed explanation of the issue in description of commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df.
PR #21211
When the result packaged is changed on a move line, we should not change
the reservation of quants, because result_package is not related to
reservation, only package_id is used during the reservation.
We also changed the copy of move_line when we split a move line to put a
part of it in a package. By copying the move line and set the
product_uom_id in the default values of copy function, we mess the
reservation, because there is no quant reservation made for the move
line even if the move_line has a product_uom_qty. So we set the
product_uom_qty to 0 when copying the line, and then write the
product_uom_qty which will call the quant reservation
Fixes#20784
Remove the condition checking that the postal account field of bank accounts only accepts mod10r-verified references, as not all banks use such references (example: UBS).
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
When using this module, the default behavior is to generate timesheet.
This timsheet is linked to a project and a task and there is a
constrain that verify that the task and project are set on model.
If another module (like l10n_fr_hr_payroll for example) tries to
create holidays.status without a project and task, it causes a
traceback.
This commit adds default values for these fields in order fullfill
the constrains.
Notice that the order of the imports in the __init__ is important
because the columns have to be created on the res.company before the
status is initialized.
Example of failing request:
```
rpc.query({
model: 'link.tracker.click',
method: 'read_group',
args: [[links_domain, ['create_date', '>', interval]], ['country_id']],
kwargs: {groupby:'country_id'},
});
```
The RPC request built contains the following:
```
args: [[["link_id", "=", 1]], ["create_date"]]
kwargs: {groupby: "create_date:day", domain: [], fields: []}
```
This will be interpreted server side as:
```
model.read_group([['link_id', '=', 1]], ['create_date'], groupby=['create_date:day'], domain=[], fields=[])
```
2 arguments match `domain` and `fields`, which causes a crash.
opw-781300
Usacase to reproduce:
- Plan MO with 2 unit to produce.
- Produce 1 unit
- Update the quantity to 1
-> Traceback
active_move_lot_ids should have been changed to
active_move_line_ids during the forward port to 11.0
from this commit d62b307597
Use case to reproduce:
- Create a BOM with a component product tracked by SN
- Create a MO for this product and reserve it.
- Plan WO and process it.
- Register the same lot than the reserved one.
-> Error message: you can't use twice the same serial number
It happens because WO use temporary move line that should not
be considered as a real object. However it exists is a constraint
that trigger if two move lines share the same SN for the same product.
It's a wanted behavior that a real move line share the same SN that
temporary move lines.
This commit prevent real and false move lines comparaison.
on pricelist, open a pricelist form
click on one country group [country group form opens]
click on a pricelist again
Before this commit, a traceback appeared, saying the pricelist record was null
YET the pricelist's form on which we clicked before opened.
After this commit, the form of the pricelist opens, and no traceback is thrown.
OPW 783896
[FIX] web: test circular many2many
closes#21148
Otherwise, when rendering the 'Product' template it crashes when calling
the 'get_price' method.
Indeed, we need to add products as a Product model instead of as a plain
JS object.
Use case(stock_picking.py):
- Sell a product which has tracking enabled
- Reserve the stock on the delivery order and assign to all stock.move.line a lot/serial, but leave the qty_done zero
- You will get an error message which is not correct
(stock_quant.py)
Give more information about the source of failure
opw:783828
Jeremy Kersten