Purpose: Enhance the profile picture of
* Mitchell Admin and Marc Demo as they
are now sometimes shown in larger sizes (as in appointment).
* Joel Willis, whose picture is used on his eLearning profile
Task-2992949
closesodoo/odoo#101945
X-original-commit: d0e1360e63efca56c06fad82780ab6a96fb6f0eb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reproduction:
1. Install eCommerce and accounting
2. Go to Accounting->Configuration->Taxes, add one sale tax 15%, and one
0%. Both taxes are included in the price.
3. Go to Configuration-> Fiscal Position, create a new one “test” which
applies the tax mapping from 15% sale tax to the 0%. Check “Detect
Automatically”, set country group as Europe
4. Go to Website->Orders->Customers, set the country of the portal user,
Joel Willis, as Luxembourg. In Sales&Purchase->Fiscal Information set
the fiscal position as “test”
5. Go to Website->Products->Product Variants, create a new one
“test_tax_prod” with price 110, and sale tax 15%, can be sold, can be
purchased and consumable.
6. Go to Website->Configuration->Attribute, create a new product
attribute “test” with Display Type as Ratio, Variant Creation Mode as
Never. Create a value “a” in its attribute values
7. Go to Website->Products->Products, find test_tax_prod, go to its
variant tab, set attribute as “test” with value “a”, publish this
product
8. Open an incognito tab, login as “portal” pwd: portal, search the
product “test_tax_prod”, set the price list as “public price list”, the
price is 95.65 on the page. Add it to the cart, the price is 110
Reason: When we update the order_line, we should update the price based
on the fiscal position for the no_variant products too. However, based
on the current workflow, the price is computed in method
_website_product_id_change before an order line is created. Thus for
no_variant products, the price is not updated.
Fix: This issue is fixed in saas-15.3 by rewriting the workflow and
calculating the price through an on_change function here: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605
In v13, we don’t have this on_change method to compute the new price, so
a similar price update can be created in the cart update for
website_sale. This fix solution was created here: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
However, new price computation issues can happen when combining two
pricelists, here: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391
Thus the fix is eventually done in _website_product_id_change. Added a
new parameter to force checking the orderlines based on the domain. The
orderline is created but only can be searched based on the domain. This
ensures the price is computed correctly for pricelists and for tax.
Added fiscal position test for no variant product
opw-2856956
Fix by re-writing in saas-15.3: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605
First related fix: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
Second fix to patch for the first fix: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391closesodoo/odoo#101939
X-original-commit: 0ecf2296a8595cf4fb1ba9c5fb7dee876de0a527
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
this commit, remove the margin 0px to add a space between multiple user
avatars.
closesodoo/odoo#101933
X-original-commit: 6512e002263c23cbdffdecf7ee4f031ad7ea4c55
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Currently, the keys passed through the t-foreach for looping over the
groups has a flaw. It comes from a method that works as below:
It checks the group has a value => provide a key as group_key_{value}
if not => group_key_{i} where i is the iteration index
But the {value} is acutally just an id of some model. So in some cases,
with low ids (empty DB, tests, ...), you can run into situations where
the keys are duplicates, making owl crash.
This comit fixes the function to make sure it has no duplicates.
closesodoo/odoo#101925
X-original-commit: aadb38e259c25cea69d54c3c62b21d8e747f9b87
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Model patches are now defined using the `registerPatch` function. This
function takes an object as argument which keys match those of a model
definition.
Benefits:
+ More consistent shape between model definitions and patch definitions
+ No need to import one function to each type of patch
+ No need to repeat the model name for each type of patch
+ No need to import the original definition
Task-2998282.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#101827
X-original-commit: 7d23491b44b7372209057ea2abc565a95710b316
Related: odoo/enterprise#32136
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
A rule was missing from the copied legacy rules
Note:
`form-break-table` was not only applied for small screen but also for
other case like quick edit in Kanban.
Steps to reproduce:
* Open Project
* Select a project
* Click on the Create button => BUG
closesodoo/odoo#101930
X-original-commit: de78e8bcbbc02be9024a1dd08379306ae56b0a2a
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The way we request images for the product's extra images feature did not
work properly with the patch made by `web_unsplash` since we did not
call the super function.
It is now called properly making it work with unsplash as expected.
TaskId-3003948
closesodoo/odoo#101928
X-original-commit: da23f3ad52179c145cbf9a19db20ed6a46193f0d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The records' description in the cashmove report was showing the raw json
data, now it's showing the English translation.
closesodoo/odoo#101927
X-original-commit: bcc9b5504f84729ccb5522742a2b6404c14be2d1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When using the "Holes in sequence" shortcut on a journal
in the Dashboard, the "Create" form shows the Miscellanous Entries
journal as a default instead of the same Journal that the user
trying to fix.
https://watch.screencastify.com/v/kUorLSIHwoy97UKuDJBCclosesodoo/odoo#101926
X-original-commit: a8f9950d6d55137f9c9de15042f6cb717e4a7140
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
When saving a payment method from the `my/payment_method` page
validation is used as the type of operation. In the present
validation operations were incorrectly filtered and treated as a
payment.
After this commit validation operations are processed in the
`_stripe_create_checkout_session` function as it should.
Task - 3001168
closesodoo/odoo#101923
X-original-commit: 7f371db1af160a5e89f9476540aee35f79769068
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In the present when in a multi-company environment it is possible to create loyalty programs without a company associated to it. This cause a problem when computing conversion rates as conversion rates are associated to a company.
After this commit if no company is setted on the loyalty program then when computing the amout to deduce on the loyalty program we fallback to the env company (this is the same way the company is initially deduced on the loyalty program).
Task - 3001177
closesodoo/odoo#101922
Forward-port-of: odoo/odoo#101631
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The confirmation message for the sale order appeared twice in the
chatter: first with the confirmation and second with the posted payment.
The second message is now rephrased in order to avoid any confusion for
the user (no double payment).
task-2965158
closesodoo/odoo#101921
X-original-commit: c1faff69db2a66e249bfbc5ea77644da0957d401
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Due to a last minute request we add this store to handle a difference
between the quantity done and the `stock.move.line` sum. The remaining
of the feature (mainly javascript) should arrive soon. We do it at this
time since the previous fixes also add a store attribute, and the user
on existing deployed server will only face once the issue.
closesodoo/odoo#101905
Task: 2960983
X-original-commit: 05a2e5b7b9af58eea931dd9d80c506186e4131a8
Related: odoo/enterprise#32172
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
-Activate split order option
-Create an order with two products
-On the splitting bill screen select one product and click on
payment
-Don't validate the payment and click on back
-Refresh the page
Current behavior:
There is only one order with the unselected product
Expected behavior:
There is two orders with one product
Explanation:
When on the spliting page we remove product from the first order
to add them to a new one if they are selected but the new order is
not saved yet. We need to make the new order order on payment proceed
so that all new changes are saved.
opw-2989858
closesodoo/odoo#101903
X-original-commit: a43a9fa3178caa2a2a7d5b6dd6aff5de6409f285
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Setting the attributes `can_create` and `can_write` in views
which are not editable is useless as you cannot edit the record
in these views.
This allow to gain some KB when serving the view to the web client,
as well as making the view cleaner.
e.g. the graph view in the CRM > My Pipeline menu
Before:
```xml
<graph string="Opportunities" sample="1">
<field name="stage_id" can_create="true" can_write="true"/>
<field name="user_id" on_change="1" can_create="true" can_write="true"/>
<field name="color" modifiers="{"invisible": true}"/>
</graph>
```
After:
```xml
<graph string="Opportunities" sample="1">
<field name="stage_id"/>
<field name="user_id" on_change="1"/>
<field name="color" modifiers="{"invisible": true}"/>
</graph>
```
This revision takes the opportunity to port the `editable` concept
from the server to the web client MockServer,
in order to be able to test the removal of these attributes from the views
in the QUnit tests.
The `_editableNode` JS function added here is the translation of the
existing `def _editable_node` method in `addons/base/models/ir_ui_view.py`
https://github.com/odoo/odoo/blob/f5edde3624f4fe40f87cc7fed7dcfc4bbce1f19f/odoo/addons/base/models/ir_ui_view.py#L1282-L1301closesodoo/odoo#101902
X-original-commit: f0beddf534a57e972ac3a7bef6afa1caae1dcff3
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
- Go to Projects and find one having field "sale_line_id" set
(example "AGR - S00048" with
"S00048 - Senior Architect (Invoice on Timesheets)")
- Go to Sales -> Quotations and :
1/ cancel
2/ set in draft
3/ edit Project to "AGR - SO00048"
4/ confirm again (see attached)
- Alter Marc Demo access right to have:
Sales -> Administrator
Project -> User
- With Marc Demo, go to Sales -> Quotations and open S00048
- Try to cancel it
Issue:
Access right error.
Cause:
When canceling a SO, we remove the related SO line on the project
however the current user have access to edit SO but not the project.
Solution:
Use sudo().
opw-2959627
closesodoo/odoo#99736
X-original-commit: fab2bd4428dcfec26b644351951f0855ad98fcd9
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Install POS Loyalty
- Create a loyalty program with a coupon
- Create an order with the coupon
- Try to cancel the order
Issue:
Access error raised because have no access to POS lines model.
Cause:
During the cancel process, we are trying to get `use_count` of the
coupon, that trigger compute func `_compute_use_count` that is also in
pos_loyalty. This last one will try to find related POS lines while
user have no access to POS.
Solution:
Do sudo on coupons before filtering.
opw-2959627
X-original-commit: 503945600c15ab49700c7cf00cd61dedc554d4a4
Part-of: odoo/odoo#99736
This commit removes unecessary overrides of the Notebook component
styling in the Form and Kanban columns examples.
Additionally, it also moves the most generic styles (like responsive)
into the Notebook component itself.
closesodoo/odoo#101868
X-original-commit: c1b9905b2e17ca0fda3aeb152c2927031d1662c4
Related: odoo/enterprise#32158
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The cookies bar default templates are designed in order to guide the
user towards selecting the option that will provide the best user
experience.
This raises security concerns (see discussion in PR for details).
This commit adapts the buttons of the default cookies bar templates so
that both options are shown with the same style, forcing the user to
take a decision.
task-2800976
closesodoo/odoo#101845
X-original-commit: 32d88f47a67679b7e90fa58e25089846484b48ca
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: im_livechat, survey, utm, website_crm_iap_reveal, website_forum,
website_livechat, website_sale, website_sale_comparison
Before this commit all cookies were considered essential.
This commit makes some of them optional. It also makes it possible for
the website visitor to only accept the essential cookies.
task-2800976
X-original-commit: 9a8a9463289a7446e9be0ef62ff895feb37a4de4
Part-of: odoo/odoo#101845
Co-authored-by: Benoit Socias <bso@odoo.com>
Steps to reproduce:
- Go into settings > Configure Document Layout
- Choose layout boxed
- set a company tagline
- click "download PDF Preview"
Issue:
The styling of the company tagline is not the same on the pdf and
the preview
Cause:
Module lxml from etree would not interpret the html the same way as
the browser. In the browser, we would have a 'p' markup inside of the
'h4' for the title. Effectively applying the style from the css
sheet. In the pdf, the lxlm module place the 'p' markup after the
'h4'. Therefore it would not receive the styling of the 'h4'.
Reproduction:
```
>>> from lxml import html
>>> html.tostring(html.fromstring('<div><h4><p>hi</h4></div>'))
b'<div><h4></h4><p>hi</p></div>'
```
Solution:
Modify the structure so we have a `<div class="h4"/>` element that does
not have this issue. In version before 16.0, a CSS hack was used
to keelp the structure the same.
opw-2846247
closesodoo/odoo#101666
X-original-commit: 5aaf60809f596f4ec3ae9c3bc4795b3044da0281
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit fixes three issues regarding the top left search input of the
Media Dialog.
First, following this flow from the website builder:
- Start the Media Dialog with no images,
=> A visual indication to guide you to use the search input is there
- Type a search query in the top left search input,
- Erase completely the search query,
=> The visual indication is not displayed again.
When [1] reworked the Media Dialog with components, it wrongly
defined the ImageSelector web_unsplash patch to load unsplash images: if
there was no query string, the state.isFetchingUnsplash variable was set
to true and never to false, therefore the component was acting as if
there was still some fetching in progress.
Secondly, pressing 'enter' when the input was focused would trigger a
reload of the window. This was due to an obscure html spec described in
[2]: "When there is only one single-line text input field in a form, the
user agent should accept Enter in that field as a request to submit the
form."
When [3] reworked the design of the Media Dialog, it added a t-if on the
second "url" input, making the form with a single input.
This commit fixes this wrong behaviour by using div elements instead of
forms.
Lastly, [3] also removed the position-fixed on the loading images,
which was preventing to modify the container height before resizing
them. This led to visual glitches before seeing the resized images. This
commit adds back this class to prevent that visual glitch.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2
[3]: https://github.com/odoo/odoo/commit/ff0b2d441252560a076a3609d81c369f0ce42d19
task-2687506
closesodoo/odoo#101788
X-original-commit: 8ce4036364de2d65921962357b11d905ca3676e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Steps to reproduce:
- Add an event product to the template order
- Create an so
- Select the template order you just created
Expected behavior:
you get a popup to configure the event
Current behavior:
There is no popup and the product event is not
fully configured
opw-2971168
closesodoo/odoo#101456
X-original-commit: 33062d9561e9cb4a680dfc36e0c8931a0647e5e8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Let's say the company use a GS1 nomenclature and a user scans such a
barcode:
`(01)11111111111113(10)xyz(30)40`
It means a product P:
- that has the barcode value '11111111111113'
- for the lot 'xyz'
- with a quantity equal to 40
The GS1 nomenclature explains that a lot consists of a prefix `10` and
of up to 20 alphanumeric characters. In the above example, we could
believe that the lot is actually `xyz3040`. To prevent this kind of
issue, the GS1 standards use a special character: the Group Separator
(its hex value is `\x1d` and does not have any visual representation).
So, when reading the barcode of the above value, the barcode reader will
detect the GS between `z` and `3` (so we know that this is the end of
the lot name).
Because GS has no visual representation, the way the GS character is
given by the scanner to the device depends on the scanner itself. For
instance, some barcode readers try to encode GS thanks to its unicode
input (as used on a Windows device): it enters Alt+0+2+9 (i.e., the
unicode value of GS). This is an issue since we filter out all keydown
events with the `Alt` key pressed.
Also, our way to interpret the barcode value depends on the device: on a
desktop device, we listen the events. As explained above, this could be
an issue (for instance with Alt+029). On a mobile device, we let the
barcode reader write in an hidden input and we then extract the written
value. There is also an issue here: the GS is not present in the
extracted string.
For these reasons, some changes are need. The idea is to let the user
lists the ways his barcode readers will encode the GS character (the
scanners often give the possibility to set a value manually.). There is
already a field for this:
https://github.com/odoo/odoo/blob/320025ee630acadd4a5cbd32f425cddee4f81c1e/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L18-L20
However, this is not correctly working. Suppose we now stop to filter
out the `Alt` keys: in the above example, the scanned value becomes
`011111111111111310xyzAlt0293040`(as you can see, there is an `Alt029`
at the end of the lot). Suppose also that we defined
`gs1_separator_fnc1` with `Alt029`. When parsing the barcode value, we
have:
https://github.com/odoo/odoo/blob/1c0dec6d5813fa81a0fec8668ee13d8036cde5c5/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L91-L98
So, when we try to extract the lot name, the values will be:
- barcode: `10xyzAlt0293040`
- regex: `^(10)([!\"%-/0-9:-?A-Z_a-z]{0,20})(?:(Alt029))?`
And here is the issue: `Alt029` will be caught by the second capturing
group of the regex (instead of the third one), so it will be considered
as part of the lot name, we still have an issue => considering the
`Alt`/`Control` keys and defining some values in `gs1_separator_fnc1`
are not enough, we need to parse twice:
- The first parsing is used to convert all occurrences of
`gs1_separator_fnc1` into the hex `\x1d`. Then, it is also used to
remove all useless `Alt`/`Control`/`Shift`.
- The second parsing is the already-existing one and this parser is
already able to catch all `\x1d` as group separators:
https://github.com/odoo/odoo/blob/1c0dec6d5813fa81a0fec8668ee13d8036cde5c5/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L90
For the mobile device, it means that the users will have to define a
special character that stands for GS (e.g., `#`), so we will retrieve it
in the input.
OPW-2930873
closesodoo/odoo#99730
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Part of task-2998139
closesodoo/odoo#101834
X-original-commit: 5900068e1de250284c11ee14b3642ba3d31d2583
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The widget was squeezed and not taking the whole width it was supposed
to.
closesodoo/odoo#101830
X-original-commit: f57a5cce1e50aaaadcede3e5165df9cc999323d0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When selecting multiple employees, the time off type was not
automatically reset and would show time off types not available (due to
missing allocations) to some of the employees.
task-3002165
closesodoo/odoo#101829
X-original-commit: fbafe1992865a8ba492cc43bab17ae68df9eb994
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since [1] when BS5 was introduced, vertical dropzones sometimes push row
children to the next row.
This commit removes the padding of the vertical dropzones, that was
introduced by BS5 because they most of the time are direct children of
.row elements.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2993565
closesodoo/odoo#101824
X-original-commit: 7d4cde7d2813284624ed3c651a3bd10df76ea999
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Previously, it wasn't possible to add fields to the form
using the web editor on the apply page.
This commit also set the "job_details" field on the hr.job
model as a translatable field.
Related commit: 0a8c3e7451
task-2990154
closesodoo/odoo#101808
X-original-commit: af4c7188a6928a033d0a4ef30f759049d8c59a8c
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The quantities on l10n_it_edi can be positive or negative.
Since the government disallows negative quanities, the xml template
specifies the quantity as absolute. The unit price is calculated, and
will be calculated correctly regardless of whether the quantity is
positive or negative.
This constraint can be removed as it is no longer required.
The check being removed was introduced in the commit: d643164
The fixes that allowed for negative quantites in this context were made
in: 2eb72e24fdc2c21075e188d9c62ba3bc6b416805
which was part of the PR: https://github.com/odoo/odoo/pull/97907closesodoo/odoo#101806
X-original-commit: 806266fe00de2fb0ce85f8cc603434dbc7b2a1d5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
The changes introduced by [commit 1] broke the getSelectedVariantValues method
when using the optional products modal with a preconfigured variant. When the
variant is preconfigured, the variant selection form is not rendered. As a
consequence the VariantMixin fails to retrieve the combination used when
calling getSelectedVariantValues.
In v14 this problem was solved by including an element in the DOM containing
the attribute value ids in one of its data attributes. Restoring this element
and the associated logic for retrieving it solves the problem.
[commit 1]: https://github.com/odoo/odoo/commit/2b832269f474d9b08c7c6cd827e5f78ebcfafeca
opw-2722176
closesodoo/odoo#101843
X-original-commit: 2959641fcee0c599162ed6b1dfc8efebd0c9211c
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
On the invoicing, the subtotal/total element is misaligned due to the
nesting inception of groups. This commit forces to push the element to
the end (`right`) of the line.
Steps to reproduce:
* Go to Invoicing
* Select an invoice => BUG
closesodoo/odoo#101835
X-original-commit: 27119175d89fbb874967816886eced80cf4b22bb
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since the merge of the CSS Grid system in form view, in form view where
there is a "subtotal", it was miss aligned.
In this commit, we fix two point:
* we use the following CSS rules to don't be impacted by the
`float: right` elements (e.g. "Coupon Code") and to push all element
to have the space between.
```css
.o_field_section_and_note_one2many ~ .row.o_group {
clear: both;
justify-content: space-between;
}
```
* we modified the form compiler (group) to not add layout/positiong
CSS rules on the empty `clearfix` element from the ARCH. As before this
commit this `DIV` was also used for the formula to spread the size on
the children of a group.
Steps to reproduce:
* Go to sales
* Select a quotations => BUG
X-original-commit: cdc00b03b77cc08bde14ffbc9e6867650f316ea3
Part-of: odoo/odoo#101835
We don't we to add padding on the listview embedded in a form view.
So we have added a `:not(.o_field_x2many_list) > ...` on the original
rule to avoid adding these padding on `o_field_x2many_list`.
Steps to reproduce:
* Go to Sales
* Select a Quotation => BUG
X-original-commit: c016560b6b199f00e0d248025a81be02caddff54
Part-of: odoo/odoo#101835
Since the `Many2OneAvatarField` field was rewritten in OWL component,
there is a newline between the image and the input.
We apply a `d-flex` on the parent to fix the problem.
Steps to reproduce:
* Go to Helpdesk
* Select a ticket
* The field `Assigned to` is on two line => BUG
X-original-commit: 1c88a43a4332ea4fa21ae2b04fdb8869300250d8
Part-of: odoo/odoo#101835
On large screen, the sheet in form view has too much space around.
This is due as the `max-width` was set to the `width` of the `XL`
container and not the `XXL`.
Note the size in `$container-max-widths` are:
* sm: 540px
* md: 720px
* lg: 960px
* xl: 1140px
* xxl: 1320px
Steps to reproduce:
* Open a form view with a sheet => BUG
X-original-commit: 27450c9c5d76fee9922a4625f5129b91976a6c55
Part-of: odoo/odoo#101835
This commit restores the highlight on the row when we navigate with the
keyboard.
Note we use `:focus-within` to maintain the highlight when we are in a
sub element of the row (e.g. `th`, `td`, some sub `div`, ...)
Steps to reproduce:
* Open a list view
* Use the keyboard to navigate => BUG
X-original-commit: 277fbfadd03133187b6d015f996e5197db5da5b1
Part-of: odoo/odoo#101835
Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.
This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.
It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.
What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.
Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).
Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.
Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
differentiate essential and non essential cookies and to allow user
to accept only one or both (task-2800976).
Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
The German law about this
Closes#83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)
Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt
closesodoo/odoo#101826
X-original-commit: b06ce21eba6388ce34bbffffadcb489f0e8557dd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some overrides of search might allow to sort on non sortable fields like
my_activity_date_deadline on crm_lead. An option allow_order was used
to indicate that to the legacy list view. The new list view introduced
with https://github.com/odoo/odoo/commit/bc0a0cead62edd1e0b299fb9a90cd21792814618
no longer consider that option and consequently the Pipeline list view
of crm can now longer be sorted by my_activity_date_deadline. The same
happens in some other views.
In this commit, we reintroduce the use of that option in the list view
and fix that problem.
closesodoo/odoo#101837
X-original-commit: 52481d55ef857ffc1004d27216cbf6b81a527b14
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Pierre Rousseau