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>
PURPOSE
With this commit you can now see how the mailing you're creating
will look like on a mobile.
LINKS
Task-2818037
closesodoo/odoo#101822
X-original-commit: 2b195390e15c9ed3b54f0adf0afc439f06429616
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Tests adaptations will come in a following PR, but the current focus is set on owl conversion.
task-2936932
closesodoo/odoo#101500
X-original-commit: 78e15be0b58c0c964f1df79e95f17fcf72480a5b
Related: odoo/enterprise#31970
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This is an oversight in odoo/odoo#100130
A modifier set with `context.get('...')`,
for instance
`invisible="context.get('sign_directly_without_mail',False)"`
takes priority on attrs
only if the result of `context.get('...')` isn't falsy
e.g.
https://github.com/odoo/enterprise/blob/1a4e4fafe4fc78dab0aad7ab6241a6f4a7be317a/sign/wizard/sign_send_request_views.xml#L64
should return
- `modifiers="{'invisible': [['is_user_signer', '=', false]]}"`
with `context.get('sign_directly_without_mail') == False`
- `modifiers="{'invisible': true}"`
with `context.get('sign_directly_without_mail') == True`
closesodoo/odoo#101813
X-original-commit: a3dc5f5fd34671c67253c6ff36bb7c960f9170ff
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Remove the legacy hack to have fielsdToFetch working after the merge of
d2a2fd94bfcef8360805b46a1692ba7eb84fbe1c.
Add addtionalClasses of m2m tags to get the correct style.
closesodoo/odoo#101833
X-original-commit: ff4d5c1bca0b3af95d4f856ebc424f1b31ba5147
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, open an act window action asking for a tree view
would cause a crash. We fix that.
closesodoo/odoo#101831
X-original-commit: fa6fd8b079ad3347f3571654f07bf9751834654d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit replaces two usecases of the legacy FormViewDialog and
SelectCreateDialog, as we are about to remove them.
closesodoo/odoo#101819
X-original-commit: b1574ae38be45e871e505100c2342887ed7dba8b
Related: odoo/enterprise#32132
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, with its default props, the SelectCreateDialog
displayed a "Create" button in its footer, but clicking on it does
nothing.
This commit simply opens a FormViewDialog to create a new record
of the given model, like in legacy. This default behavior can still
be overridden thanks to the props "onCreateEdit".
X-original-commit: 3afaad687e8ca8cb34a7bf7121e75a5a583762ed
Part-of: odoo/odoo#101819
Before this commit, in a form view, the state selection button was
placed on the left. It should be on the right.
closesodoo/odoo#101818
X-original-commit: c5f22e1f0b8f1f0eae42666ec5732e590957e21e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a grouped kanban view, when the "delete" button
of a card is clicked, the card is deleted but a "Load more..." is
displayed in the column.
Why is this?
The group counter is not correctly decremented when the record is deleted
How to reproduce :
- Go to a grouped kanban view with a delete button on its cards
- Click on the delete button
Before this commit:
The record is deleted and "Load more..." is displayed in the record column.
After this commit:
The record is deleted.
closesodoo/odoo#101817
X-original-commit: c97551a5aac6eaa0ca3d750039a65e3e03a453da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The calendar view and all its extensions have been converted to
owl, so it's time to get rid of the legacy implementation.
closesodoo/odoo#101816
X-original-commit: 681a6a98c9919021c2f688609e5e4263a9cf4d14
Related: odoo/enterprise#32130
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current message may make you believe the date on
the invoice will be changed when it's the accounting date
This aims to clarify that the move.invoice_date will stay
the same when it's the move.date that will be changed
closesodoo/odoo#101820
X-original-commit: 5f5dbbcc66f4ded1388949386faf90e0d406a4b2
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
There are a few issues solved in this commit
1. Fetch plans is called too many times (Journal items List view). This is not necessary as plans are only required if editing
2. Plans are not fetched again if the product/account changes. This is because the record referenced by props and nextProps is the same, hence a change is not detected.
3. In list views - analytic account data is retrieved for each instance of the widget. To reduce the calls, a batched read is used instead
Improve test
closesodoo/odoo#101803
X-original-commit: 01d7579cfc8bf441f03d4467ef34a2d3bae015a4
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the "Oh snap!" dialog could be displayed anytime
a server validation error was returned by an RPC. Also, clicking
on the "discard" button in this dialog always triggered an `historyBack`
even when we open a new action.
Now, this dialog is only opened on error while saving and does not
`historyBack` anymore.
closesodoo/odoo#101802
X-original-commit: 31c6ecb7f9ad68d337cbc7f0fd3b4d682c088b85
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Use case to reproduce:
- Create a product with manufacture and MTO route
- Set the warehouse in 3 steps manufacturing
- Confirm a SO for 5 units
- Update the quantity to 4 units
Current behavior
Each picking has a quantity to 4 units. Except for the post
production to stock that still for 5 units but a return is
created.
Expected behavior
Each picking has 4 units
It happens due to `_run_pull` that will create a new procurement
group in post production location (the purpose is to avoid a merge
between semi-finished product and finished product). But in the case
of a negative procurement, we want to decrease a picking and not
create a production order. So create a new procurement group with the
next MO sequence will aslo create another issue because
`_run_manufacture` will skip the MO creation since the quantity is
negative and it will be a gap in the sequence number.
Instead of creating a new procurement group, search for an existing
in sibbling moves, so `_search_picking_for_assignation` could find
a picking to merge the negative procurement and decrease an existing
move.
closesodoo/odoo#100439
X-original-commit: c5e8adaa2b364e3ff4625e080df4c523a9673668
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Consider this case:
Template A has 2 variants: KIT and NOKIT
KIT has a total cost of 100, NOKIT costs 50
When selling NOKIT, the current code will select the bom of KIT
to calculate the price_unit of NOKIT, which means that when
reconciling the aml of the invoice (amount = 100) with the aml of
the cogs move (amount = 50), it will be partial due to the difference
in amount. This alse messes with the balance sheet report.
This fix ensures that only boms directly related to the product
or for the generic template are selected.
opw-2918080
closesodoo/odoo#98676
X-original-commit: 8ce71352886442f3a75999fe39856f82651314e5
Signed-off-by: Steve Van Essche <svs@odoo.com>
This commit improves the fiduciary mode by:
- removing message error about the change of sequence format
- suggesting the Customer Invoice / Vendor Bill date according to the following heuristic:
- Last day of the month of the most recent Customer Invoice / Vendor Bill (ignoring drafts) OR today (whichever is the smallest)
- If this date falls before a Lock Date, pick the last day of the first month that is not locked
- Examples:
- Example 1 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : March 15th 2022
==> Default New Vendor Bill date = March 31st 2022 (last day of March 2022)
- Example 2 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : March 31st 2022
==> Default New Vendor Bill date = March 31st 2022 (last day of March 2022)
- Example 3 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : June 2nd 2022
==> Default New Vendor Bill date = June 17th 2022 (today is the smallest)
- Example 4 :
We are June 17th 2022. Lock date : April 30th 2022. Bill Date of the most recent Vendor Bill : April 30th 2022
==> Default New Vendor Bill date = May 31st 2022 (last day of the first month not locked)
- renaming the invoice according to the suggested date
Task id: 2887007
closesodoo/odoo#101799
X-original-commit: 179f4f83db0d029850375012bbf80dedc6679505
Signed-off-by: William André (wan) <wan@odoo.com>
Fixup for d823033ad67702b1b92d27a3f66c7a4ec304c644
Portal user should not modify partner's name if an invoice for this partner is
already issued. However, delivery address contact may have empty name, while
eCommerce UI requires filling out the name. This blocks checkout process. Fix it
by allowing name changes, when it's not set.
opw-2981455
closesodoo/odoo#101796
X-original-commit: 781dbeaccac76a6ec4f4b8cac1b607810697e394
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This field widget is no longer used in form, list or kanban views,
so it hasn't been converted to owl. This commit removes its legacy
implementation from the registry, s.t. we ensure nobody use it
again. Moreover, we adapted a new view test using it to use another
field widget instead, to remove the dependency and ease the removal
that should happen soon.
closesodoo/odoo#101787
X-original-commit: 68cfd4b08bc9ab0305ae9033e42820370b52bdf3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In debug, we want to see the field component description in its
tooltip. For instance, for a many2one: `Widget: Many2one (many2one)`,
`Many2one` being the `displayName` attribute of the Component, and
`many2one` the key in the registry (to use with `widget="many2one"`
in archs).
X-original-commit: 39fbb4620b5e846cd597ecbbfefdbda8bc4cb8e1
Part-of: odoo/odoo#101787
This commit brings back the Send SMS button, which was no longer
visible in form views since they are now displayed in edition by
default.
It also solves the missing enable_sms option, which was not yet
ported from the legacy implementation.
A test file has been added to the sms module to verify the presence
of the button in the view.
closesodoo/odoo#101786
X-original-commit: fdb38657904202d9bfa75817289a53596b914406
Related: odoo/enterprise#32108
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
This commit brings back the functionality to send e-mails when using
the EmailField in form views. Since they are displayed in edition by
default, the link was no longer available and the feature was missing.
A test has been adapted to assert the presence of the button.
X-original-commit: dbaa1c1083803f31d932445fed8d6324c5191c4b
Part-of: odoo/odoo#101786
This commit adds a Go to Url button next to the UrlField input. Since form
views are always set in edition mode, it was no longer possible to open
URLs by clicking on the link. Now, a button has been added directly after
the input to bring back the original feature.
Tests assert the right behavior regarding this button.
X-original-commit: e97215e78500a7b36aa0da073c767f5f96198d3f
Part-of: odoo/odoo#101786
Since form views are always visible in edition mode, it was no longer
possible to click on the phone number to start a call. Now, a button
is displayed next to the input, allowing the call to start despite
the state of the view.
Tests have been adapted to assert the presence of the button.
Enterprise PR: https://github.com/odoo/enterprise/pull/31954
X-original-commit: 4ac2f17ce6279aa745b1a930f52b86635a04753c
Part-of: odoo/odoo#101786
This PR https://github.com/odoo/odoo/pull/97805 wrongly assumed that
self contained a single workorder. This would raise an error if there
were multiple records in self.
Solution:
Modify calls on `self` to `workorder` (as we already iterate through
them)
closesodoo/odoo#101775
X-original-commit: 26cb902e603d6d576957d1d329d3eef4e76af5f8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This reverts commit 3a7349d02b6b667c890af2f197a3640d875b804e.
This toolbar being more accessible in mobile (scrolling to access all
the buttons), sadly it broke the toolbar's dropdown...
closesodoo/odoo#101766
X-original-commit: 253152d93f381ba0e55787818294aaee24383e0a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
JF Aubert