Issue: All action buttons were the same color.
Solution: Make the snooze button more visible by giving-it
a warning color
Closes Task#2295872
closesodoo/odoo#54508
X-original-commit: d4b7f8b44c8d0d5b07a85cd52ee1648f9068f7b2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The currency of Slovakia is EUR (since 2009).
opw-2293328
closesodoo/odoo#54507
X-original-commit: 7a414dd666ae57285762f059e1c3e3cdb4801a1f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit 30af656e1a removed a third operand
in the domain but forgot to remove its operator, making the domain
filtering on the Participant invalid.
This commit fixes it by removing the ~~first~~ second pipe.
closesodoo/odoo#54504
X-original-commit: 44feadabab601b0df34d504b585abb9339a4a478
Signed-off-by: Christophe Simonis <chs@odoo.com>
1. Idle timer is now reset also for touch events.
2. Using onWillUnmount and onMounted hooks to add event listener to
window for detecting activities is not possible in this situation
because setting the listener depends on a pos.config field
(iface_floorplan) which is only available after 'start' is finished.
(Remember that hooks are required to be set in the constructor.)
So instead of using those hooks, we replicate them by using a global
variable IDLE_TIMER_SETTER. This variable holds the bound method
_setIdleTimer and set it as callback to each event listener.
Then, before closing pos, we remove the listeners.
3. Close present temporary screen when going back to floor screen
after idle timer.
closesodoo/odoo#54498
X-original-commit: de1430d71890da24547fe24ba04dd28f59f77ee0
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Tested in safari, chrome and firefox, removing display: flex property
in the .pads element solves the issue. There is actually no need to
declare .pads to flex-flow in column direction as div are block
elements, and they laid out in column by default.
X-original-commit: 6389f00598fa6acd991b21f9875d27005b689ec6
*: website_blog, website_event
It would make sense to be able to change the height of a cover or to
change the text alignment even if there's no backgroung-image.
Therefore, we're removing the background-image restriction for the
options of the cover snippet.
Part of https://github.com/odoo/odoo/pull/47933
task-2210733
closesodoo/odoo#47933
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: event, website_blog, website_event, website_forum, website_sale,
website_sale_comparison
We're changing most of the "DRAG BUILDING BLOCK HERE" placeholders so
that they only appear on drag. Making the preview as close as possible
to the page once saved. However, we're still keeping them on empty pages
because it make sense there to let know that the area is editable.
Part of https://github.com/odoo/odoo/pull/47933
task-2210733
Co-authored-by: qsm-odoo <qsm@odoo.com>
Small UX improvements on list view and edit text of an empty kanban
screen.
Task ID 2291554
closesodoo/odoo#54234
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The blockquote in its "cover" layout allows to add a background with
a dedicated colored filter on top of it. That option was a bit buggy
since the filter option only appeared if the page was saved first. As
we now have a generic option to apply a colored filter on image
themselves, that option became useless anyway.
Part of https://github.com/odoo/odoo/pull/53930
task-2157252
*: web, mass_mailing, website, website_form, website_sale
New CSS design of the editor (step 1/x).
This work is unfortunately far from perfect but is a first step towards
what we want. In particular, much CSS linked to elements that are meant
to be removed/moved in the upcoming weeks was done in a huge rush but
will thus hopefully be removed/reviewed before the 14.0 release.
As the design is now far more complex including gradients and other
"complex" elements, it was also very difficult to keep a design based on
css-variable so this system was removed, which means that the editor now
appears the same everywhere (backend, frontend, ...). The original goal
of this system was to have an adapted style for backend, frontend and
website visitors. Unfortunately, the current result was a very good
frontend editor design, a not-so-good backend editor design (for mass
mailing at least) and a totally unadapted design for the website
visitors. Making this perfect will be achievable by loading different
assets for those 3 areas and hopefully those assets will only differ by
the values of editor scss variables.
Part of https://github.com/odoo/odoo/pull/53930
task-2157252
Example where this was a problem: when clicking on a field type for
website form, the whole option is rerendered and we never go through the
"close" method of the clicked we-select element (which will be important
in the future).
Part of https://github.com/odoo/odoo/pull/53930
task-2157252
To reproduce, open a pos session. Finalize an order with invoicing.
Error message is shown.
Invoicing in pos calls doAction of the action manager. The first time
doAction is called, it triggers a chain of events and a side effect
of that chain is to instantiate two mail owl components which isn't
possible because not all mail assets are loaded. A very quick fix is
to bypass that mentioned chain of events by setting isStarted flag to be
true. Aside from bypassing the instantiation of mail components, there
are procedures that were skipped as well which includes:
1. setting the bus to listen to scroll events
2. setting odoo.isReady to true
3. adding a class to the action manager element
All of the above is not important in pos and can be skipped so this
quick fix is valid. However, this fix doesn't actually solve the real
problem which is the fact the pos is loading unnecessary assets.
This commit implements the quick fix. Cleaning up pos assets will be
done in the future.
closesodoo/odoo#54478
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In 6e25a510b3 `find_or_create` was
modified to return a recordset rather than just an id. This made it
incompatible with the RPC protocol and it was not annotated to
downgrade the return value back to an id.
Fixesodoo/odoo#54466closesodoo/odoo#54476
X-original-commit: a7e3894e20207b714cebefa908be090967866791
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In the GSTR1 report, Under 6A Export Invoices, the invoice value which
is shown in the report is expressed in invoice currency without any
currency symbol.
This is misleading for users because the GST form report website
asks amounts in company currency (Indian currency)
opw-2292449
closesodoo/odoo#54462
X-original-commit: bb617b70eab3e033c828c2899c139e66ddc8fc28
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
odoo/odoo#34023 added this override to `postprocess_pdf_report`, which
was apparently missed when odoo/odoo#33770 made a few
methods (including this one) RPC-private.
Fix the override so it's properly called again (probably).
Task 2285894
closesodoo/odoo#54448
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
On res.partner.bank, we check that:
- l10n_ch_postal contains a valid postal number
- l10n_ch_isr_subscription_chf contains a valid ISR subscription number
- l10n_ch_isr_subscription_eur contains a valid ISR subscription number
ISR subscriptions numbers are postal numbers but starting with 01 or 03.
Those codes are reserved to ISR issuance.
When the bank account on a Vendor Bill is detected as
an ISR Issuer, check the reference is actually an ISR.
The 27 digits ISR Reference is error prone when typed by hand
and an error at this stage would break the payment process later.
This is required to avoid batch payment error with SEPA.
We prefer using the pretty form xx-yyyyy-z of a postal account.
The Swiss users will identify it more easily.
We always want to auto fill the field l10n_ch_postal when possible from
acc_number, which includes only 2 cases of filling acc_number:
1. a 9 position postal account number
2. an IBAN from PostFinance which includes clearing 09000
Original prs: Closes#51645, #51544, #51560closesodoo/odoo#54455
X-original-commit: f8a3ec438e3b5fa56305db729a78304aec7a6716
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
1. Create a new location of type internal in WH/Test
2. Create a new product P with availability of 100.0 in WH/Stock
3. Create a new transfer from WH/Stock to WH/Test with 50.0 units of P,
Put in Pack and Validate
4. Create a new transfer from WH/Test to WH/Stock/Shelf 1 using the
previous package, Validate and Unpack
5. Repeat steps from 3 and 4
6. Create a new transfer from WH/Stock/Shelf 1 to Customer with 100.0 units of P
7. Review stock quant from the location WH/Stock/Shelf 1
2 quants of the same product in the location WH/Stock/Shelf 1: one
negative with -50.0 and another positive with 50.0
The step 4 creates 2 quants of 50.0 units, which are reserved at step 6.
However, when validating the transfer 100.0 units are taken from one of
the quants.
To prevent this situation, we run the quant vacuum process after
unpacking. This will merge the 2 quants of 50.0 and prevent any future
negative quant creation. We also clean zero quants, although this is not
mandatory to fix our use case.
Closes#53535
opw-2283707
closesodoo/odoo#54431
X-original-commit: f7168311f4333f7fc684e00e1c1c284981718335
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install "Studio" and "Contact" apps
- Edit with Studio the Contact Kanban View
- Add field under city/country
Field appears only if no city is set.
Cause
The new field has as anchor the 5th <li> with the field country
who will appear only if not city is set. However, in case there a city
AND a country, the 6th <li> will appear instead of 5th (the target one).
Solution
Let only one <li>, one country and one city field but with the right conditions.
opw-2288545
closesodoo/odoo#54423
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the default active favorite filter was determined by
its ID given by the control panel. These IDs start at index 0, meaning
that if a condition checks for the value of such an ID, it could be
false even though the ID and its filter exists.
Now the indexation starts at 1 to avoid such problems.
closesodoo/odoo#54435
X-original-commit: cfb7bbea1b428a062ee08ca045509d189b1fd1d4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The payment.transaction type field allows filtering some potential
payment methods down the line of a transaction being created; e.g. if a
subscription product is present in a quote, the payment's type should be
`form_save` to save the payment token for future use on the subscription
that will be created at confirmation.
The transaction that got created by sale flows did not set the type of
the transaction correctly, and this value was not propagated to the
rendering values of the acquirer. It now is.
This is necessary as part of task 2275051, where we need to know which
payment methods to enable in Stripe depending on a need for tokenization
or not (since some methods are not tokenizable).
closesodoo/odoo#54426
X-original-commit: 09dbbd77d83332c48f62b1c36c3b33ddbfa3a4eb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This commit handles 2 things:
1) the merging of the `py_utils.context()` into the evaluation context
returned by `BasicModel._getEvalContext` to access the same time-related
keys,
2) the addition of 2 new keys into the `py_utils.context` (thus
transmitted to the basic model): `today` (an alias for the already
present `current_date`) and `now` which represents the current date and
time value.
Task 2269697
Commit [1] introduced the bug by relying on the fact an element with
id=top is in the edited DOM. As the website header can be disabled, this
induced a crash as soon as the header was indeed disabled. Also, the
editor is not meant to edit the website only so we cannot rely at all
on the presence of a #top element.
[1]: https://github.com/odoo/odoo/commit/6df67a28c2f113572acd4a3db19ab6b1bd37e7daclosesodoo/odoo#54409
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, defining a extension of a template by using the
combination of directives 't-name' and 't-extend' ignored potential
extensions that could have been defined beforehand.
For instance, let's assume the following templates.
```xml
<t t-name="a">
<div><span>1</span></div>
</t>
<t t-extend="a">
<t t-jquery="span" t-operation="replace">
<span>2</span>
</t>
</t>
<t t-name="b" t-extend="a">
<t t-jquery="div" t-operation="append">
<span>b</span>
</t>
</t>
```
Rendering template "b" displayed "1b" whereas we would expect "2b".
Moreover, when the extended template is itself an extension of
another template:
```xml
<t t-name="a">
<div><span>a</span></div>
</t>
<t t-name="b" t-extend="a">
<t t-jquery="div" t-operation="append">
<span>b</span>
</t>
</t>
<t t-name="c" t-extend="b">
<t t-jquery="div" t-operation="append">
<span>c</span>
</t>
</t>
```
Rendering template "a" displayed "a", template "b" displayed "ab",
but template "c" displayed "ac", whereas we would expect "abc".
With this commit, other extensions done to a template are kept when
a new extension is defined. It relies on the templates order, and
takes into account all extensions that have *already* been defined.
This is exactly how the new qweb inheritance mechanism (using
't-inherit' and 't-inherit-mode') behaves.
closesodoo/odoo#54315
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Issue
- Install "Accounting" and "Account Analytic Defaults".
- Create an Analytic Tag and use the distribution (eg.: 60/40)
- Create an Analytic Defaults for a specific partner.
with the Analytc tag just created.
- Create a bill, select the the same partner as the Analytic Defaults and
add a new Invoice Line with a price (eg.: 1000).
The tag is applied to the payable account, which is
wrong and it leads to an analytic inconsistency.
Solution
Apply analytic tags only on move lines not excluded from invoice tab.
opw-2269757
closesodoo/odoo#54410
X-original-commit: 6e0bb7a24cad46891c80ddc384311dd81eca1e82
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Create four promotion programs:
if the order > 1500 than 10% discount
if the order > 1750 than 15% discount
if the order > 2000 than 20% discount
if the order > 2500 than 25% discount
Take a product with a price of $300 and add 5 to cart > the 10% discount
is correctly applied.
Add 1 more product (6) > it should now qualify for 15% discount, but it
stays at 10%
Add 1 more product (7) > it (correctly) gets the 20% discount
The 25% discount does not get applied until 11 of the product is in the
cart, even though it should qualify at 9
If you then decrease the quantity, the right discount will
sometimes display.
This occur because when the order amount change and the new total is
used to match the right promo the previously applied discount is not
removed from the amount.
This occur as side effect of
1d59785 in which the amount has to be
kept in order to avoid discount line removal on cart update.
opw-2285656
closesodoo/odoo#54400
X-original-commit: 28c099e6d5b02518b6b5a0be66b2b74a57f0c936
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
description for tax templates in account_tax_data.xml is not showing a "friendly" customer description for several taxes.
It's common to be requested for changes and being forced to help customers to replace the current tax label by understandable descriptions.
This PR improves that description and makes it easier to understand.
closesodoo/odoo#54402
X-original-commit: f8d55c8e4559264c68155a4a8e3151f6aa045037
Signed-off-by: Josse Colpaert <jco@openerp.com>
Go to eshop with public user
Add items in cart
Checkout, reach shipping and billing address page
Fill the form
Add a coupon
Page will refresh and added content will be lost
This will prevent user from adding a coupon when a form needs to be
filled
opw-2287428
closesodoo/odoo#54396
X-original-commit: 4ed42845624e39c66222cda81f307236a6d5a483
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*mail,point_of_sale,web_editor,website
In the tests, required services are deployed for each test
independently. There is no need to have, in additon, all services
deployed globally. Worse, it could conflict and lead to unexpected
results.
This commit ensures services are no longer deployed globally in
tests. It turns the module 'web.env' into a declarative module with
no side-effect, by moving the service deployment to main.js, which
isn't added to the tests page.
Task 2287397
closesodoo/odoo#53817
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Go to Payments view
Select multiple confirmed payments, click on Actions>Send receipt by
email
Only for the first payment will be sent an email.
This occur because in composition mode 'comment' (the default)
mail composer sens the mail to a single record
Adding a duplicate action to handle multi send
Updating translation accordingly
opw-2278971
closesodoo/odoo#54108
X-original-commit: 11fd7687047b2c17e9464e8415087d9a9fcf58a8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The workorder opening wizard view need a footer to be closed when
clicking on a button.
Task : 2278147
closesodoo/odoo#54364
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Support for the "allow exports" group was implemented by checking the
group in init(), which is sync. Move that check over to willStart
instead.
Also add a default mock for user_has_group (makes it so it always
replies that the user doesn't have the group), and override that
specifically for the group we're interested in in the export tests, so
those tests have access to the Export action / option.
closesodoo/odoo#54254
X-original-commit: 30968ac93373990338c23f49e678d272b8e60c6b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue
- Install Employees & Dashboard
- Add employees to kanban
- Dashboard
- Hover an employee picture
There is only the picture visible
on the page, the remaining space is white.
Cause
I found several issues.
1. The pictures are not shown on hover in employees
But they are on dashboard.
2. $attach = all `.content` and on dashboard there is
2 `.content` so the flyout is append 2 times
3. The move method is trigerred on hover too, it hides
the flyout if we are not in it. But with attachToTarget
we are not in it so it's hidden all time.
4. If everything above is solved, the image is shown but
not at the correct position because the flyout base
position is not top 0, left 0
Solution
1. Reduce the minimum required size to 128px
2. use closest instead of parents
3. Don't hide if we have the option attachToTarget
4. Calculate the flyout offset and replace it correctly
and set it to position fixed to handle scrolling
OPW-2291493
closesodoo/odoo#54333
X-original-commit: 2c6d692ee40c97d2ae63da64db7623702948407e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Aymane (ayt)