Scenario:
- add a file in mass mailing editor => an icon is added linking the file
- save
- edit => the icon is replaced by a generic icon
- save
- send mail => no icon is shown in email received
The system is using eg. `data-mimetype="pdf"` to show the icon, before
12.0 this worked but in saas-12.3 the system uses mailing.mailing
body_arch's field that is sanitizing attributes and remove it on save,
so the icon is only working in received email if you save one and only
one time after adding file inside the mass mailing.
opw-2474053 (ticket for similar issue in 14.0)
closesodoo/odoo#70057
X-original-commit: 7e14515b84d8081557517df7e9dc7d8c0d17f2be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#70058
Forward-port-of: odoo/odoo#69993
Forward-port-of: odoo/odoo#69927
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field
Problem:
The specific fields to a Swiss company appear.
Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.
opw-2504699
closesodoo/odoo#70011
X-original-commit: 326dc3f7001f605d7ebb929740ed8478fce20e7e
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a user U not in group group_system
- Log with U
- Create a vendor payment with payment method Checks
- Print it
Bug:
An access error was raised because U didn't have the rights to write on model ir.sequence
opw:2513014
closesodoo/odoo#70062
X-original-commit: 11376c88e0068a0bece0b0b56ffd4a9f296ffb87
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When the user submits a form, a lead will be created but the language
won't be the one selected by the user.
To reproduce the error:
(Enable debug mode)
1. Settings > Translations > Languages
2. Activate another language L_other
3. On website, add a form:
- Action: Create an Opportunity
4. Add an existing field: "Language"
5. Submit the form
- Language must be L_other
6. Consult the new lead
Error: The language is not the selected one.
OPW-2486276
closesodoo/odoo#70050
X-original-commit: 8d6a971a8dba860fe7c2a453c3a15f62916f656a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps:
- Go to Inventory / Products / Products
- Create a product (2)
- Storable Product
- Cost: 10
- Click Update Quantity
- Create a new quantity line with 3 in On Hand Quantity
- Update the line with 1 in On Hand Quantity
- Go back to the product
- Click the "Forecasted" smart button
Bug:
The on hand value is 30 instead of 10.
Explanation:
When `location_dest_id` is the current location, it is used to specify
that a given quantity has been added to this location's stock. However,
when removing a quantity, the move goes from the current location to a
virtual one. The current location is, in this case, stored in
`location_id` and the destination is the virtual location.
This makes stock removals not appear in the on hand value since we only
filter the layers on their move's `location_dest_id`.
This commit assumes that a move always goes from or to a virtual
location and checks if the current location is in `location_dest_id` or
in `location_id`.
opw:2510911
closesodoo/odoo#70038
X-original-commit: 978853a6355e36e81752bf0714102f519a6a7931
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Use the last version of raspberry pi os to build the IoT Box
We don't hold anymore the firmware-brcm80211
closesodoo/odoo#70037
X-original-commit: a8c952fe477d22f5a88696df44e63faca13cba06
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this update if you would update the module the default livechat details would be reset.
By wrapping it in a no-update they're not updated with a module update.
closesodoo/odoo#70029
X-original-commit: 45c330c1e44d6a9526596b5ec1dfbff317579b68
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Scenario:
- add a file in mass mailing editor => an generic icon (instead of lower
version where icon depended on mimetype) is added linking the file
- save and send mail => no icon is shown in email received
The system is targeting `a[href*="/web/content/"][data-mimetype]:empty`
to add real image inside instead of using background-image attribute
which is stripped in sanitized.
With this commit, data-mimetype is not removed when image processing
attributes are removed when a file is inserted.
opw-2474053
closesodoo/odoo#70022
X-original-commit: eb3772508ce518ff3f84724eebbe43fd1e040d77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose of the commit is to do the generic improvement for the
refactoring of some module's view.
So in this commit, done the following changes:
- Reporting > Tasks Analysis , average progress of each task display correctly
- In project overview:
- state button is fit correctly in report view
- In task quick create, added placeholder for name field
- In Product form view:
- service_tarcking field: rename 'don't create task' into 'don't create a task'
- display the share button if privacy_visibility should be portal
- remove the 'Documents' stat button
- In Tasks list view, allow users to edit the stage of the task in batch if the project is in the context
- In project kanban view, remove the 'profitability' link and the corresponding stat button on sale.order
task-2458123
closesodoo/odoo#68146
Related: odoo/enterprise#17201
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
When synchronizing microsoft calendar events, if the event is permanent
Microsoft says the endDate is "0001-01-01": we save that and this causes
an error when it is being parsed in javascript since we require a date
with higher than 1000 years in require('web.field_utils').parseDate
function.
With this changeset, we do not set endDate if the type of the event is
not endDate (as shown[^1] in the documentation endDate only makes sense
for event of type endDate).
[^1]: https://docs.microsoft.com/en-us/graph/outlook-schedule-recurring-events#recurrence-ranges
opw-2479029
fixes#69481closes#69944closesodoo/odoo#70009
X-original-commit: 7aa233e63a8c82cce8336adb99418a96e061268f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In the Argentinean invoices report view, we were removing the Payment
Terms and we were only showing the Payment Term name in the header.
Now we add it back following the Odoo approach but we also keep the name
of the terms on the header.
We made this modification in the invoice report with and without payment.
original commit: 6a0cf2e
closesodoo/odoo#69998
X-original-commit: bf88ef700fc0224b973f3e6142db42799a2eccb1
Signed-off-by: Josse Colpaert <jco@openerp.com>
account_payment:
- Processing fees computation was done based on the wrong country.
payment:
- The acquirer's cancel message was missing from the
/payment/confirmation page.
- `redirect_form_view_id` field was declared with attribute 'name'
instead of 'string'.
- Uninstalling a payment acquirer would fail with a traceback.
- The first acquirer was not automatically selected if it was the only
selectable payment option of a 'manage' payment form.
- Specifying a preferred acquirer to the /payment/pay page would show
not acquirer at all if the preferred option was incompatible with
the constraints, rather than falling back on showing all acquirers.
payment_adyen:
- When the value of the API URL fields is malformed (e.g., missing the
"https://"), clicking on the confirm button raised a traceback.
payment_ogone:
- There was a typo in the return route.
payment_paypal:
- PayPal acquirers were not filtered out if the currency was not not
supported.
- Returning to the webshop without paying would raise a traceback.
task-2494916
closesodoo/odoo#69996
X-original-commit: 4f7e463fb8b13506caa8aff0beeef5eb0720bf00
Related: odoo/enterprise#17997
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
This mostly an issue when trying to run just the tests of `web` (aka
`-iweb`) with only community modules available,
`TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the
ready code times out:
AssertionError: False is not true : The ready "odoo.isReady === true" code was always falsy
and the test suite fails.
The ready code simply checks that `odoo.isReady` is set. The web
client sets `isReady` when `webclient_started` is
triggered (specifically in `_onWebClientStarted`, which is the handler
for that event).
[The community web client only triggers `webclient_started` at the end
of `doAction`][0] meaning the community client is considered ready
until after the first action has executed.
[The first action is executed by `show_application`][1] whose process
is the following:
1. load and initialize the menus
2. if an action is specified in the URL, run that
3. otherwise if the user has a home action, run that
4. otherwise run the first menu's action
When installing only `web`, the only menus which could be available
are Apps and Settings, and the demo user has access to neither. This
means the demo user has no applications, and opening the first app is
a no-op ([`openFirstApp` has a case just for that situation to ensure
it does nothing][2]). As a result, `webclient_started` is never
triggered, `_onWebClientStarted` is never called, `odoo.isReady` is
never set, and the tour never runs.
Fix by updating `openFirstApp` to return *whether* it opened an
application, and in `show_application` the last fallback if even
opening the first application failed is to just declare the web client
ready.
While at it, rewrite `show_application` using ES6 facilities and
flatten and linearize it using guards. This means the code pretty much
tracks the process described above, with one step added:
5. otherwise complete the webclient's startup
[0]: https://github.com/odoo/odoo/blob/1eb474243b55f1b9e10c70d199bbe022e68b51d0/addons/web/static/src/js/chrome/action_manager.js#L174
[1]: https://github.com/odoo/odoo/blob/d1c56ec7c435c5baba8604feccc6116e4c25ca96/addons/web/static/src/js/chrome/web_client.js#L77-L107
[2]: https://github.com/odoo/odoo/blob/e24ab17d38fb049404f04112990e8b2fe1dd7727/addons/web/static/src/js/chrome/apps_menu.js#L44-L46closesodoo/odoo#70039
X-original-commit: a5b2146404da9ea0cd4752a21dcd230140822c86
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.
closesodoo/odoo#70032
X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When resuming a POS session, if the latter has been opened in the past
and if its state is 'Opening Control', a incorrect UserError is raised
and prevents the session to be started.
To reproduce the error:
1. Use a French company
2. Create a POS
- Enable "Advanced Cash Control"
3. Start a new session
4. Close it
5. Set the computer's date in the future
5. Open the POS session > Continue Selling
Error: A UserError is raised ("This session has been opened another day.
To comply with the French law, [...]"), but the user does not have the
possibility to close the session. Moreover, since its state is "Opening
Control", no sales have been made yet.
This fix suggests to reset the start date in such a situation.
OPW-2488952
closesodoo/odoo#69994
X-original-commit: f7048c1de139113eb6109787e669160146319bd3
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.
closesodoo/odoo#69990
X-original-commit: 8a4f4bf04bd5e5f9cf827273ea27a189a43c2515
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit, we add all the data related to the Argentinean
perceptions for each jurisdiction.
For each jurisdiction (xx) we have a new:
* Tax: Percepción IIBB xx Sufrida
* Tax: Percepción IIBB Catamarca Aplicada
* Tax group: Perc IIBB xx
* Account: Saldo a favor IIBB xx
* Account: Retención IIBB xx sufrida
* Account: Percepción IIBB xx sufrida
* Account: Retención IIBB xx aplicada
* Account: Percepción IIBB xx aplicada
* Account: IIBB xx
Also, we activate some perceptions to work with demo data
closesodoo/odoo#69873
X-original-commit: 0dcc71314d41fb30559495695f7a626b4c1b20e3
Signed-off-by: Josse Colpaert <jco@openerp.com>
Have a Fiscal position FPOS which map tax A to tax B
Have products DEMO with tax A and DEMO2
Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2
Close POS
Go to Orders, select the last one, hit return, edit, delete DEMO2 line
Tax will be wrong.
This occcur because the fiscal position mapping fail an equivalence
check with a virtual record, so the tax is calculated as A and not B
opw-2485399
closesodoo/odoo#69952
X-original-commit: 983797e626f742e84710de7ec8487824d6eaa7f1
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Usecase to reproduce:
- create a product with 0 stock
- Sale order 500 units
- a RFQ is created for 500 units
- in replenishments, you have 0 units to order, OK
- RFQ --> confirm PO
- in replenishments, now the quantity to order is 500
--> should still be 0, it leads to confusions
It happens because the replenish action check the missing
quantity for today. It result by -500 units since the delivery
is planned for the next day (default supplier lead days = 1).
But since the orderpoint exist, the quantity forecasted is
already computed correctly with the right lead time.
But the action will remove the 500 missing today from the
quantity forecasted (The idea is to add the missing quantity on
the main location. e.g. I have
-10 units in WH/Stock/Shelf1
-20 units in WH/Stock
The orderpoint will only look for its own location -> 20 to reorder
The replenishment report look by warehouse and not by location -> 30
missing. So 30 missing + 20 incomming -> 10 to add (by default on
WH/Stock)
The fix is to add a step when a product is missing then compute its
virtual available with lead days (to avoid missing confirmed moves
during the lead time).
opw-2456978
closesodoo/odoo#69527
X-original-commit: f939c7b2c4143d685c25d155a164d63070d36ed2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This revision solves two things:
- On installation of `l10n_latam_base`,
`l10n_latam_base` is set as default as `l10n_latam_identification_type_id`
for all partners in the database.
The ORM method `write` was used to do so.
With a database having a large number of partners,
such as multiple hundred of thousands,
this leaded to performance issues when `l10n_latam_base`
got installed.
I checked compute methods that could depends on this field,
and the only one I found is `_compute_l10n_ar_vat`,
which is not yet `installed/loaded` when this posthook takes place,
as it's in the module `l10n_ar` which depends on `l10n_latam_base`
and therefore is loaded after. So, it was already not executed/computed
when using the ORM `write` method before this revision.
Therefore, the use of plain SQL can be used to speed up the performance.
- Also, the ORM `write` triggered unexpected compute fields
which could raise exceptions, because of the `commercial_partner_id`
synchronization.
For instance:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1198, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 455, in load_modules
loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 348, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 239, in load_module_graph
getattr(py_module, post_init)(cr, registry)
File "/home/odoo/src/odoo/14.0/addons/l10n_latam_base/__init__.py", line 8, in _set_default_identification_type
env['res.partner'].search([]).write({'l10n_latam_identification_type_id': env.ref('l10n_latam_base.it_vat').id})
File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
return super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
return super(ResPartner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
res = super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 550, in write
partner._fields_sync(vals)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 469, in _fields_sync
self._children_sync(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 478, in _children_sync
self._commercial_sync_to_children()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 452, in _commercial_sync_to_children
sync_children._compute_commercial_partner()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 297, in _compute_commercial_partner
partner.commercial_partner_id = partner.parent_id.commercial_partner_id
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1127, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
return super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
return super(ResPartner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
res = super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 546, in write
result = result and super(Partner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_activity.py", line 766, in write
return super(MailActivityMixin, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 322, in write
result = super(MailThread, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/website/models/mixins.py", line 182, in write
return super(WebsitePublishedMixin, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3640, in write
self.modified(relational_names, before=True)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5786, in modified
tocompute = list(tocompute)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5862, in _modified_triggers
yield from records._modified_triggers(val)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5858, in _modified_triggers
records |= model.search([(key.name, 'in', real_records.ids)], order='id')
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1708, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4492, in _search
self._flush_search(args, order=order)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4470, in _flush_search
self.env[model_name].flush(field_names)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5442, in flush
self.recompute(fnames, records=records)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5908, in recompute
process(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5879, in process
field.recompute(recs)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1145, in recompute
self.compute_value(record)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4068, in _compute_field_value
self.filtered('id')._validate_fields(fnames)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1260, in _validate_fields
check(self)
File "/home/odoo/src/odoo/14.0/addons/sale_project/models/project.py", line 70, in _check_sale_line_type
product_id=task.sale_line_id.product_id.display_name,
odoo.exceptions.ValidationError: You cannot link the order item SO/2019/11374 - [COMOD2H] Servicio de Correctivo dos Horas to this task because it is a re-invoiced expense.
```
upg-11324
closesodoo/odoo#69958
X-original-commit: 680bd481412823b66fcf45c9312a59c7029e200b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit follows https://github.com/odoo/odoo/pull/64948
Before this commit, the mail composer was not properly used. It was not started with a model and business document ids.
This commit also reverts a keyword context value for the sms composer.
closesodoo/odoo#69910
Taskid: 2342252
X-original-commit: 14629c8e1778269dc2ccc0dedd5e39b23c78669f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
The domain for the fiscal position in the carryover lines was incorrect,
missing the required quotes.
closesodoo/odoo#69921
X-original-commit: 85c07f0f93d664bf7f6028a1dfa0f663e2999c3d
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.
Technically, this condition is used to get the translated name of records to
later construct the canonical URL.
Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.
[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions
--------
Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.
opw-2486918
closesodoo/odoo#69918
X-original-commit: 733411fe03b924832d6b10cadf93c8fc09cc5802
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Try to export mail.message records
Bug:
A traceback was raised
Wrong forward-port of 69b27ac
opw:2514584
closesodoo/odoo#69912
X-original-commit: 9cf49ba3fa60c174abffc5c048616f91397f7b9d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The "note-editable" class was lost on the editable element when loading
it into an iframe. As a result, some selectors failed, making it so that
some options wouldn't activate when they should.
closesodoo/odoo#69908
X-original-commit: d71b7d87daa5b33f16eb9c6ade29580fb2076313
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a partner have two delivery address, one full filled, an other with missing
fields.
During the shopping (the first delivery address is auto selected), if the
partner go back in /shop/address to select the second address.
Then go to /shop/confirm_order, there no checks.
closesodoo/odoo#69901
X-original-commit: f8c8418bdd5b9d27b33fea3c63511297a231aa93
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When running an automated action on record creation, if the action
raises a UserError/ValidationError, the record will still be created.
To reproduce the error:
(Need website_crm,base_automation. Enable debug mode)
1. Create an Automated Action
- Model: Lead/Opportunity
- Trigger: On Creation & Update
- Trigger Fields: Phone (crm.lead)
- Action To Do: Execute Python Code
- Python Code:
```python
if record.phone:
raise UserError("Lorem ipsum")
```
2. On website, add a website form WF
- Action: "Create an Opportunity"
3. Complete and submit WF including a phone number
Error: An error message is displayed ("Lorem ispum"). However, the lead
has been created and is present in CRM Pipeline.
An on-creation automated action is executed once the record is executed,
but nothing will cancel this records creation if the action raises a
UserError/ValidationError.
OPW-2423948
closesodoo/odoo#69911
X-original-commit: 8d452ae16b7e6c3077d9eae135852bada43cec93
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In an iframe, we need to make sure the element is using jquery on its
own window and not on the top window lest jquery behave unexpectedly.
This was apparent with tooltip which was called in snippets.editor with
the "wrong jquery", with the result that tooltip.js had a reference to
the top window/document instead of that of the iframe. Because of that,
it appended its tooltips to the top window instead of the iframe, and
as a result, said tooltips were wrongly positioned.
closesodoo/odoo#69879
X-original-commit: 19be8709efa8f690ccff8d04dd9a17e4ef4d82fd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
The overlay around an image when cropping it is positioned absolutely.
If it has no relative ancestor, it will cover the entire body. This is
what happend in mass_mailing, making it impossible to scroll the page
while cropping. This commit addresses the issue by positioning that
editable relatively so that the overlay never goes beyond its bounds.
closesodoo/odoo#69878
X-original-commit: c4d423640a9f1f9892e9d24dc08531ba0bbf8887
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the colorpicker is in an iframe, listening to mouse events on the
global document can have unexpected effects. Namely clicking in the
colorpicker, then moving the mouse outside the iframe made it move the
color cursor.
This fixes that by binding it to the parent widget's document, with a
fallback on the global document in case it's missing.
closesodoo/odoo#69877
X-original-commit: 4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
currently, Across Odoo, there are bugfix folder in around 13 module,
New manifest system allows to add new files in stable so the bugfix files are no
longer required.
after this commit,
all the bugfix files are removed from all module.and all the code in those file
is maintained as per New manifest system.
Task : 2510653
closesodoo/odoo#69830
Related: odoo/enterprise#17936
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This makes it possible to declare an element unsuitable as parent of the
tour tip via the "o_forbidden_tooltip_parent" class.
We then apply this class to the "o_we_customize_panel" of mass_mailing's
snippets menu so the tip is applied to its parent like in saas-14.2.
Without that, the tip is hidden by the body of the mail. The reason it
was positioned in the parent in saas-14.2 is that the theme selector
wasn't in the customize panel but positioned absolutely above it.
This is an ad-hoc fix to something of an ad-hoc situation, given the
relative weirdness of the html environment (the snippets menu is in the
padding of the body of an iframe).
closesodoo/odoo#69876
X-original-commit: 58d5af5df81926af1a5715dd57f6b5c3b40b1e16
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit is fixing two issues:
1: make ribbon translatable
2: display ribbon below smart button
closes#68438closesodoo/odoo#69838
X-original-commit: cbed573e6146a0aab6e0e9114be515a347cd10a4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We need to check the selection on click in the editor's document so as
to update the visibility of the toolbar (we want to hide it if the
selection is in a non-editable area). When the editor was in an iframe
however, the wrong document was targeted: we want to check on clicks in
the editor's document, not the top document.
closesodoo/odoo#69775
X-original-commit: b0429c96e30751390991a9471a4c031dfed98d81
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Create a company whoose name ends with a dot like "Bidule Inc.", change
the company of the user to that new company, head to the Accouning
module and create a new journal of type purchase. Traceback because the
generated mail alias for that journal uses the company name and that the
local-part of an email cannot ends with a dot.
From the RFC standpoint, the local-part of an email address (the part
before the @, `john` in `"John Doe" <john@example.com>`, cannot begins
with, ends with or contain following dots.
The email sanitizing function have been updated so it takes care of the
above requirement.
See also #61811
opw-2448692
closesodoo/odoo#69864
X-original-commit: f0e840ae6db387e1dfc99cc21e09d84eb126e7b9
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'purchase_product_matrix'
2. try to edit a PO with more than one line
3. try to change the order of a product line
What is currently happening ?
Traceback: TypeError: Cannot read property 'data' of undefined
What are you expecting to happen ?
Change order lines without traceback
Why is this happening ?
There is a function 'reset' that checkes if 'ev' exists:
https://github.com/odoo/odoo/blob/e0af10ccc92cb3b07f0eea6fa44ebf5a1bdc86aa/addons/sale/static/src/js/product_configurator_widget.js#L119
And in 'purchase_product_matrix' there is a override of this same function that calls it
and then tries to use an 'ev' attribute without checking it before
How to fix the bug ?
Check 'ev' before accessing it
opw-2513061
closesodoo/odoo#69856
X-original-commit: 25312bc576b9e0330eb316e77d8a177ee0434832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Task 2352493
When the user is asked to fill in the label on the invoice, the tooltip
tells him that the label can be auto-filled by configuring its products.
This leads the user to configure products. But then, as he doesn't fill
in the label, the tour is "broken".
closesodoo/odoo#69871
X-original-commit: 78b5536a4c6fa7a20d8fd182fcd85726c2a8555f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When the payment form is displayed, Stripe.js library isn't loaded, thus preventing the customer to pay online.
When the refactor of assets was done, the link to the Stripe library was moved to __manifest__.py.
As the link does not end with '.js', the file wasn't loaded anymore.
See PR #60632closesodoo/odoo#69849
X-original-commit: 8535b090a36fe6472c4b3d8211f3be39c7f1c58a
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Valentin Chevalier <chevalierv@users.noreply.github.com>
Nicolas Lempereur