Before this commit the schedule and timezone were only visible in debug mode. As the default timezone is UTC, some misleading information could be displayed in some cases (e.g. planning without internal users).
closesodoo/odoo#52111
Taskid: 2246557
Related: odoo/enterprise#10370
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Create 3 products:
A: kg, no tracking
B: kg, tracked by lot
AB: kg, no tracking
- Create a BOM for AB:
1 kg of A
30 g of B
- Create a MO for 1 kg of AB, validate and close the MO
- Unbuild the MO
A stock move for 0.03 g of B is created instead of 30 g.
This happens because we wrongly compare the quantity in the UoM of the
stock move with a normalied quantity.
opw-2278727
closesodoo/odoo#53390
X-original-commit: 6790e89f97d6bbbaab4e071af52cce9ccee98821
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently, toast notifications are too far apart with each other if there are
multiple notifications.
So with this commit, we have reduced the margin from the bottom so it looks
closer.
Task : 2278730
closesodoo/odoo#53381
X-original-commit: d43008b38b7b71a5dc1a260560a98ca75e1fafb4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* code *must* have an eval_context, `None` would blow up as soon as it
looks for the `'action'` key
* [accidentally quadratic] eval_value returns a value per line, seems
silly to evaluate all lines for each line when we can evaluate all of
them once, then map results to field names
* eval_value doesn't break inside the loop, so every id gets a value
by construction, `dict.fromkeys` is completely unnecessary (and
provides no performance benefits)
closesodoo/odoo#53110
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
General Purpose : Introduce a new "My Activities" view so that CRM
users can easily overview and process their To-Do list
- new button in "My Activities" tree view : Send Email
Purpose: allow users to send email in one click to the client
- new button in "My Activities" tree view : Send SMS
Purpose: allow user to send sms in one click to the client
- new button in "My Activities" tree view : Snooze
Purpose: easily Snoozes the activity for 7 days
--> today + 7d if deadline < today
--> deadline + 7d if deadline >= today
- New view crm_case_tree_view_my_activities to show "My Activities"
Purpose: Use this view so that CRM users can have a "To Do List"
Domain of this action is : crm.lead, type = opportunity
Filter is : My Activities (at least an activity assigned to me)
- Rename filter "assigned_to_me" to "My Activities"
- Change crm_case_tree_view_oppor to be clearer for the user.
Purpose: allow the user to have an good idea of what he has to do in
a view.
Remove all decorations set on the CRM tree views
Add the widget remaining_days to the field activity_date_deadline
Add the field activity_ids with the widget list_activity
- New menu item and corresponding act_window to display the new views
Task ID 2243124
Community PR odoo#51537
closesodoo/odoo#53376
X-original-commit: 2382c01956feda617b7d207d1bc4d69de1e8b6b3
Related: odoo/enterprise#11314
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`state` was special cased in `copy_data` such that it would always be
reset to its default value if it had one.
While this special case can be useful (maybe) and is certainly
ingrained in odoo, having it not be overridable can be
problematic. Move the special case to the fields, so it's possible to
explicitly mark state fields as copy.
closesodoo/odoo#53113
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
As users find it odd to have the RUC(Registro Único de Contribuyentes) labeled as VAT(from odoo),
so we are going to add the RUC itself to display the right name for users in Peru
closesodoo/odoo#53366
X-original-commit: aba0b299243c3d9b4615e1066d641aa8360aabac
Signed-off-by: Josse Colpaert <jco@openerp.com>
When you create an ir_ui_view form the backend, the encrypt function
was called with a Falsy value and crash with error:
TypeError: secret must be unicode or bytes, not bool
Now, when you create view from backend, we only set password if it is a qweb
view. In case of update, the field is dirty, so if you don't update it, it
will be not write.
closesodoo/odoo#53348
X-original-commit: 3d9101db0f7cc0adc1f34721c38b4c2f7089566d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The attribute has been lost during a previous commit e6695c72d8.
This commit avoid that you can create an ir.ui.view without arch.
Before this commit, if you try to create an ir.ui.view with type but no
arch, the code will raise an exception in _check_xml:
/odoo/addons/base/models/ir_ui_view.py, line 377, in _check_xml
view_arch = etree.fromstring(view.arch.encode('utf-8'))
AttributeError: 'bool' object has no attribute 'encode'
Now, the user will have a warning on create, to say that View Arch field is required.
Could be backported if reported
X-original-commit: 4877bb4b650f5d1c52fefb06dec2fa568afcb121
- Modify `timesheet_action_all` to display the tree view before the grid
view
- In the quotation tree view, order by Status, group by Salesman and
save as filter
- Open a SO with timesheets
- Clck on the 'Timesheets' stat button
An error occurs because the `orderedBy` context key is added in the
action context.
The purpose of replacing the action context is to remove the default
filters. We can simply set an empty dict to avoid any unwanted keys.
opw-2278618
closesodoo/odoo#53339
X-original-commit: 4a0348fed0c7c5b9557d1c9ae2dbf2bbfafcc3a2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, checking if the menu was visible or not combined
with checking if we are on desktop or not was enough. Now that we have
website header templates using hamburger which can be enabled in
desktop, this was not enough anymore.
closesodoo/odoo#53307
X-original-commit: 04e95bc191bba8bc3aaa36aec7b61e085744e85b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Bug
===
Install CRM, then go to the lead kanban view and try to generate leads.
An error will be raised.
Technical
=========
In the "iap.account" model, in the `get` method, we can create the IAP
account if it doesn't exist yet. Since 5307f47d975c3b3ebd87c7f7e2248802a1aa5be7
the operation is done in a different SQL cursor than the current one.
The reason is that we need to commit the change, and committing the current
SQL cursor can cause issue and break some flows (mainly if it's not done
at the very beginning/end of the flow).
In the current code, we cache the `account_token` to be able to read it
with the current SQL cursor (otherwise, the current cursor has no access
to the field because change has not yet being committing for it).
But, the cache is invalidated when the "IAP account SQL cursor" is closed.
```python
with self.pool.cursor() as cr:
...
IapAccount = self.with_env(self.env(cr=cr))
account = IapAccount.search(domain, order='id desc', limit=1)
if not account:
if not force_create:
return account
account = IapAccount.create({'service_name': service_name})
# fetch 'account_token' into cache with this cursor,
# as self's cursor cannot see this account
account.account_token
# <---- Cache is invalidated here
...
```
So we can not access the the field value after the invalidation.
Solution
========
The solution is the store the `account_token` value before closing the
"IAP account SQL cursor" and then, after closing it, we add it in the cache.
Task-2277733
closesodoo/odoo#53323
X-original-commit: 32caf74ff10052d2a303fa24d5cc7b37538dd406
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider that the default company of the current user U is C1
- Log in C2 (only)
- Print the POS details report
Bug:
The header of C1 was displayed.
opw:2274282
closesodoo/odoo#53073
X-original-commit: 59f5e5767445d157d9cd496f6b2b49d516cf003b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Update translation files to match the latest content
Load also translations for fr_BE
It's common to use fr_BE for Belgian people working in Luxembourg
opw-2278849
closesodoo/odoo#53352
X-original-commit: dadb0d088879f7824ab12763dcaf9d8768d9b787
Related: odoo/enterprise#11309
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
for invoice_reference_model field with selection add property in account.journal set ondelete policy that implements the proper cleanup of the corresponding records upon module uninstallation
account.move type field rename to move_type
closesodoo/odoo#53344
X-original-commit: ef0df0562cc5d296006a3288672031fe4f4621e0
Signed-off-by: Josse Colpaert <jco@openerp.com>
On ir.property model, do get the field_id using the cached result from
ir.model.fields _get() method instead of issuing a direct SQL query
OPW-2067461
closesodoo/odoo#53351
X-original-commit: 24fff41d02fc7469d563f732a607db5c9a150e1e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Since dd139948f0 when saving oe_structure for the first time, for eg.
a `<div class="oe_structure" id="oe_structure_part_1"/>` structure, when
edited we will create an inheriting view that fills it.
But this inheriting view would contain branding data and "data-note-id"
which would make this use case erroneous:
- edit page and fill oe_structure => data-note-id="1" saved on view
- edit page and add link in other oe_structure => error
This happen because the data-note-id refers to the editor of the
element currently being edited, since we saved it previously we get two
elements with `data-note-id="1"` and the code will just get the first
one which in reality could have not been in editing.
With this change, we strip the branding data on the parent element.
Without the change, added test failed with:
AssertionError: '<div class="oe_structure" data-test="1"
id="oe_structure_test" test="2">hello</div>' not found in
'<t t-name="dummy"><div class="oe_structure" data-test="1"
id="oe_structure_test" data-oe-id="55" test="2">hello</div>
</t>' :
saved element attributes are saved excluding branding ones
opw-2268836
closes#53321closesodoo/odoo#53346
X-original-commit: 855438be92ee71d8f8d5afedd52459e149ec49f7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Issue
- Install website slides
- Create a slide with document url =
a youtube video URL with params like ?rel=0
- Check it on the website with debugger
The iframe url doesn't have ?rel=0
Cause
We only take the video ID and pass it
to a predefined string. We add light
theme params too.
Solution
Split the given url in order to
get the params and pass it to
the predefined string.
OPW-2275928
closesodoo/odoo#53334
X-original-commit: 5e8fcd3391525192f462cc44acd84d3badb4f132
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create a product with traceability per LOT enabled and a barcode;
- Enable the option “Delivery Packages” in the inventory settings;
- Go to "Barcode" app;
- Scan EAN, the product line will be selected;
- Scan a LOT, a unit of quantity is incremented at each time the LOT is
scanned;
- Put in Pack;
- Scan again the same EAN to register the next LOT, the product line
will be selected with remaining quantities;
- Scan a new LOT number.
Before this commit, as the product line will remain with the old LOT
number, when the new LOT number is scanned a new line is created. This
line will miss the initial quantity and the quantities added to this new
line will not decrement the original line quantity.
Now, the old LOT number is clean when the Put in Pack function is
called.
opw-2270781
closesodoo/odoo#53337
X-original-commit: 01bf263acbe406d45a4b7a5358bdcdfb70c1d9ed
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Wrong usage of self in for loops makes some apparently multi-friendly
methods not work correctly when called with a recordset of len > 1.
This commit replaces those references by the correct unique record
reference which should be used at this iteration of the loop, avoiding
potential exceptions or wrong behavior in the concerned methods.
closesodoo/odoo#53320
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Until Werkzeug 0.14, redirect() would resolve all URLs to absolute
paths or even absolute URL, because relative paths were not valid
according to the HTTP RFCs (though most browsers supported them).
However RFC 7231 allows them, so Werkzeug 0.15 removes this rewrite on
URLs, and `redirect('foo/bar')` now redirects *relative to the current
URL* instead of the old `/foo/bar`.
If `code` is not found, the link tracker loops on the current
URL (`/r/{code}`) instead of redirecting to `/` as was intended.
Going through uses of redirect() this seems to be the only problematic
call site left, others either use absolute paths or they use URLs
coming from the outside.
Task 2254691
closesodoo/odoo#53327
X-original-commit: 3a6e079e54a6f973cfc96995a84a7fabff803f1c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose of this commit is move 'Helpdesk' under the 'Services'
section on res.users form view instead of 'others'.
closesodoo/odoo#52043
Taskid: 2253481
Related: https://github.com/odoo/enterprise/pull/10821
Related: odoo/upgrade#1351
Related: odoo/enterprise#10821
Closes: #52043
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the daterangepicker always opened below the input,
even when there was not enough space to display it. Moreover, when the
user scrolled while the picker was opened, it wasn't stucked to the
input, so the picker was displayed at a random position after the
scroll.
With this commit, we compute the available space above the picker
when opening it, and if there is enough space, we display it above,
otherwise, we display it below. Moreover, we automatically close
the picker when the user scrolls.
task-2117229
closesodoo/odoo#42161
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
In the PDF, `DictionaryObject` can be wrapped in `IndirectObject`. For nested
dictionaries, using `get` on a `DictionaryObject` will unwrap the result if it's
an `IndirectObject`, but not `__getitem__` so when trying to futher call `get`
on the result will cause an error: we need to unwrap the object first.
Instead, we patch `DictionaryObject.get()` for it to unwrap the object in case
it's an `IndirectObject`.
This is a follow-up commit of fece5ab1bf2fef043b131f1bd0886f0841116103
closesodoo/odoo#53269
X-original-commit: 189a0b28ec7fdb7472f936450cfd7b4bfd6912ed
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
This reverts commit c43647f085a7f62c9c81db6553be6a6e402943d0.
That change was not tested properly and can cause unforeseen errors
because it has far-reaching consequences, modifying the fallback
language on all requests.
One of the consequences is an alteration of the behavior of the
translation function `_()` due to the absence of a default language. For
users with no language set, it will now translate False/None values as
False/None, rather than the empty string fallback. Code that was not
prepared to deal with those non-str translations will now crash.
Besides, 'en_US' is a hardcoded default used in many areas of the code,
and we cannot get rid of it like this, especially in a stable series.
Cfr #52758closesodoo/odoo#53273
X-original-commit: e220c5a28ecbd160be86b0ce00a7f17bcfaa816e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Prior to this commit the close button of the notification is wrongly
placed when no title is provided.
Applying this commit places the close button at the right end. This commit also
modifies the size of the buttons to btn-sm.
task-2277737
Fixes#52229closesodoo/odoo#53219
X-original-commit: caa3f1107ddaa4cdf6878f4532632a41bc710862
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When using the options 'Hide countdown at the end', only the first
canvas would dissapear and the message wasn't showing up. It was due
to a return in a loop that would cause the code to stop at that point
instead of just going to the next iteration as intented.
task-2261649
closesodoo/odoo#53218
X-original-commit: 9b5f5cfce5d2d01c8e02f231e69ab350a3178795
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The superuser is already used to check whether modules are installed
with demo data and create the notification.
It was not used for accessing the admin partner though, so in the case
where a user is logging in with the password "admin" and with no
access to `partner_admin` it's going to blow up the login process
despite no reason to.
Admittedly this is somewhat difficult to achieve in "standard" odoo,
it was only discovered because 2FA (odoo/odoo#33928) can reach this
point without having a "proper" session set up as that set up is
delayed until after the MFA step has succeeded while
`_admin_password_warn` is part of the redirection flow from the
initial login (user/password input).
closesodoo/odoo#53244
X-original-commit: d18d226084a8b47f2858d8a271886115b29d7b2f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this, it was impossible to reconcile an invoice with a credit note, as the tax_audit field's computation found two invoice lines while it expected only one, and crashed.
Note that our current tax report does still not handle all the cases properly:
- Invoices with negative lines using cash basis taxes won't work well, as we can't differentiate a credit note from an invoice using only debit and credit.
- Misc entries reconciled together with cash basis taxes on them ("faking" the invoice and payment) won't work well either, as both of them have the 'entry' type.
>> This commit is a temporary fix, essentially made to unlock customers blocked byt this issue. Another, more complete, fix is coming soon.
closesodoo/odoo#53238
X-original-commit: 8ed0ae8ba593c3b636c0b1e8d5bb41549a45a432
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Until version 13.0, ir.ui.view:postprocess_and_fields returned a tuple
of a string and a dict of field information.
With aae1d57829, it now returns a
defaultdict instead of the dict.
This dict comes from NameManager.available_fields, which is initialized
as a defaultdict. There is no apparent reason to have a defaultdict in
this place, apart from the usage in has_field.
Furthermore, using a defaultdict has a side-effect in the search_view
computed field of all the ir.actions.act_window. On a database, if you
access env.ref('base.paper_format_action').search_view it will contain
a stringified dict, and the string default_dict(<class 'dict'>, {...})
is used in place of just {...} under the fields key.
closesodoo/odoo#53235
X-original-commit: 4586d0fbf0bdd5959b274611c58df911e50f4ef2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Updating the uom_id on a product_product will eventually change also the
uom_po_id to have them belonging to the same category. Saving the update
call write() on product with a dict of two values (uom_id and uom_po_id)
As product.product is inherited from product.template, the write() on
the corresponding product_template is called but in this case 2 times
for each values. The first time, only uom_id is updated. The _check_uom
constraint is triggered and obviously failed. The uom_po_id on the
template is not yet updated.
This commit makes the sync in the beginning of write() of product.template.
Which means before calling the constraint.
This commit also makes the onchanges on uom_id acts the same between
product.product and product.template.
Task : 2197818
closesodoo/odoo#48714
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Do not construct a message by putting together translatable bits, it
makes it hard to translate (out of context) and may not work for some
languages constructing the sentences differently.
Do not try to save bits, be explict.
Clarify constructions for long oneliners.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Mimic the syntax of logging to use placeholders in translatable
message.
The main advantage is to be able to fallback on the source term if the
translation can not be formatted properly.
It is very common to have errors in translations with missing
placeholders or badly translated (ie. the source
"%(subject)s" -> "%(sujet)s").
Instead of blocking the execution of the code, fallback on source
string.
Task-id: 1853119
Issue
- Install Sales
- Enable discounts & pricelists
- Create a product
- 2 variants:
- first with "create variant" set to Always
- second set to Never
- Create a SO
- Pricelist setting "without_discount"
- Add the product with product configurator
The line price is not correct (only Always taken in account)
Cause
When the variant has Create Variant set to Never
we pass the extra money in the context.
When we have a pricelist with "without_discount"
this context is not propagated correctly and it's lost
Solution
Pass the product directly if it's not empty which
have the context set.
OPW-2246102
closesodoo/odoo#53216
X-original-commit: 68628206c5883adc614045706fcc2ea085efd252
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
On a SO, you can set a default delivery address or a default invoicing address according to the customer.
The same behavior has been applied on repair order.
opw:2277679
closesodoo/odoo#53194
X-original-commit: 5dfedd9fa452ad5a7ea5ee25209a4d31da379f2d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previously the option to choose preferred routes in the replenish wizard
was only possible when stock setting: group_stock_adv_location (Multi-Step
Routes) was activated.
Part of specification 4 of overall inventory onboarding improvement task.
Task: 2220129
Related Enterprise PR: odoo/enterprise#10719closesodoo/odoo#51676
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit makes it so products can be replenished without any other
module. This is achieved by adding a "pull" rule to the default receipt
route generated when a warehouse is created. "Pull" rule is added to 1-,
2-, and 3-step receipt routes. Previous to this commit, an additional
module (e.g. purchase, mrp, etc.) was needed for a pull rule to trigger
with the existing receipt route rules. Replenishments can be triggered
via "Replenish" button in product form, recording rules (auto trigger),
and replenishment (manual trigger).
Additionally, this commit makes it so when other modules (mrp, purchase)
that handle replenishment are installed, this additional "pull" rule is
removed from the default receipt route to prevent undesired behavior
(e.g. MTO manufacturing components magically being received from no
where). Unfortunately this means 2 undesirable situations:
1. If a user adds adds/changes rules to the receipt route and then installs
mrp or purchase then their additions/changes will be removed.
2. If a user removes either (when only 1 installed) or both of these
modules then stock module will again not be able to replenish as the
pull rule will not be re-added to the receipt route.
It is expected that these 2 cases do not need to be handled in most
cases or can be handled by advanced users.
Stock tests have also been updated to accomodate this new pull rule.
Specification 4 of overall inventory onboarding improvement task.
Task: 2220129
Related Enterprise PR: odoo/enterprise#10719
This commit makes it so having a stock.picking unlocked will no longer
make the action buttons invisible. This change is expected to make it
easier for new users to not get as confused while using stock.picking.
Buttons now visible that previously were not are: "Check Availability",
"Validate", "Sign", "Print", "Return", "Unreserve", "Scrap", "Cancel".
Additionally the "Lock" button is no longer highlighted.
Additionally, relax 'is_initial_demand_editable' restriction on 'qty_done'
in 'stock_move_line_operation_tree' so that readonly status is only
dependent on 'is_locked' status.
Note that after this change picking.is_locked will only affect things
related to its move lines, including the visibility of the "Operations"
stat button.
Specification 3 of inventory onboarding improvement task.
Task: 2220129
Related Enterprise PR: odoo/enterprise#10719
Previous to this comment, creating new products during an inventory
adjustment was not possible (within stock app, was possible within
barcode app). Now it is possible to create new products within
stock.inventory form 'product_ids'. Additionally the
stock.inventory.line tree 'product_id' will also allow creation of
new products only when there are no 'product_ids' assigned. By
default these new products will have 'type'='product' (storable).
Specification 2 of inventory onboarding improvements
Task: 2220129
Related ENT PR: odoo/enterprise#10719
Since a recent commit[1], we have a utility method in tools named
'is_html_empty' that checks whether the given html content is
void(containing only formatting tags) or not. However, the re from
this method does not consider the case of self closing tags, fox ex
`<br/>`. In such cases, the method returns Falsy value even if the
content is void.
This commit fixes the issue by considering self-closing void tags
in the regular expression.
commit[1] - https://github.com/odoo/odoo/commit/974f512f5f5d3b9f80a8c3fcde290e4f55cf1230
Task - 2267689
closesodoo/odoo#53167
X-original-commit: 0fd6c9388dc959a9b6b7828850683175edb05b9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when a user created with default access rights,
but doesn't have employee linked with user then it will generate a
traceback because if user is not linked with employee then
it will return null so due to that while rednering the template
error was generated.
So in this commit, fix the treaceback by returning default values
if the current user had no employee
closes odoo/odoo#53161
Taskid: 2262636
Closes: #51687
X-original-commit: 96de35eda1a8e6e5086eb8221e939f3f737a9a6c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Arnaud Joset