This commit fixes 3 issues with the domain in field tooltips, in
debug mode.
1) it only displayed the domain defined on the field in the model,
not the domain set in attrs in the view, if any.
2) when the domain was the empty array, `domain: ` was displayed.
3) unset values should not appear in the tooltip (invisible,
column_invisible, required, readonly).
opw 3455119
closesodoo/odoo#146563
X-original-commit: 8c4ff1fac9eb003c23770bf74f9d7ffe062f6ce7
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
Activities made on the archived record are not shown in the activity
system-tray menu.
After this commit:
Activities made on the archived record are shown in the system-tray
activity menu.
task-3458597
closesodoo/odoo#146462
X-original-commit: d6d91b4f86d3d0ef954160a9de6e42a1bc4e184f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
REMINDER: old taxes = {7.7%, 3.7%, 2.5%}; new taxes = {8.1%, 3.8%, 2.6%}
1. We created 2024 taxes in advance and made them inactive by default
to avoid confusion for our users, while making them available for those
who needed them. Now that we are about to enter 2024 its time to active
new taxes by default and deactivate outdated ones.
We are keeping outdated taxes a bit more for clients that are not closing
their accounting at the end of the year and might need them for upcoming
months.
2. Remove the activation of new taxes that was made in the module migration
since now those taxes are already active.
closesodoo/odoo#146495
Task-id: 3184792
X-original-commit: 69868b3a1e327346138835ee4c91d86a5229f9c4
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Change your language and open any dashboard.
The table titles (e.g. "Top countries" of the Leads dashboard) are not
translated.
It was lost in commit odoo/o-spreadsheet@9616681
With this commit not all link labels are translated. Only odoo links.
I don't think other (regular) links should be translated.
closesodoo/odoo#146574
X-original-commit: a2e406db138d51e710caf61a2809cfa991ea6cb3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
As the vendor bill names are those from the vendors
and the customer invoices are per document type,
it does not make a lot of sense to care about the gaps
in the traditional sense for LATAM journals.
closesodoo/odoo#145173
Signed-off-by: William André (wan) <wan@odoo.com>
This is because the `env.registry` may not be the latest registry in the
Registries pool, which happens when new modules are installed by a request and
fail. In the `setup_model` the `_m2m` is set to the old registry, but models
will try to read the `_m2m` from the latest registry and raise 'Registry' object
has no attribute '_m2m' error
This commit fix the issue by resetting the env when necessary
closesodoo/odoo#146544
X-original-commit: a433f3175a5105d9028dd9937d5461ae2d5d11fe
Signed-off-by: Raphael Collet <rco@odoo.com>
`field_computed` is decorated with `lazy_property` and will be reset by
`setup_models` If a request comes, read `field_compute` when `setup_models`
just clears some fields. The `field_compute` will be cached with fewer fields
and cause KeyError for the registry in the future.
This commit re-clear lazy_property for registry after fields are modified
X-original-commit: 04e35d7bf3ca98dc722795c75033747697d70d30
Part-of: odoo/odoo#146544
If `setup_models` is called concurrently,
the first one just delete the `registry._m2m`.
then the latter one tries to access `registry._m2m`.
An error 'Registry' object has no attribute '_m2m' will be raised
This commit add a lock to the `setup_model` to fix the problem
X-original-commit: 9ae78193f5c9ae4dcfa28c4ea4be1a7f98e42136
Part-of: odoo/odoo#146544
Make correspondent a compute to benefit from cache.
This reduces the time on populate medium from around 600ms to 200ms.
closesodoo/odoo#146109
Related: odoo/enterprise#52703
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On my machine, this reduces the time of the qunit suite from around
115s-120s to 100s-105s. This reduces the time of init messaging with
populate medium from around 3s to 1s.
Avoid having to split local id to find record. This is a slow process
that is better avoided.
Make _fields a Map rather than an object.
Name anonymous methods to get better trace and profiling.
Move field update to separate methods. Start making the update method
return whether the value has changed, to go into the direction of
removing reactive from internal code (especially for on change).
Use markRaw or toRaw on technical values that don't need to be observed.
Start better naming variables, especially having a specific name when
the value is possibly a proxy, and keeping the simple name for when it's
definitely not.
Part-of: odoo/odoo#146109
Snailmail letters failed to fail in newer version of Odoo.
The cause is a report attachment was supplied at the creation
of the letter, preventing the snailmail module to generate the report with the required CSS.
Said CSS was also rewritten to be clearer and to fix the follow up
reports.
closesodoo/odoo#146525
X-original-commit: 87c90abaec701cfa0e29391b52780e4c2b9e4694
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Steps to reproduce [1]:
- Go to website (blog post page) > Change the layout of the cover
(Customize > 'Regular' Cover).
- Click on the cover (in edit mode) > You can type anything inside and
use the text tools (E.g. if you add an image from the toolbar, it will
be added on all blog posts).
Steps to reproduce [2]:
- Go to website (`/calendar` page) > Unpublish an appointment page.
- Go back to the `/calendar` page > Switch to edit mode > You still can
edit the "unpublished" tag on the items cover (add text, images,...
using text tools).
The editor uses some methods (`getContentEditableAreas()`,
`getReadOnlyAreas()`,...) to check if an area should be marked as
editable on load, there is already a cover selector used to define a
record cover as an editable zone, but this selector is targeting the
whole element, leading to the behaviour described in [1] and [2]. We
actually just need to set the savable content (usually the record `name`
and `subtitle` fields) as editable and not the whole element.
The goal of this commit is to fix this behaviour by removing the cover
along with its descendants from the initial editable zones (especially
to prevent the scenario in [2], see: $editableSavableZones) and only
setting the savable fields as editable areas.
opw-3561659
closesodoo/odoo#146407
X-original-commit: 333e437d6acb227f092f1d152fe68d49076cff94
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This PR improves phone_validation tooling
* fix issue when adding or removing a 'phone.blacklist' record
with a void number;
* improve parsing, try to be defensive with input number to recover
from some commonly found issues with '+' or '00' prefixes;
* add tooling to extract region information from a number.
See sub commits for more details.
Task-3608129 (Whatsapp: Moultifix !)
closesodoo/odoo#146398
Forward-port-of: odoo/odoo#145554
Related: odoo/enterprise#52840
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After some testing notably with WhatsApp module, it appears usage of phone
numbers could be a bit more defensive to try to accomodate with data users
entered. Notably when failing to recognize a number, we can distinguish
error and try to reformat it based on two commonly spotted errors
* missing "+" in front of a E164-like number (e.g. '32455001122');
* usage of "00" in countries where it is not really standard to use it
instead of a "+" (e.g. '0032455001122');
Those find of numbers generate a 'TOO_LONG' error from phonenumbers library.
In that case we try to reformat it just to see if we can do better with it.
Task-3608129 (Whatsapp: Moultifix !)
X-original-commit: odoo/odoo@85c1306156
Part-of: odoo/odoo#146398
In this commit we add a new tool function in 'phone_validation' tooling
module. This tool 'phone_get_region_data_for_number' returns
* 'code': the region code from phonenumbers library, which is like 'BE' or
'GB' and (should) be the uppercase version of odoo country code;
* 'phone_code': the 'country_code' from phonenumbers library parsed object
which is actually the phone code of the country (might not be unique
e.g. 1 for US and CA);
* 'national_number': the 'national_number' from phonenumbers library parsed
object which is the number without the 'phone_code' prefix (e.g. for a
belgian number +32485001122 it is 485001122).
This will be used in whatsapp (enterprise) to ease finding country (and
partners) based on an input number.
Task-3608129 (Whatsapp: Moultifix !)
X-original-commit: odoo/odoo@646aa8f369
Part-of: odoo/odoo#146398
steps to reproduce:
- configure your POS with anglosaxon accounting and "Update quantities in
stock" at session closing and enable "Use QR code on ticket"
- open the POS, sell a storable product and close the session
- scan the QR code on the ticket to create an invoice
- check the pickings on the session form view
before this commit:
- 2 pickings are created, one at session closing and one from the invoice
after this commit:
- if the session is closed, do not create a new picking
opw-3592418
closesodoo/odoo#146077
X-original-commit: 486fa23e586c1dae490ffe0a91138d6f6dc6d824
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Since PR odoo/odoo/pull/124068, the browser history back no longer works
correctly when navigating from the home menu to applications. It requires
two history backs instead of one.
Why:
Two pushStates are performed on the router, the first to add the menu_id
and the second to apply the action associated with the menu.
These two pushStates are not in the same setTimeout, which causes two
changes to the url. So two entries in the browser history .
Solution:
We perform the two pushStates in the same setTimeout. This causes
only one url modification and therefore one entry in the browser history.
How to reproduce:
- Go to the home menu
- Click on the app A
- Return to the home menu using the toggle menu
- Click on the app B
- Perform a history back
- The home menu is displayed
- Perform a history back
Before this commit:
The home menu is still displayed
After this commit:
The app A is displayed.
closesodoo/odoo#146143
Enterprise: odoo/enterprise/52683
X-original-commit: 8e3152fbfbb4a836ab9663d009fbcacbe3554ae8
Related: odoo/enterprise#52697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to reproduce issue:
1. Select non english language
2. Open a POS session
3. Select a product
4. Got to payment UI
5. "Customer" is not translated
Explanation:
Concerned element uses a `t-out` with an `or` operator, translation can not apply to it.
Suggested fix:
Use of distinct tags with `t-if` and `t-else` instead, to make translation work.
opw-3636234
closesodoo/odoo#146292
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Example use case:
- Create a product A.
- Update the available quantity of the product.
- Create a basic user without Inventory permissions.
- Go to the product list (product.product or product.template) and get
an error when access to stock.move records to set the qty_available
field (for example).
TT45220
closesodoo/odoo#142472
X-original-commit: e41fbda20582683361a5124db418f152bf80a3ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, attempting to do
`self.env['calendar.event'].write({'partner_ids': [0, 1, 2]})`
would give a traceback as the method that updates attendees
only supports parsing commands, not ids.
This is a problem as that method is called from 'write' and other methods
with the assumption that partner_ids can only contain commands.
This will not be the case when using a gantt view and grouping
by partner_ids for example, and cannot be worked around.
task-3452277
closesodoo/odoo#146446
X-original-commit: 88e191132bf40a4e3090077f1fd0077e649eb7fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Since [this other commit], we add ZWS characters to the edges of links.
Unfortunately, this breaks the label option of the link tools that has
been introduced in [this commit].
Steps to reproduce the issue:
- Go to website
- Edit a page
- Click on the contact us button in the header
- Using the label option of the link tools, delete the final character
=> Nothing happens.
The final character is not deleted as expected.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
[this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022
Related to runbot-44779
closesodoo/odoo#146361
X-original-commit: 593dc52cd5c3362c446395a52a7782f74f445e34
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The issue:
having 2 invoices/quotations/purchase orders with different customer, each customer has a different language, the 'Unaxed amount' string will get translated into the first language of the first invoice partner.
The fix:
recompute the total when the lang context change
opw-3569173
closesodoo/odoo#146311
X-original-commit: d48a09738bdde4050bc75f82480ff47ddeb8b553
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit and since PR [1], the default "checked" value set on
checkboxes field on the form snippet were lost once the page is saved.
This is because [1] changed the rendering engine of qweb templates from
our own qweb js rendering code to owl templates rendering.
By doing so, `t-att-checked="'checked'"` would toggle the "internal"
checkbox checked value but would not add the checked attribute on the
element.
It's a deliberate choice made in owl. As the checked attributed does not
mean the same as the internal checked value, it makes sense.
Indeed, the checked attribute is about the default value of the checkbox
while the checked internal value is about the current checked state of
the checkbox.
In React, for instance, the same behavior can be seen. And if one wants
to really set the checked attribute, they got to go with
`defaultChecked`.
Same apply with `value`.
Maybe owl will implement the same `defaultXXX` behavior in the future as
it's something that was already discussed on their side.
Step to reproduce:
- Drag & drop a form in the website builder
- Add a new custom field and select "Multiple Checkboxes" type
- Set one of the checkbox checked by default
- It is visually checked, but the attribute is not set
- Save the page
-> The checkbox is back to unset state since the attribute was not set
[1]: https://github.com/odoo/odoo/pull/130467
opw-3607795
closesodoo/odoo#146328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit add a new delay_type that will add to the date the nb_days then go
the end of the month and finally add a new field called days_next_month.
This field is a Char because we want the field to be of size 2. Also, we added a
constraint that this field must be numeric and between 0 and 31.
Ex of use with Invoice date the 25/11/2023, if we have a payment term with 90
for the nb_days and 10 for the days_next_month:
+90 days = 23/02/2024
End of month = 29/02/2024
+10 days = 10/03/2024
(Also, there is a special case handling when the day of the month is 29, 30 or
31 to avoid exceeding the next month's end. For instance, with a payment term of
30 days end of month and using the 31st of a month, prevent calculation from
moving beyond the end of the next month (e.g., early March instead of end
February)
closesodoo/odoo#143758
Task: 3609320
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
__Current behavior before commit:__
`_compute_meeting` computes the meetings linked to the children of the
partners in `self`. To do so, it first retrieves all children partners
of `self`, then it loops through all of them to apply the meetings to
the parents.
This way of doing is inefficient because it is useless to iterate over
the children that don't have any meetings.
__Description of the fix:__
Loop only through the partners that have a meetings instead of all
children partners.
Improve `test_meeting_count` to test the case where only the child
partner has a meeting but the parent has initially none. This test
improvement is a forward port of [#144575][1].
__Benchmark:__
| len(all_partners) | w/o fix | with fix |
| ----------------- | ------- | -------- |
| 1k | 32 ms | 14 ms |
| 100k | 1500 ms | 800 ms |
opw-3511371
[1]: https://github.com/odoo/odoo/pull/144575closesodoo/odoo#146381
X-original-commit: e35949cdd09b4312a60383b79290008e78768b64
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Description of the issue/feature this PR addresses:
Within the project task form view, in the timesheet notebook, the "Remaining
Hours on SO" label becomes misaligned when the planned hours are set to 0.
Fix:
To ensure proper alignment, add a condition for the label.
task:3468392
closesodoo/odoo#146334
X-original-commit: 3f35ccf7bdd9c0cb988f0207427ec8d3acccecd6
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Add a "Text-Image" on the website.
- Replace the image by one of your own.
- Save.
- With the html editor, remove the `mimetype` attribute, the
`data-original-src` attribute and change the `src` of the picture into
the corresponding protocol-relative one. The `src` then looks like
"//domain/web/image/...".
- Save the modifications of the html editor.
- Enter in edit mode.
- Click on the image.
-> It is now impossible to change options such as `Filter`, `Width` and
`Quality`.
Because the `data-original-src` attribute was removed from the image,
the system tries to add it back thanks to the `loadImageInfo()` logic.
Because the `src` attribute of the image is now a protocol relative url,
`new URL(src)` will raise an error and the logic will use this url as
argument for the `/web_editor/get_image_info` route. Because the url
given in argument of the rpc call is not the relative one, the system
fails to find the original attachment. The `mimetype` attribute is
therefore not added back on the image, leading to the impossibility to
change some options.
To solve the problem, this commit modifies a bit [this commit]. In order
to be robust to absolute, relative and protocol relative URLs, an URL
object is first created from the image src. The relative URL
(`.pathname`) of the URL object is then used to retrieve the original
attachment linked to the image.
Let's synthesize the different `relativeSrc` obtained with different
image src. In the following examples, "https://test.com/blog/travel-1"
will be used as `img.ownerDocument.defaultView.location.href`.
(the complete URL of the document in which the image is located).
- `src` is an absolute URL (e.g.
"https://test.com/web/image/697-d0f2aaf8/shoes.jpg"). In this case,
`relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that begins with a slash (e.g.
"/web/image/697-d0f2aaf8/shoes.jpg"). This URL represents an absolute
path starting from the root of the domain. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that does not begin with a slash (e.g.
"web/image/697-d0f2aaf8/shoes.jpg"). The interpretation of this URL
depends on the current location. In this case, `relativeSrc` =
"/blog/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a protocol relative URL (e.g.
"//test.com/web/image/697-d0f2aaf8/shoes.jpg"); there is only the
protocol missing. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
This solution takes the advantage of the second argument of the `URL()`
constructor which is used if the first parameter is a relative or
protocol relative URL and which is ignored if the first parameter is an
absolute URL.
This commit does not only modify [this commit] to handle more types of
URLs but also:
- To avoid having to use `.split()`. Indeed, `.pathname` does not
include query parameters.
- To avoid having to consider an error raised by `new URL()` as a normal
flow. Indeed, in [this commit], an error would be intercepted by the
`catch` if `src` was a relative URL. This was a legitimate flow. The
problem was that other unwanted types of src (for example protocol
relative URL) were also raising errors but were silently ignored (as
intercepted in the `catch`).
[this commit]: https://github.com/odoo/odoo/commit/89c14783846288a2de53f6258a93440e02550b13
task-3623731
closesodoo/odoo#146238
X-original-commit: 96324fe8443647a078756c98f9629af274ff38a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
When a line with a factor_percent of -100 is applied in the tax,
it should be subtracted from the ImporteTotal.
This way, we might think that the total of the invoice should do,
but we need the amount before application of the withholdings.
And in the case of DUA it should be the sum of base and tax.
Doing this, we realized that we do not have any tests for
vendor bills and their refunds for the intra-community case, so
we added one for vendor bill and one for vendor refund. (there
is no -100 line for sale)
In the meantime, we added docstrings on the existing tests
and realized that the sale of intra-community services, it should
be no sujeto por reglas de localizacion instead of sujeto.
(because as well with the fiscal position, the delivery address counts)
We also saw that for intra-community, the clave regimen depended
on the tags on the amls but the refund repartition lines were not mapped on the
tax report line with Intra-community but in a separate refunds section
(mod303), so we fixed by checking all tags on the tax from all the
repartition lines.
task 3603788
closesodoo/odoo#143204
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
To reproduce
============
- Create a meeting activity from any document (for example CRM opportunity) with a calendar.
- It will create a meeting in the calendar.
- Now, mark as done the activity created and it will delete the meeting from the calendar too.
revert of https://github.com/odoo/odoo/pull/144526
opw-3626773
closesodoo/odoo#146421
X-original-commit: 0b183299a8ef7361d28d9d2b49cc56b74bfb2b46
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Steps to reproduce:
- Install Accounting and l10n_sa_edi
- Create a retention tax: (e.g. "Retention Tax 10%")
* Amount: [a negative amount] (e.g. -10.00%)
* Is Retention: [checked] (in "Advanced Options" tab)
- Create an invoice with the following invoice line:
* Product: [any]
* Price: 1000
* Taxes: "Sales Tax 15%" and "Retention Tax 10%"
- Confirm the invoice
- Print the invoice
=> On the invoice, there is a "VAT Amount" field that should show
the amount coming from the taxes that are not Retention taxes as it
is done in the EDI invoice (XML).
However, the Retention tax is subtracted.
In our example:
- Tax amount for "Sales Tax 15%" is 150.00
- Tax amount for "Retention Tax 10%" is -100.00
=> The "VAT Amount" field of the invoice line is 50.00.
It should be 150.00 instead.
Solution:
Compute the "VAT Amount" field as it is done in the EDI invoice.
opw-3568831
closesodoo/odoo#146394
X-original-commit: b50d20e9fc631d7aa2e64cf6749be1630354fd69
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Steps to reproduce:
- Install Accounting, Sales & Purchase
- Go to "Settings / Users & Companies / Companies"
- Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany)
- Switch to Branch Company
- Go to Sales (or Purchase)
- Create a SO (or PO)
- Add a SO line (or PO line) and try to select a tax
=> Taxes from the parent company are not available in Sales and Purchase
as they are in Accounting
opw-3604981
opw-3636972
closesodoo/odoo#146384
X-original-commit: ddc653758c2dd6af74e21f5fbd07ab679ffb3e73
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Summary
-------
Currently, the 'Total amount of invoice in letters' setting doesn't do
anything on GCC invoices.
Steps to reproduce
------------------
* install `l10n_sa`
* enable the Arabic language
* in the settings, enable 'Total amount of invoice in letters'
* create and print an invoice
You should see that the amount in words in not displayed.
Note:
Currently, currency labels are not translatable. Since this isn't
something that can be changed in stable version, it was decided to not
include them in the Arabic amount in words.
opw-3501112
opw-3485691
closesodoo/odoo#146364
X-original-commit: 1fb28f229c701ae1261dc502ef345ffda162f994
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before this commit, the sending webhook did not work well naturally
with the receiving end.
After this commit, it does since default values on base_automation have been adapted.
closesodoo/odoo#142710
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Set a webhook that executes a ir.actions.server of type python code.
Before this commit, the code had no access to any request's parameters. This was a limitation
in the basic flows that the feature is supposed to support.
After this commit, we pass in the context a key "payload" that contains a copy of the request parameters.
task-id-3599629
Part-of: odoo/odoo#142710
Steps to reproduce:
- Open Project
- Go to project for which sale order item is created
- By clicking on three dots, go to Project Updates
- In right side panel, milestone section, there is no space between milestone
name and the SOL
Issue:
- This lack of spacing between milestone name and SOL makes it difficult for
users to read and understand milestone information.
Cause:
- The project.update right-side panel was displaying milestone names and SOL
without a space, causing readability issues for users.
Solution:
- added a space between the milestone name and SOL.
task-3545942
closesodoo/odoo#146360
X-original-commit: 6341fabafd225e2ecf8037f58e5312ce391003f0
Related: odoo/enterprise#52816
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
[Commit 1] made sure the history worked when resizing elements by
calling `odooEditor.automaticStepUnactive()`, but applied its
counterpart `automaticStepActive()` only at the very end of the action,
leaving some `return` statements on the way that could break the flow.
This commit calls `automaticStepActive` just before leaving the listener
and moves `automaticStepUnactive` just before the first DOM
modification. It's both more logical and avoids returns pitfalls.
Note: `automaticStepActive()` makes sure modifications made on the DOM
through the browser's developer tools are tracked and can be reversed
with the undo button. Not reactivating it in time means some flows could
be broken (until another method reactivates it).
[Commit 1]: https://github.com/odoo/odoo/commit/423f4bd2a6cc47e69699d2437eaa5acda94bb98d
Related to task-3576046
closesodoo/odoo#146249
X-original-commit: b99cc41e4352d3ff9bffe7b0a5436edbef0ab01b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Before this commit and since [1] when the website builder was moved from
the "frontend" to the "backend" of Odoo in Odoo 16, the option to enable
URL redirect when updating a page URL was "compressed":
- The toggle/switch element has not enough room to be displayed entirely
if there were too many dependencies
- The toggle/switch label was split in multiple lines, words could even
be split in 2.
Step to reproduce:
- Go to / in the website builder (so the / finds a lot of dependencies)
- Open page property
- Change the URL field, you see the redirect url field appear with the
mentioned issues.
Note:
- In other languages, the switch label could be even longer, splitting
the line makes even more sense
- Removing a class is generally something to be avoided in stable, but
this type of class should not be xpath'd anyway. And given the
template structure, it's unlikely someone would have xpath it as it's
easy to xpath any element without relying on classes.
One solution would have been to add a new class to cancel the first
one but it seems overkill in this case.
[1]: https://github.com/odoo/odoo/commit/2ef7e788263b4742a8e0788f47673b7b31da3726closesodoo/odoo#146244
X-original-commit: 8c17c487e6632192874133a2ce4265a0f1eaf6fb
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a page is reloaded with the chat bot, it sometimes restarts from
the beginning. This commit ensures the chatbot starts where it left
after a page reload.
closesodoo/odoo#146175
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit and since commit [1], it was possible to clone a page
in the page list view.
It shouldn't be the case, cloning a page lead to bad result: a page
with the same URL which is not shown in the page list view because pages
are filtered by URL to remove duplicates.
Cloning a page has always had to be done through the page properties >
"clone page" button. Doing it this way will ask the user for a new page
name (and so a new url). The page will then correctly be listed.
[1]: https://github.com/odoo/odoo/commit/3192051806e0da1276604a31ad818f8768105362
opw-3591738
closesodoo/odoo#146173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose:
- Changed the default value of 'Show In Preference' (is_public) field from true
to false for preventing the automatic publishing of mailing lists.
Task-3594678
closesodoo/odoo#144699
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In this pr we remove the blank choice in the self-ordering mode select.
It's unnecessary and throws a validation error on saving settings.
Task 3599144
closesodoo/odoo#142351
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
When the pos was loading only a part of the products, the request should follow those rules order:
- product is a favorite
- product is a service
- product had stock moves soon
- product update
But this request didn't take into account consumables products and if there was no stock move,
the value was null and postgres consider null values first when ordering desc.
Now with that changes, the order is correctly set based on the rules above.
closesodoo/odoo#139981
X-original-commit: 35a9168a53bded7e13451f4b485443c1b419ea21
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Problem
---------
In most cases, default deferred accounts and journal need to be set up
for localizations. This is normally done in the enterprise report module
for that localization. However, in some cases, the localization does not
have special report formats. In such situation, a localization report
module that sets up very few default values for the data company is
defined. This is way overkill.
Objective
---------
Allow the community company template to have 'unknown fields' defined.
Doing so, allows for the default deferred accounts and journal to be
defined without entreprise module to exists. Currently, this raises an
error.
Solution
---------
In the pre-processing of the chart template values, we skip all the keys
in the company data that are not company fields.
We add a context value which, when True, revert that behavior back to
before this commit and checks that all fields in the company template
are actual company fields (this will be used in the standalone test for
l10n modules).
We also update the standalone test for l10n modules so that:
1. it reports errors in all l10n modules at once.
2. it uses the context value described above and checks that all fields
in the company chart template are correct company field.
closesodoo/odoo#138937
Related: odoo/enterprise#50305
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if you switch to a right-to-left language and open the POS,
the numpad will look like this:
3 2 1
6 5 4
9 8 7
The numpad should stay the same even in RTL languages:
1 2 3
4 5 6
7 8 9
opw-3623228
closesodoo/odoo#146181
X-original-commit: fb0ece3336f53cfba4e7ef9c59f4acbd292da45a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Benoit Socias
