In this commit:
==================
Invisible the 'Removal strategy' field when selecting the other
location type except Internal location.
task-3555853
closesodoo/odoo#157888
X-original-commit: f24a77d073d609b03c0ff686f843db10218ad1b7
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
It cannot happen through the default SO form view, but some funny guys
have found other ways to do it, even though it can be quite problematic,
especially if the new pricelist is in another currency.
closesodoo/odoo#157742
Related: odoo/enterprise#58744
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Adds text values for the call settings sliders.
* Replaces `onChange` events with `onInput` events so that the values
respect the position of the sliders.
* Debounces some functions to handle the increased amount of calls
due to the swap to the `onInput` listener.
* Changes the default value of `voiceActiveDuration` from `0` to `200`
to match the minimum value of the input.
closesodoo/odoo#151028
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Issue: When using the Fullscreen mode of slides for articles we do run
first the website animations before loading the slide, which will make
the content to stay invisible since we will never actually perform the
animation.
Steps to reproduce:
1. Create a new course with an article content.
2. Add any block (text, image).
3. Add an animation to this piece of block.
4. Go to Fullscreen mode.
Solution:
We manually instantiate and attach the WebsiteAnimate widget to
the wpContainer element to ensure animations are properly initialized
and applied after the slide has loaded, after that we get rid of this
instance after every new slide that load so we avoid having multiple
instances.
opw-3757919
closesodoo/odoo#159445
X-original-commit: 593ca1f36a4a9da753d8361840b07e2445f2d99b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
When using the up/down arrows in an `InputUserValueWidget`, only the
first value is updated but the other ones are lost.
This commit adapts the behavior so that all parts of the composite value
are updated.
When decreasing, parts that have reached zero are set to zero.
Steps to reproduce:
- Drop a "Banner" snippet.
- Select the text block.
- Set the "Border" option to "5 10".
- Press the up or down key.
=> Only the "5" was updated, the "10" was lost.
task-3800288
closesodoo/odoo#159385
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
When specifying a composite value in a `UnitUserValueWidget`, if the
first element is a 0, it is considered inactive and resets to its
default value.
This commit considers composite values that start with a 0 as active.
Steps to reproduce:
- Drop a "Banner" snippet in a page.
- Select the text column.
- Specify "0 10" in the Border.
=> The value was reset to 0.
task-3800288
Part-of: odoo/odoo#159385
Since [1] when `extraClass` was introduced, styles are wrongly applied
if an `extraClass` is defined on a `selectStyle` option, but both the
class and the option modify the same CSS property.
Typically, the "Round Corners" option sets the `border-radius` property
and uses the `rounded` extra class. But that extra class specifies
values for the `border-radius` properties.
Without the class, `applyCSS` determines that the style of some corners
is already `0px` and does therefore not need to be added to the inline
style.
But once the class is added, this is not true anymore - and the `0px`
should have been specified.
This commit avoids this issue by applying the CSS again once the
`extraClass` is added.
It also reverts [2] partially to remove the `extraClass` handling from
within the `applyCSS` function.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Select the image.
- Set the "Round Corners" to "50 0 0 0".
- Press tab to leave the field.
=> The entered field values was transformed.
[1]: https://github.com/odoo/odoo/commit/bf5b4b69330747af7b09d48e59218b78a29a4b14
[2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4
task-3800288
Part-of: odoo/odoo#159385
Steps to reproduce:
-------------------
- create 2 websites (for one or two companies);
- create 2 jobs;
- publish job A in website 1;
- publish job B in website 2;
- as a public user go to website 1 and apply for job A;
- go to website 2 and try to apply for job B;
Issue:
------
When we encode the email address, we receive the message:
```
You already applied to another position recently. You can continue if it's not a mistake.
```
Cause:
------
We don't take into account the website linked to the job we are applying for.
Solution:
---------
Incorporate the website into the domain for application search.
opw-3798670
closesodoo/odoo#159263
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
**Current behavior:**
If a recurring sale order has an associated sale order option
and the recurring plan of the order is changed, a trace back
occurs.
**Expected behavior:**
The recurring plan can be changed as it ordinarily would.
**Steps to reproduce:**
1. Add a recurring product to a sale order
2. Add an optional recurring product to the order
3. Try to change the recurring plan of the order to encounter
the trace back
**Cause of the issue:**
This flow causes some 'phantom' sale order lines to have their
price recalculated (phantom because they have no price, qty,
currency, nor order_id field values). During this recalculation
a currency_id is expected either in the line itself or in the
sale order it is a part of. Because there is no value for either
of these, it fails the ensure_one() method in the sequence
(0 vals, expects 1).
The phantom lines are created in the `sale.order.option` model
in the `sale_management` module, in `_compute_price_unit()` and
`_compute_discount()`.
**Fix:**
Call `invalidate_recorset(flush=False)` on these cached records
at the end of the methods in which they are created.
opw-3754297
closesodoo/odoo#158950
X-original-commit: 16f51c93d0f9cadcdbcd9ed2d58e43ed0d550bf9
Related: odoo/enterprise#59301
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently, an exception is generated when the user tries to access embed view
of slides by following the steps:
- Install "eLearning" with a demo data
- Open external embed view of slide 1 by "/slides/embed_external/1" in url
Error:
`AttributeError: 'slide.channel' object has no attribute 'website_share_url'`
This error is because commit [1] added code that tries to access the
'website_share_url' field in the 'slide.channel' model in template
'embed_slide' , but it actually belongs to 'slide.slide'.
This commit resolved the above issue by accessing "website_share_url"
with "slide" instead of "slide.channel".
[1]-https://github.com/odoo/odoo/commit/db63c03af9932ae4d9b786620e88e62ce938589a
sentry-5095823727
closesodoo/odoo#159513
X-original-commit: e2e868cca86f09e4e71d47837432884e886a42c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
Description:
On a database with heavy activity, it is possible for the payload
size we pass for the `NOTIFY` query on the bus to be larger than what
PostgreSQL allows by default, 8000 B. This limit is defined as:
https://github.com/postgres/postgres/blob/6686e9676c8faff4ee04c1574e117ae38f117efa/src/backend/commands/async.c#L158-L166
and it is used to compare the size of the payload before processing:
https://github.com/postgres/postgres/blob/6686e9676c8faff4ee04c1574e117ae38f117efa/src/backend/commands/async.c#L654-L657
Fix:
- Binary split the payload into multiple chunks if it's exceeding
the above-mentioned limit. The unit of splitting is a channel, so
if the content of one channel itself is larger than said limit, it
is not handled, but shouldn't occur under normal circumstances.
- Introduce also a new ENV variable `ODOO_NOTIFY_PAYLOAD_MAX_LENGTH`
to allow tweaking of the limit if they are running a handrolled
custom PostgreSQL cluster.
Reference:
opw-3650618
closesodoo/odoo#159469
X-original-commit: 61c7bba44990522d853bae25aa7899cb03c72e31
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
[This commit] fixed an issue with the menu cache. Unfortunately, during
the forward port, we missed updating the cache key according to what has
been done in [this other commit]. This commit updates the cache key and
improves the test.
Steps to reproduce the bug fixed by this commit:
- Render a website without a record URL in the menu (to the cache)
- Edit the website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This issue does not occur if there is a record like URL in the menu
before the first render.
[This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68
[this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159464
X-original-commit: 9b5647f2951cdd7bde214f860b5ea95d42d2a501
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Currently, on sale orders, you cannot access parent's fiscal positions
from a branch.
Steps to reproduce
-----------------
* install `sale_management`
* set up a company hierarchy. Let's say we have two companies P and C
such that C is a branch of P.
* let's say that P has a fiscal position F
* switch to company C
* attempt to set fiscal position F on a sale order
You will see that F does not appear on the list.
opw-3773335
closesodoo/odoo#159386
X-original-commit: fa419e550497b1291930f9fb8215a719de331024
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before that commit, the search defaults would not be filtered when the
WithSearch is started with a search model state or updated by its parent.
closesodoo/odoo#159406
X-original-commit: dac527b7baa699cef0828a9d87a4c814ff3f7f05
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Issue:
- When adding opportunity/lead to a contact using Studio
and attempt to add a line, we encounter the following error:
"TypeError: 'NewId' object is not iterable."
Steps To Reproduce (in 17.0):
- In a contact form open Studio and add a O2M field
Customer (Lead/Opportunity)
- Try to add a line
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
Solution:
- The issue arises in the search domain of
`return_if_relevant` , exactly in
("partner_id", "child_of", lead.partner_id.commercial_partner_id.id)
where the type of `lead.partner_id.commercial_partner_id.id`
is NewId since the partner is being edited to add a task.
This action triggers the `parse` and `to_ids` methods with
a value type of NewId. thus the error.
- The operator child_of expects a list of IDs, and the ids
property refer to the record's origin ids. to resolve this,
replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
closesodoo/odoo#159296
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Before this commit
==================
Unable to activate the industry from the form view in the industry section.
Additionally, the button in the form for upgrading would be called the
button_immediate_upgrade method, resulting in errors.
After this commit
=================
Activation of the industry from the form view in the industry section is now
possible. Furthermore, the issue with upgrading the industry from the form view
has been resolved.
task-3775729
closesodoo/odoo#157008
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Before this commit:
===================
In coins/bills pop pup, if user adds some coin and removes quantity from any of
the fields (blank space) then it's showing `NAN` and not calculating the other
inputted value which is completely annoying.
After this commit:
==================
If user removes quantity from any of the fields (blank space) then the input
will count `0` in the backend and calculate accordingly.
task - 3728728
closesodoo/odoo#153770
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The barcode nomenclature allows to define custom prefix for gift cards.
e.g. the default nomenclature in demo data allows both 043 or 044 as
prefix for rule of type coupon.
Therefore the hardcoded string with 044 doesn't allow to sell a gift
card whose barcode does not start with this.
Instead of hardcoding the value, fetch it from the configuration and
the nomenclature that is defined in the settings.
OPW-3499787
closesodoo/odoo#159349
Signed-off-by: David Monnom (moda) <moda@odoo.com>
In c983f8a5 we updated the `test_survey_invite_action` test
to create surveys in batch instead of one by one.
This is problematic because `session_code` (given by utility
method) must be unique for all surveys.
Technically, using 6-digit codes makes it very unlikely that
a collision occurs with existing records (see
Survey._get_default_session_code's iterative process).
Task-3829536
closesodoo/odoo#159295
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When using the "ConditionalVisibility/DeviceVisibility" option for
blocks that are inside a popup, you can end up with an empty popup.
This was has been a limitation of those options for a while, but there
is a real use case for hiding a popup under certain circumstances.
Adapting the options to work on popup was complex enough that it does
not seem suitable for a stable version.
But a simple solution that tries to break as little as possible existing
code could be a huge benefit.
This commit makes it so that if the all children of the .oe_structure
are currently being hidden by ConditionalVisibility selectors or by
DeviceVisibility classes, the popup will not be shown to the visitor.
It will still show if content is being hidden by other means, either
with customizations, or if the content is dynamically generated (like in
the case of a Dynamic Snippet).
This change is done starting saas-16.3 as this is the version the OPW
was opened with, and since this is still a significant change, it will
limit the impacted versions.
opw-3734501
task-3128349
closesodoo/odoo#158303
X-original-commit: 3f5e3c4d49d4c0f67b548d22846e27c5ff8c73f1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Avoid redirect to forum/<name>/question/<post> that will rediret in all
case to /forum/<name>/<post>.
closesodoo/odoo#158148
Signed-off-by: Jérémy Kersten <jke@odoo.com>
- 17.0
Steps to reproduce:
- Open Project app and click on overflow menu of a project
- Select project updates option
- Try and create a new update document
Issue:
- The budget details text is just coming under activities which should be in
profitability section.
Cause:
- Unset priorities of the inherited XML to cause files load before on another
changing the orientation of display order and same Xpath for two inherited
files.
Solution:
- Changing Xpath of one inherited view to accommodate for the order of display
Task-3678808
closesodoo/odoo#149564
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: website_sale
This is a follow-up of [1], which missed some occurrence of the same
issue that it fixed.
E.g.
- Add a delay to the "write" of the event model
- Go to /event/<event_id>/community
- Enter edit mode
- Click on the page
- Enable the room creation option
=> The page reloads but nothing seems to have been done... it is
actually *being* done: the page reloaded too soon.
Note: this commit also marks some other occurrences which are not buggy
but might be in the future if not properly changed. To be adapted in the
master forward-port.
[1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345closesodoo/odoo#159393
X-original-commit: e941363242c918f52222b105de7336e8c830e8db
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue: When trying to duplicate courses with the visibility set to
members we won't be able to duplicate it, since when creating the
duplicate course we won't copy the enroll policy and instead we will
apply the default value, 'open' which triggers our validation error.
Steps to reproduce:
1. Install website_slides.
2. Create a new eLearning course.
3. Set the options:
-Show course to: Course Attendees
-Enroll Policy: On Invitation
4. Try to create a copy of this course.
Solution: If we allow the copy of the enroll policy we will make sure
that the new created course has the right parameters to be created.
opw-3749209
closesodoo/odoo#158651
X-original-commit: f17a3d331f877116271e014c5a7b61938311944c
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
This commit addresses slow performance of the JS `OrderLine.findAttribute` method when `attributes_by_ptal_id` is exceedingly large.
Before this commit, `findAttribute` would loop over all the values of `this.pos.attributes_by_ptal_id`, and filter out only the attributes that have at least one of the passed in ptal IDs (from the `values` parameter) within the attribute's "values" list. It would also modify the attribute to include a `"valuesForOrderLine"` key mapping to a list of all of the found ptal IDs from that attribute's values.
This method becomes slow when `this.pos.attributes_by_ptal_id` is very large. Since it needs to loop over every single attribute.
This commit provides a workaround to this slowness, by caching the search for valid attributes that this method performs in a lookup table.
First, we construct the lookup table in `_processData` method of the `PosStore` class. `_add_ptal_ids_by_ptav_id` does this, by looping over all the values of all the attributes, mapping the ptav ID of the attribute to all the ptal IDs we find.
Now, inside `findAttribute`, we will instead loop over each of the passed in `values`. For each value, we will retrieve the all the cached ptal IDs from `this.pos.ptal_ids_by_ptav_id` for the given value. Now that we have the ptal IDs, we can get all the corresponding attributes from `this.pos.attributes_by_ptal_id`. For each of those attributes, we can do the same modification from the original method by adding the `"valuesForOrderLine"` key/value. Finally we return all the modified attributes.
This new method has a nested for loop, which may seem like a problem. But I believe that both the things being looped over (`values` and `this.pos.ptal_ids_by_ptav_id[value]`) should be very small compared to the potential size of `this.pos.attributes_by_ptal_id`. (43,000 in this customer's DB)
`findAttributes` is called many times whenever the POS's numpad buttons are pressed, so this commit has the overall effect of drastically reducing the input latency for a numpad press.
However, I do believe that this is a workaround, and the real problem is that the entire `attributes_by_ptal_id` is always passed to the POS, regardless of what products are actually being ordered. `attributes_by_ptal_id` should instead be incrementally fetched as products are ordered (if this is possible).
Benchmarks (in customer DB):
Before commit, each keypad press took around 1-3 seconds per Order Line present in the POS. For 11 products this was ~15 second latency.
After commit, each keypad press is almost instant.
The `ptal_ids_by_ptav_id` lookup table will consume additional memory, in this customer's DB I've estimated it to be about 0.3MB more memory. Taking memory snapshots in profiler shows no significant different between versions, however this is inconsistent.
Will attach profiler results to PR.
opw-3788840
closesodoo/odoo#159402
Signed-off-by: David Monnom (moda) <moda@odoo.com>
If the move in the test is created at 23:59:59, and the wizard on
the next day at 00:00:01, the test will fail because the wizard
takes today as the date at creation.
We just add a freeze_time (for this test only, as the other tests
in the class don't have the issue).
Linked to runbot error 60478
closesodoo/odoo#159377
X-original-commit: d064068ff46ef8f84224f50c4c86922ae2004159
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When the user creates a new ribbon without a background color,
a traceback will appear.
Steps to reproduce the error:
- Install "website_sale"
- Go to Website > eCommerce > Products
- Pick a product > Sales > Create a new ribbon without a background color
- Save & Close
Error: A traceback appears:
"TypeError: argument of type 'bool' is not iterable"
https://github.com/odoo/odoo/blob/806a60d9766e4e04f461a0fb7c824cf5f5c7d5ae/addons/website_sale/models/product_ribbon.py#L24
Here, when the user creates a new ribbon without a background color,
"bg_color" will be False, so when it tries to check "vals['bg_color']".
It will lead to the above traceback.
sentry-5077714703
closesodoo/odoo#158954
X-original-commit: e9021f1332b49042733cf263e8cb62218ccc2965
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Fix the property mobile display:
- Set the popup in fullscreen.
- The draggable feature is disabled.
- Replacing the move up/move down property arrows in the popup by a
back arrow so that the fullscreen popup can be closed.
- Removing the min-width on the property popover to prevent the popup
from going out of the screen.
- Edit button is now always visible as hovering on it is not possible on mobile.
Task-3635554
closesodoo/odoo#156886
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Our certificate for aeat seems to not be valid anymore.
We don't have a replacement currently.
The flow is still tested with bizkaia or gipuzkoa (mostly just
different servers/addresses, but same flow/xml), where the
certificate is still accepted.
We remove this test that fail every day.
Linked to Runbot error 25907
closesodoo/odoo#159382
X-original-commit: ccd5ce7f0f106f68ce704cb032bcb754a480be14
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Before this commit, attempting to invoice an order paid by cash in a
new session, with cash rounding enabled only for cash payments in the
PoS config, would result in an unbalanced entries error.
opw-3813932
closesodoo/odoo#158907
X-original-commit: 3a61e143af62f1edeec299a39ab133138ec0560c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Construct deciding on whetheres an attendee should receive 'complete'
mail, contains a condition which checks if the attendee has:
number_completed_slides >= number of all slides
This however falls into a corner case when there is no slides at all and
computation gets triggered (which got introduced with commit [1] ).
[This Commit Change]
This commit introduces an additional check on the total number of slides in
a channel. Consequently, records without any slides in the related channel
will no longer send completion mail notification.
[Reproduce]
- Install website_slides
- Create a new eLearning course with some content but do not publish it.
- Add attendees.
- Delete all the content.
- BUG: emails about finishing the course got sent (Settings/Technical/Emails)
[Why this commit modifies existing test]
The test introduced with commit [2] checks if a specific template is used
in email generation, requiring email generation to occur as a prerequisite.
Originally (before [This Commit Change]), it relied on the default behavior
that considered an attendee a completer even without any published slides,
thus triggering an email. However, after this commit, with a course containing
zero published slides, completion cannot occur, and thus, no emails are sent.
For this reason slight alteration of the test setup is required allowing
for the emails to get sent and in effect the test to perform its role.
[References]
[1] https://github.com/odoo/odoo/commit/3efa80847c4631febefc770b79bb786953a05b36
[2] https://github.com/odoo/odoo/commit/9a0231d5c3fa25f4ec63303cfc7eb8e2bc8ff9e1
opw-3703987
closesodoo/odoo#153178
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
In the beginning of 2024, the default tax of 20% in Estonia was changed
by 22% (with the 20% still supported as a legacy) [1]. With that change,
the tax report was also updated so the line previously containing the
taxable amount at 20% now contains the taxable amount at 22%.
However, the formula computing the tax amount itself was not updated to
reflect this change and was still computing the tax by multiplying the
taxable amount by 0.2.
This fix corrects the tax computation in the report.
[1] ec25405367eaeca6bdd1f54e2a09fe6b93b8a4b6
opw-3815147
closesodoo/odoo#159339
X-original-commit: 6ea02a52b2cedce70572df78ddb7142acb784886
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Refactored the restrict_partner_id check in the stock_account module to make it more flexible for future updates.
Now, it's easier to extend restrict_partner_id check without override the whole method.
Related with https://github.com/odoo/odoo/pull/155694closesodoo/odoo#158687
X-original-commit: 8a4c6e51a200c4b093571d4f2003b39de07fe4b1
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Upon calling `invalidate_recordset` the current recordset present is
flushed. That recordset can be active=True which override active=False
set `_process_job()`. Flushing the recordset *before* calling
`_process_job` makes sure that there is no dangling data to be flushed.
closesodoo/odoo#159262
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Current behavior:
When printing a receipt with a QR code on an iOS device, the QR code was
too small and couldn't be scanned
Steps to reproduce:
- Setup an ePos printer for the PoS
- Activate QRCode on receipt option
- Start a PoS session on an iOS device
- Add some product to the order and validate it
- On the receipt screen click on the print button
- Try to scan the QR Code on the ticket (it's probably too small)
Note:
If you don't have an iOS device you can use browserstack and use ngrok
to expose your local server to the internet and connect to it on
browserstack. You can do the same process to expose the printer so that
you will be able to print from browserstack.
opw-3788988
closesodoo/odoo#159185
X-original-commit: 7fff77b5b60e15f20622ce0a9c6dbe28e25e2660
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Example of steps:
- Open any record with a chatter
- Log a note
- Edit it
- Try to save
Actually it is impossible to save it, because we can not
perform a CTRL+ENTER in mobile and there is no button
This commit adds a button to save editing, using `fa-paper-plane`
icon similarly to send button.
opw-3784145
closesodoo/odoo#159092
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
1. When an empty heading from H4 to H6 is the only element in the editable
area, the backspace key doesn't turn it into paragraphs.
2. When the cursor is at the start of a heading element with text content, and the
user hits the backspace key, the element gets converted into a paragraph.
After this commit:
All heading elements are removed on backspace if they're empty.
task-3456815
closesodoo/odoo#158970
X-original-commit: 6a52ac3d76a23f47bcebcc43603e2963ea52521e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
**Current behavior:**
Trying to select the Algerian fiscal localization for a company
after installing the respective module is impossible.
**Expected behavior:**
The localization package should be installable after the module
has been installed.
**Steps to reproduce:**
1. Install `l10n_dz` and create a new company without any fiscal
localization
2. In the fresh company, select `Algeria` as the fiscal
localization package, observe the error
**Cause of the issue:**
Two tax names in the module's tax data file have the same values
for a field that should be unique.
**Fix:**
Change the values in the identical fields.
opw-3787096
closesodoo/odoo#158877
X-original-commit: 122d9e8827ef26f72ff967b164ec550d349a6ee4
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Before this commit, if a button had the attribute special="close" on the
footer of an x2many dialog, the dialog was not closed.
This occurs because the view button hook searches the dialog close
functions put in the environment by the dialog component, and in this
case is another component that initialize the hook, and the function is
not found.
Now, the view button hook will use the dialog close function put in the
environment by the dialog service.
closesodoo/odoo#159121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue
-----
The sale confirmation mail template is not rendered because a part of code is translated.
Note: there's currently no Norwegian translation on Transifex for versions after 16.3
opw-3809578
closesodoo/odoo#159082
X-original-commit: f4a0c70f3fc42fff94c8d259a828f1a1b37e0b1b
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Create a Loyalty program:
- Program Type: Loyalty Cards
- Rules: 0.01 per $ spent
- Reward: 1.00 per point on cheapest product
Make a SO with total 339
Loyalty Card will get 3.39 points
Make a SO with line having
- Unit Price 140
- Tax 15%
- Total will be 161
Hit Promotions
Issue:
The system will add a discount line with unit price 5.0.
With 15% taxes applied the total discount will be 5.75
While it should be 5
Order 1, Total with tax 339 => 3.39 loyalty points
Order 2, Total with tax 161 => 1.41 loyalty points from current order
+ 3.39 from past order
= 5.00 total loyalty points
When applying the discount on Order 2 the system converts 5 points to 5$,
but considering 15% tax included, the price unit of the discount line
should be 4.35
opw-3642795
closesodoo/odoo#159227
X-original-commit: 5888145b6cc27ccf0c963cf00971d386f0433a11
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue
where the volume and weight were incorrectly computed
for carriers based on rules.
But it was done by changing the method api, which
seems to break some custom modules using/extending
the modified methods.
This commit reverts the API change, conveying the
needed information through the context for now
(the api change will be done in master only).
opw-3826165
closesodoo/odoo#159220
X-original-commit: d6e004b23822e98e8d1052b75b66a7d4f6d2c38c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa,
adding by default the filter `sale_order_id`
which does:
```py
<field name="sale_order_id" string="Sale Order"
filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]"
/>
```
becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes:
```py
[
"&",
"&",
"&",
[
"project_id",
"!=",
false
],
[
"display_in_project",
"=",
true
],
[
"id",
"in",
[
3341211,
3526685,
3692221
]
],
"|",
[
"sale_order_id",
"ilike",
"SO2023/123456"
],
[
"sale_line_id",
"ilike",
"SO2023/123456"
]
]
```
which makes an "AND" connection between the task ids domain leaf and the
sale order name ilike leaves, and all these task ids will come from
these SO names, making the AND useless.
In addition to be useless, it downgrades the performance.
On Odoo.com,
- with the filter `sale_order_id`: 15473 ms
- without the filter `sale_order_id`: 39ms
opw-3752003
closesodoo/odoo#159205
X-original-commit: 1a9302dc3a9b0d9323612c10e0f3a91300bb89fd
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Prior to this commit, `oi` icons were not adapted when RTL was defined
in frontend.
This is because RTL adaptations were defined in the backend bundle.
This commit moves the RTL adaptations to be used wherever `oi` icons can
be defined.
Steps to reproduce :
- Enter in edit mode
- Drag and drop an image gallery and a carousel snippet
- Navigate to the theme tab
- Add an RTL language (Arabic, for instance)
Bugs :
- The image gallery displays inverted chevrons
- The carousel's chevrons are correct, but clicking on "previous"
displays the next picture, and vice versa.
Also, some icons a bit everywhere in the apps were not rotated either.
For instance, the back button a forum post to go back to the forum.
Note that task-3714335 will replace FA icons by BS icons, and will
triple check Odoo icons at the same time, to ensure all Odoo icons are
available in the frontend and correctly imported. For instance,
`oi-spin` and `oi-pulse` could make sense in the frontend too.
opw-3747848
task-3794966
closesodoo/odoo#159150
X-original-commit: fc105130551cf9897c7a0a78baf4458e6d5e6fd8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
**Current behavior:**
In the jobs/ directory on the website, if a position has a
location set in its configuration, the 'Location' label will
display the name of the company rather than the city where it is
located.
**Expected behavior:**
The city will be displayed under the 'Location' label.
**Steps to reproduce:**
1. In the Recruitment app, give a job a location value
2. On the website, go to the jobs/ directory and navigate to the
position from step 1
3. Click 'Apply Now!' and look at the location label on the
right side of the page
**Cause of the issue:**
This field was missing the "contact" widget type in its
t-options.
**Fix:**
Add the widget type and additionally display "Remote" for the
location when there is no location set.
opw-3761348
closesodoo/odoo#159149
X-original-commit: fdb07fa0e67cacbcaee9ef99bbb3b315cd6baaf5
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
temo-odoo