Steps to reproduce:
- Create a SMS template with the 'Applies to' property set to
Transfer (without this the action will never appear)
- Go to Transfer, pick one, open action and try to send a SMS
Issue:
Traceback
Cause:
When sending the SMS we try to modify the 'mobile' attribute of
'stock.picking' but it doesn't exist.
opw-3286153
X-original-commit: c84f952824bea4c1e0d5dcc7450d5e48a5637db8
Part-of: odoo/odoo#123716
Before this commit, the attendance and non-working days were
always based to the current calendar of the user's employee.
This is not accurate since we can see other's calendars and
contract changes can lead to calendar changes (from full-time to
part-time,...).
This commit base that view on the viewed employee contracts so that
even a contract change is correctly viewed.
task-3060722
closesodoo/odoo#121153
Related: odoo/enterprise#42125
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behaviour:
In the context that a variant is being archived after the removal of
one of it's attribute lines, on the e-commerce product's page of
said product some of the attribute values are disabled because they
were part of the archived variant.
Expected behaviour:
Archiving a variant due to removal of an attribute line shouldn't
disable the selection of the other attributes on the e-commerce
product's page of the product, since the variant can never be
reconstituted (the current selection of attributes lines is `X-1`,
where `X` is the number of attribute lines of the archived variant).
Steps to reproduce:
- Install eCommerce,
- Create a product with 2 attribute lines and add values A1,A2 and
B1,B2 respectively, 4 variants should be created (cross-product).
- Go on the e-commerce product's page of the product, add the
variant A2,B1 to the cart
- Go in the backend, delete attribute line (B1,B2), from the product
template
- Go back on the e-commerce product's page, the option with A2 is
disabled.
Reason for the problem:
When deleting an attribute line from a `product.template`, if one of
the variant is being used somewhere (in our case as a `sale.order.
line` of the cart), it is archived instead of deleted. This means
that when loading the page of the product with send the attribute
values of the archived products, so we can disable the selection of
the attributes that would make the archived variant. Since A2 is
part of the variant A2,B1 that was archived, we disable the
selection for A2, without taking into account that we don't have the
same number of attributes than the archived variant and it is
impossible to make the archived variant from the e-commerce
product's page.
Fix:
Restrain the condition that checks for which attributes to disable.
We make sure that we have *any* common part of the selection to the
archived variant, and we also make sure the count of the attributes
for the product is the same as the archived variant we are checking
against.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3329225
closesodoo/odoo#124536
X-original-commit: 411441861a3242fddce5ffd02b09cbc5556aef90
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
When the product sold has a zero price,
it is possible to click the "Confirm Order"
button several times.
This will send several confirmation emails.
Cause:
Because the price is zero,
we do not have a widget that handles
the `disabled` attribute of the button.
This is handled by a widget
when we have the `o_payment_checkout` form,
but it is not the case when
selling a zero price product.
Solution:
Change the attribute of the submit
button when submitting the form to prevent
multiple click.
opw-3246935
closesodoo/odoo#124519
X-original-commit: 53c6ebfdf7c5acb5103bf9ef5cb7c12f92ceefb9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Send a request to any json-rpc route with a HTTP header
`Content-Type: application/json-rpc` but send non-json or
non-jsonrpc data in the body. The application crashes with
a 500 Internal Server Error instead of a 400 Bad Request one
closes odoo/odoo#124571
Closes: #122048
X-original-commit: a1b83b07996f3fe4744474ff4023a3a2ce17ac7f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit, when the user set a subtask and wants to directly
set the SOL of that subtask in the subtree view of a task form view. He
cannot because the field is in readonly.
This commit makes the field editable if the user has access to Sales app
as it is the case for the SOL field in the form view of task.
task-3336215
closesodoo/odoo#124563
X-original-commit: 0373abdf24e1139706e6d7610873cc89ada60e74
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Allow timesheeting on sub-tasks with no project_id set.
Instead, refer to the project_id set on its parent_id, and so on,
recursively.
task-3336215
X-original-commit: d794e41619a36a8c9ad1e77a816e57051207cdcf
Part-of: odoo/odoo#124563
This is a proposal to try to find a similar asset before generating one.
If get_attachments fails, the next step will be to generate the
attachments from scratch, a slow operations.
When creating a new website, all assetsbundle would actually be
similar to their version without website, but the url is different.
This can be visible because the first loading of /web is slow after
creating a new website: the website_id is forced in the session
and the assets_backend are regnerated, identical to the original ones.
This commit proposes to try to find an attachments with differents extra
but the same uniquifier when possible and copy it's content.
Note that just returning the other attachement url may work, but it
would be confusing to randomly have links to assets comming from another
website_id. This would also be a problem if the original attachment is
unlinked, forcing to recompute it for other websites.
Good to know, since the content is the same, no duplication of the
content should appear in the filestore, just an entry in the database.
Part-of: odoo/odoo#121376
1. move cache to _get_asset_paths
The `_get_asset_content` cache has many cache key that are related to a
posprocessing of the `_get_asset_paths` result, the heavy part of this
method. Moving the cache to _get_asset_content will have the benefit
to create less duplicates entries in the ormcache as well as less cache
miss.
To simplify even further, the css and js parameters are removed since
they only filter the output of get_paths, the heavy part of globing the
file will be done before that. Anyway, they are both true when called
from _get_asset_content, and the only other call, in
`_get_related_bundle` don't really need to filter them since it is not
a critical part regarding performance, and the funtional result will
stay the same.
The initial orm cache key was using `_get_template_cache_keys`, a little
overkill and possibly creating duplicates entries again. The only
context key needed is website_id for `_get_related_assets`.
Note that it is not really enough, the orm cache key should actually
contain `request.session.get('force_website_id')` as well has
`request.httprequest.host`. This will be addressed latter since a nicer
solution would be to have website_id as a unique parameter computed
earlier.
2. better _get_asset_paths cache key
The orm cache key was simplified in previous point but there is still
one concern, the website_id depends on more parameters than that:
- request.session.get('force_website_id')
- request.httprequest.host
- existing websites
The idea here is to call `get_current_website` instead of using all
parameters that could define the webiste.
In the same spirit of `_get_template_cache_keys` `_assets_path_params`
can be overriden to give extra params that are usefull to list assets
path. Those params are computed before entering the method
`_get_asset_paths`. This may latter put at a higher level latter, in
get_asset_node, to simplify the _generate_asset_nodes_cache key.
3. better assets_node caches key
The main purpose of this part is to improve ormcache containing assets
nodes. The ormcache key contains
- to much context key
- missing session/host/env info
- unwanted boolean options.
- keys leading to the same cache value
The main goal being to reduce the size of the cache keys, decrease the
number of cache entries and improve the cache hit.
This will also make the behaviour more coherent and hopefully less bug
prone because of mismatch in parameters.
The main reason of the orm cache is the slowness of the validation of
the assets. This includes:
- listing files (dedicated orm cache)
- computing version
The cache key was depending on
- `debug`
The only relevant value for debug is "contains assets"
We dont need to differ between debug='', debug='1', debug='test',
and 'debug=assets', 'debug=tests,assets', ...
- `defer_load`, `lazy_load`, `media`
Those values are only useful to generate html node, a leightweight
operations that does not really needs to be in cache. `media` was also
used in the generation but it looks useless if we have the media on the
node. THIS NEEDS TO BE VALIDATED but in any case, since media is not
used to generate the url, it doesn't make sence to use it in the
generation.
The main idea to remove them from the ormcache key is simply to generate
the nodes outide the ormcached values.
-`async_load`
This one is similar to `defer_load` and `lazy_load` but it looks like
it wasn't used anymore. This was simply removed
- context.get('lang')
The only information needed is the direction, rtl or ltr. This means
en and fr languages, despite sharing the same css assets, will duplicate
the ormcache entries.
-`_get_template_cache_keys`
Only the lang and webiste where really relevant in this flow. Other
keys are actually useless in this flow.
Some information used in the generation where not in the orm cache key
- `self.env.user.lang` if there is no lang in the context
- `request.session.get('force_website_id')`
- `request.httprequest.host`
- ...
The proposed solution is to:
- extract any informùation needed from thecontext, request, environment
before entering the ormcache, reduce it to the minimal possible set of
values needed
```
rtl = self.env['res.lang']._lang_get_direction(self.env.context.get('lang') or self.env.user.lang) == 'rtl'
assets_params = self.env['ir.asset']._get_assets_params() # website_id
debug_assets = debug and 'assets' in debug
```
and remove a leightweight part of the logic
```
def _get_asset_nodes(self, bundle, css=True, js=True, debug=False, defer_load=False, lazy_load=False, media=None):
links = self._get_asset_links(bundle, css=css, js=js, debug=debug)
return self._links_to_nodes(links, defer_load=defer_load, lazy_load=lazy_load, media=media)
```
Where _get_asset_links is the cached part, and _links_to_nodes is the
lightweight part generating the nodes based on the `defer_load`, ....
Additionnal notes:
- data-asset-version and data-asset-bundle are removed from the node
since they don't seem to be used anymore since 65d70acdbf
- async_load is removed since there is no occurence of this in the code.
- a small hack is still needed to pass javascript content instead of
links, this is only to manage css compile error and will hopefully be
removed in the future.
- a context key is still in use to generate the bundle, the
`commit_assetsbundle` but it has no impact on content and will hopefully
be removed in the future.
4. Add test for ormcache hit/miss
In this context, hit/miss is about having the same cache key for the
same result. This test demonstrates the current state, were entries are
create in the ormcache only if the key is really different and will lead
to a different result.
5. remove cache invalidation
This cache invalidation is quite agressive since everytime an
assetbundle is updated, all workers will clear their cache.
The concerned cache by this clear_cache is `_generate_asset_nodes_cache`
throug `_get_asset_nodes`.
The cache is ignored, both in dev=xml and debug=assets.
This clear cache was made conditionnal in 553ea82f81 but this does
not solve an issue we can have in production.
Lets imagine a clean solution
- all sources are updated
- all workers are restarted.
The orm caches are all empty, but since the sources
changed, all bundles will be recomputed. This means that every bundle
updated in database with save_attachement will invalidate the cache of
all workers. Rendering a pdf report of any kind using a specific bundle
will invalidate all cache. Starting a debug=assets for the first time
will invalidate all cache, even if the cache is not used in this case.
But for a regenerated bundle we would expect the ormcache to be:
- empty (did not generate the same bundle yet)
- have the same value (concurrent generation of the same bundle)
Having a different value would mean that the bundle was generated with
another version of the sources. In this case it is maybe even better not
to invalidate the cache since it could lead to an invalidation war
between two workers.
The only case where invalidating this cache is useful is when a bundle
changes, Usually if an ir_asset is created, modified, ...
There is still another rare but possible possibility to have a 404 if
the transaction is rollbacked after populating the assets node cache.
In this case, we only need to clear the cache locally in case of
rollback.
Part-of: odoo/odoo#121376
The confirmation dialog component uses `t-esc` thereby preventing the use of markup for the body prop.
With this commit, we use t-out instead and thereby allowing markup.
The same applies for the AlertDialog
[IMP] web: enhance extensibility of form/list confirmation dialog when deleting records
To extend the functionality of the delete confirmation in the form and list controllers, a lot of code has to be copied.
This commit separates the props into a getter, making it easier to be extended.
closesodoo/odoo#124553
X-original-commit: 6179d1d7928407a3199db48f0489ce645084d5aa
Related: odoo/enterprise#42310
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When user change the move_type of account_move to 'entry'. And when user try to
access 'partner_credit' field from the form view using debug mode.
The error will be generated.
Steps to Produce:-
1. Install 'account_accountant' and 'sales' module
2. Change move_type of account_move to 'entry'
3. Go to 'Edit View : Form' of Journal Entries in account_accountant using
debug mode
4. Add field 'partner_credit' to the form or tree view and click on save
5. Click on any Journal Entry
Trace-back will be generated.
Applying these changes will resolve this issue.
Sentry-4222621594
closesodoo/odoo#124515
X-original-commit: 94c1f20aaeb89cc07bb21cab2e19da67fd10f603
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
Emails on Sale Order, Invoice, Recovery cart. When no sales on sale.order
use "COMPANY" <email of company> as fallback before the current user.
Reason is that odoobot is often used in automatized actions and having
it as email_from is not really user friendly.
Also add company fallback in auth modules email templates (if not already
using it) for the same reason.
Task-3346388
closesodoo/odoo#124472
X-original-commit: 597fc004148bf39e8f56e36e840aa6788872f237
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, the field incoterm_id is defined
twice in purchase.order model, i.e., in purchase and
purchase_stock modules
after this commit incoterm_id field is removed
from purchase_stock module
closesodoo/odoo#123602
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Avatar didn't sync when changed due to miss reading the cache key.
Part of task-3265211
closesodoo/odoo#124466
X-original-commit: 58fea4c78e11176bac609f89476fec8cd9fdb5df
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In several places, `convert_inline` uses `classList.toggle('c', true)`
to set classes. This is not a good practice, as it's not clear what the
state of the class is. It's better to use `classList.add('c')` since
this anyway checks whether the class is already present or not.
closesodoo/odoo#124465
X-original-commit: 43afc5a5a30530bc3ede9f0a46249977a7896b5a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Outlook needs explicit dimensions for images, which .img-fluid - by
design - doesn't provide. This puts them in mso conditionals with said
dimensions for Outlook.
X-original-commit: d0949de8ce895b7da5fd128fb5d72d23d5634866
Part-of: odoo/odoo#124465
Before this commit, the main image of the newsletter template had a set
width which doesn't do anything because it gets overridden by CSS, but
it confuses the conversion process.
X-original-commit: c23fe6dc5efe46990a5473f696966a2774ae16d4
Part-of: odoo/odoo#124465
The `_wrap` util function of `convert_inline` was not checking if
`className` and `style` were defined before adding them to the wrapper
element, leading to things like `<div class="undefined">element</div>`.
X-original-commit: 9fd6e069d07c3f7964511af7289d95c970d11b3e
Part-of: odoo/odoo#124465
This ensure the layouts of emails don't get distorted in Outlook when
the user is using DPI scaling (typically, some elements get scaled up
while others don't).
X-original-commit: 2348efb6e22544d82ce53d542975f334d5553f62
Part-of: odoo/odoo#124465
Firefox doesn't seem to do well with sibling tables, so we need to
wrap them each in separate rows.
X-original-commit: 625a6545ee9e64a90e36b676c5b7b9a3c8d42418
Part-of: odoo/odoo#124465
Bootstrap rows have negative left and right margins, which are not
supported by GMail and Outlook. Sometimes we use padding on columns to
undo the negative margins of their child rows. This corrects these.
X-original-commit: dc7c7330b4b7a1c17c3b736aa60c21882a455a31
Part-of: odoo/odoo#124465
Before this commit, the line-height of the body was not properly
inherited where it should. It is defined as a CSS variable and its value
was incorrectly retrieved (if the value is 1.5 and the font-size is
10px, `getComputedStyle` returns 15px instead of 1.5). Other properties
related to fonts were likewise improperly inherited.
X-original-commit: 12ae698bd9aff8466d69819e0b849752f967c126
Part-of: odoo/odoo#124465
This addresses a series of alignment issues in the conversion of html.
X-original-commit: 5b5a0030f8cd75f0a977d7804b54dc454a6a8751
Part-of: odoo/odoo#124465
This addresses a series of issues regarding images, their responsive
behavior and their alignment.
opw-3244705
opw-3185231
X-original-commit: e20bc14e8860ce8f84eb5b0006ec67b708530161
Part-of: odoo/odoo#124465
Base64 images get converted to attachments. However, if they are in a
mso comment, they were not converted.
X-original-commit: 2fa0694227a7beb6a000c2e8219fdd8c073cf348
Part-of: odoo/odoo#124465
Prior to this fix, elements with background images were converted to
images via the html2canvas library. This made them work in Outlook at
the cost of several tradeoffs:
- the process was slow and asynchronous
- there could be no interactivity (links, buttons, etc.) in the
converted element
- responsive behavior was wonky: if only a slice of the image was shown
when it was converted (due to background-size cover behavior), the
rest was lost so if more width was needed in mobile, we would be
zooming on that slice, making it sometimes irrelevant and pixelated
This replaces all that with a conversion to VML, which is a vector
format supported by Outlook. This conversion is done only for Outlook,
which means that all other clients are getting the original background
element again.
There is a way to keep the background-size cover behavior in VML, using
the "aspect" attribute with value "atleast" but this only works on
v-fill elements and sadly putting the image on a v-fill element bugs in
Windows Mail (which is the default mail client on Windows 10 and 11) and
this client can't be singled out of mso conditionals. To get around this
issue, since this is only for desktop clients, we assume the width of
the screen to be large and mimick the cover behavior by cropping the
image to the target size. This allows us to put the image on the v-image
element and have proper rendering in Outlook and Windows Mail on
desktop.
Note:
When retrieving the image by URL in Python in order to crop it, we need
to ensure we have an absolute path. This is done - perhaps seemingly
naively - by checking if the URL contains '//'. Here's the reasoning
behind that choice. To check if a URL is absolute, we could use
`urllib.parse.urlparse` and check if it has a scheme but that would lead
to `www.odoo.com/path` being considered relative (and thus we'd add a
host to the URL even though there's already one). Instead, we could
check it it has a netloc but that would lead to the same issue since the
documentation of `urlparse` says:
> Following the syntax specifications in
[RFC 1808](https://datatracker.ietf.org/doc/html/rfc1808.html), urlparse
recognizes a netloc only if it is properly introduced by ‘//’.
Still, it would be more technically correct since `//some/path` would be
considered absolute (which it should be since it resolves to
`<current_scheme>//some/path`).
Base on that documentation, it seems that simply checking if the URL
contains '//' is pretty much equivalent to checking if it has a scheme,
with the double advantage that it's simpler and that it works for
`//some/path` as well. However, note that it doesn't solve the issue of
`www.odoo.com/path`.
In summary, here are the results with the current method:
```
http://www.odoo.com/path -> http://www.google.com/path // OK
some/path -> http://localhost:8069/some/path // OK
/some/path -> http://localhost:8069/some/path // OK
//some/path -> //some/path // OK
www.odoo.com/path -> http://localhost:8069/www.google.com/path // WRONG
```
X-original-commit: 9561ba31917024825705c876442139405e7a7957
Part-of: odoo/odoo#124465
Several issues were found regarding the responsiveness of columns,
especially in the Masonry snippet. This implements a new, more robust
approach to responsiveness of columns, based on article [1], where each
column is wrapped inside a new table, itself wrapped in an inline-block
div element, and all adjacent wrapped columns are in turn wrapped in a
common table cell:
```html
<.container>
<.row>
<.col id="A">
<.col id="B">
</.row>
</.container>
```
becomes something like:
```html
<table>
<tbody>
<tr>
<td>
<div style="display: inline-block;">
<table>
<tbody>
<tr>
<td id="A">
</tr>
</tbody>
</table>
</div>
<div style="display: inline-block;">
<table>
<tbody>
<tr>
<td id="B">
</tr>
</tbody>
</table>
</div>
</td>
</tr>
</tbody>
</table>
```
with some additional attributes and styles to make it work.
[1]: https://www.litmus.com/blog/mobile-responsive-email-stacking/
task-3184107
X-original-commit: 3ddba4dbd57891c2d9fc80fb7aa0dd08338fe3f6
Part-of: odoo/odoo#124465
Conversion of some masonry grids caused unexpected responsive behavior,
leading to a result that didn't match the edited design. This was caused
by a few separate issues:
1. Sometimes Masonry declares rows with a height of 100% but with
columns that overfit the grid. In these cases, we split the rows into
multiple rows but we failed to adapt their heights for them to be
divided equally.
2. A call to `setProperty` failed silently, making it so the height was
never set on certain rows.
3. When converting background images, we failed to remove their padding.
4. Bootstrap grid media queries were only inlined from the xl breakpoint
and up, but the snippets typically use the lg breakpoint.
5. The "o_desktop_h100" class was not applied to the parents of
`.o_desktop_h100` cells, making the rows too big for their cells in
mobile.
6. A combination of the above made the conversion fail when the masonry
snippet had a non-automatic height.
task-3184107
X-original-commit: 04d1c0caeb78ee3bedff579e229e5da47c2689ce
Part-of: odoo/odoo#124465
This adds two util functions, to create mso and !mso comments (which can
be error-prone).
X-original-commit: e258a28aa147db97eab1d3dc5db3595adf91541c
Part-of: odoo/odoo#124465
This addresses a series of issues with mso conditionals that were not
closing in the right places.
X-original-commit: 247e05a9cca403fca3de01feb49d0f0374ea38de
Part-of: odoo/odoo#124465
account_peppol module currently doesn't have any tests.
This commit adds tests to test the participant,
sending and receiving peppol messages, peppol functionality in the
send and print wizard.
task-3321786
closesodoo/odoo#124436
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
In case of error, the send & print wizard is crashing or log an error on the invoice chatter.
In that case, nothing is sent to the end-customer.
This is problematic for all flows in which we want to send a mail to the customer automatically.
For example, e-commerce with automatic invoicing or subscription/recurring invoices.
To avoid that, the current logic of the send & print has been reshaped. In case of error, a proforma
PDF is sent instead. This is exactly the same document as the PDF but without the legal layer.
To do that, a lot of refactoring has been necessary to always provide the cumulated data for invoices
to be able to access the generated proforma report and to allow the overrides to know exactly in which
mode the hooks are called.
Also, this commit renames the method by something less generic about invoices. Indeed, this wizard needs to be
usable for others documents than invoices. That's the purpose of the invoice_single/invoice_multi mode.
For that reason, all methods about invoices are now expricitely prefixed by 'invoice'.
Fix also a performance issue on multi-invoices since the invoice_pdf_report_id document was invalided for the
whole model instead of the current record. When dealing with X invoices, the whole model was invalidated X times.
Fix the managment of attachments:
- The manual attachments wasn't send when sending a mail 'invoice_single' mode.
- When changing to another mail template, the manual attachments were lost.
Fix the double generation of PDF using a web-service.
When opening again the send & print wizard, the PDF must not be regenerated but reloaded from the previous one.
Task: 3339352
X-original-commit: e9e90811aeee46989a83b21f9b59071a9c7bc362
Part-of: odoo/odoo#124436
=== ISSUE ===
If you navigate to Project > Task > Gantt view > magnifying glass
and select some items, the arrow inside the `unselect all` component
is not aligned with the text.
This is due to the fact that the `.oi-large`
class uses a CSS variable called `--oi-vertical-align` which aligns the
icon a little bit under the middle.
=== AFTER ===
We add a `.align-text-bottom` class to the icon in order to align
the icon with its label.
task-3338235
part of task-332626
closesodoo/odoo#124433
X-original-commit: 0c33fcbd7ccad15179e9873cce04272cf0ec0b48
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
*: account, base_import, board, website
This PR enhances the "cog menu" by fixing several UX flaws.
Notable improvements include:
- Reordering entries in a more logical manner, enhancing user intuitiveness.
- Assigning icons to common actions for quick comprehension.
- Grouping both print actions and module-specific actions for better organization.
Enterprise:
- https://github.com/odoo/enterprise/pull/41851
task-3337951
task-3355224 (milk post-merge fixes)
part of task-3326263
closesodoo/odoo#124413
X-original-commit: 596772885a87016d29f002cd4e41b5a973965e40
Related: odoo/enterprise#42212
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
How to reproduce the bug
========================
-> Try to preview some documents like (Employement Contract.pdf or Odoo CLA.pdf).
-> Preview is broken.
Technical
=========
"application/pdf;base64" mimetype was not included in the isPdf() so the
method was returning the false value.
After this commit:
==================
Now the PDF containing this mimetype are previewable.
Task-3305415
closesodoo/odoo#124412
X-original-commit: 698d51fa56be47eb108cec299b12a3f6b58058b9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create an invoice
- Send it using sent & print
- Re-open the wizard
- Click on 'Cancel'
=> The PDF has been deleted.
This is because we want to remove the attachments manually added by the user but the condition to do it is wrong.
closesodoo/odoo#124345
X-original-commit: 26e95e1eb906d6770016a80c39c79eb2be03c1f6
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
We make the class DisplayNameRepository use the name service instead of
BatchEndpoint. This makes the code simpler and allow to avoid a lot of
rpcs (in some occasions) when fetching display names.
closesodoo/odoo#124090
Related: odoo/enterprise#42124
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
The method getDisplayNameAsync being no more called, DisplayNameRepository
has no need to manage deferreds. We simplify it.
Part-of: odoo/odoo#124090
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
We define a new service "name". That service makes possible to load in
batch display names and maintains a cache. Some known display names
(fetched otherwise) can be added to the cache. The cache is cleared at
least each time the UI is updated via _updateUI (action service).
Part-of: odoo/odoo#124090
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
Before this commit, the Product (backend link) is not readable to the community
and in the enterprise, it's not matching with the rest other backend links
(blueish) (e.g. New) due to the default text color. Same way TRANSLATE button
have visual glitch for community and enterprise.
After this commit, the backend link is readable for the community and matches
with others in the enterprise version by using `$o-navbar-entry-color`
task-3346020
closesodoo/odoo#124455
X-original-commit: 154be2e2f673c039e62e148e7b2c05304af6b568
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When user tries to quick create a field where model is not specified, the error
will occur.
Steps to reproduce:
1. Turn on developer mode.
2. Go to Settings > Technical > Fields Selection.
3. Create a new record and quick create a field.
Traceback will be generated.
Applying this commit will fix this issue.
sentry-3956146718
closesodoo/odoo#124442
X-original-commit: 9e64211eb4398b25c57d73bc5a92eda88d314bd1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In Odoo editor when a html field is empty, we add en empty <br> inside the <p>.
This change broke all if statement checking that company details is empty.
In this commit, we add a function is_empty_company_details that return True if
the company details field contains only a <br> and False otherwise. With this
method, we can check that company details is empty and displaying other thing
that just an empty line break.
closesodoo/odoo#124440
Task-id: 3168705
X-original-commit: 2aaca9afb6c54be3ef87ea38646af90a2599aa6b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Before this PR, when multi vat was activated and a foreign vat number was set on
a fiscal position it was not printed on the invoice for the following layout:
Striped, light and boxed. The Bold layout is not impacted since it does not use
company details.
This PR adds the foreign vat on the invoice when it's necessary.
Task-id: 3248767
X-original-commit: 181bd158d149530d085b6da7e1c5ca3003f36bd3
Part-of: odoo/odoo#124440
Eteil Djoumatchoua(etdj)