Before this commit, the rows attribute given on the TextField component
was always 2, it is not possible to alter it without overriding the
component.
This commit adds a props to be able to update the rows with a prop
called `rowCount` and this prop can be set via `rows` attribute set on
the field.
task-2947516
X-original-commit: 110915c80c2a2578563283b1744e0e88d80ac4bb
Before this commit, when a component using the `useInputField` hook (for
instance `TextField`) and the `record` is not given in its props, the
hook will crash since it assume the `record` is always defined. However,
the props definition the `record` is optional.
This commit checks if `record` is defined in the component before using
it to be sure to avoid any crash because it is not defined.
task-2947516
X-original-commit: ebe3d00e52dd6097ce55986bc9e3bf9d79ca64cc
This commit converts the list view used in project sharing in OWL and
remove the legacy definition.
task-2947516
X-original-commit: 79159c0c6b715c3acbfb370523b73a664648deb2
The goal of this commit is to add some fixes on page properties dialog
after the Owl REF [1].
- XML: use default form view style (remove </group>).
- Move the '/' back into the non editable part of the URL.
- Prevent python code from creating a different URL (and optionally
setting "website.rewrite" record for it) when the new URL is the same
as the initial one after slugify.
- 'useAutofocus()' on the first page properties field.
[1]: https://github.com/odoo/odoo/commit/61a9d7bd2abc6081b321a51d329f9e85209215e5
task-2687506
closesodoo/odoo#102869
X-original-commit: 1165dfcd4fd5677d14f3d3329ad7c62be847b31a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Problem: If you have a customer assigned to an invoice/quotation
without an e-mail address and then share a payment link with
the customer. If the customer clicks on 'Pay', he won't be
redirected to Stripe's checkout page. He'll get instead 'Invalid
e-mail address: False' (see the image attached).
Explanation:
When there is no e-mail address defined, Odoo sends 'False' to
Stripe but Stripe sees it as the e-mail address which is indeed
Invalid. To solve the issue we replace False by None for the email
value of a customer without email address.
opw-3007866
closesodoo/odoo#102867
X-original-commit: 647a5fd79b88d4ea00eca2d6c1f9d9a2259a8414
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Before this commit: if an event's attendee didn't have a state, it couldn't
get synced with Google.
The solution is first to set a default value for it.
opw-2915661
closesodoo/odoo#102865
X-original-commit: 89b53744c668183913b8a188730bd350fe778807
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Currently, there is no check when deleting an account report that has variants. Deleting such a report leads to variants not being accessible anymore.
When duplicating an account report, the columns are not duplicated and it can be tedious to duplicate them by hand.
There is also a bug when copying lines that have parent lines (no report_id set)
This commit fixes these issues by:
- raising a UserError when trying to delete reports with variants
- duplicating columns when duplicating a report
- correctly setting the report_id for all duplicated lines
Part of the big task fixing bugs in accounting
Task id=2996493
closesodoo/odoo#102846
X-original-commit: a84c7c6f210434dfcbf5c6a316f20981d06a3925
Related: odoo/enterprise#32607
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Popeler Antoine (anpp) <anpp@odoo.com>
Current behaviour:
Currently when settling an account in a POS session, in Saudi Arabia,
there is QR code on the receipt and a title "Simplified Tax Invoice",
which should not be present on settlement
Expected behaviour:
Receipts generated from a settlement in Saudi Arabia localisation shouldn't generate a QR code and a tax title.
Steps to reproduce:
- install the modules: `l10n_sa`, `l10n_sa_pos`, `settle_due`
- Switch to the Saudi Arabia company
- Enter POS and create at least 2 payment method:
- Cash: Identify Customer = false, Journal = Cash
- Customer Balance: Identify Customer = true, Journal = empty
- Create a new POS Session, just add "Customer Balance" to payment methods,
the rest of settings are as default (might need to add "Customer Invoices" to the journal of the session)
- Start a new session, find a customer with some "Amount Due" and click on the value,
choose one of the payment methods
- On the payment screen choose "Customer Balance", now you should have 2 payment lines,
one is the payment methods for settling, the other is the customer balance with a negative value.
- When validating, the receipt has a QR code and Invoice title, when it shouldn't.
Reason for the problem:
There is currently no state that differentiate between a normal order and a settlement.
Fix:
Implement a settlement state (computed) in the localistation order model.
Add the state to the data that goes to the templating engine.
Add conditional rendering for the templates related to the QR code and the "Simplified Tax Invoice" title.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-2976267
closesodoo/odoo#102853
X-original-commit: 0b04230d3c5e7fc1bc83340ec2fca9cf646cbc60
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
Since the merge of Bootstrap 5, the `btn-block` class don't exist
anymore. So we use grid instead to align the buttons.
Steps to reproduce:
* Go to field service
* Create a field service task
* Click on worksheet
* Go back to the task
* Click on sign report
* The buttons are not correctly aligned => BUG
closesodoo/odoo#102714
X-original-commit: af053ab9e21ef86e31c9a27b404658c864df1446
Related: odoo/enterprise#32540
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Since [1] the Plausible dashboard height was hard-coded to avoid the
display of a scrollbar on the iframe.
In case the Plausible dashboard height grows in the future, it will not
be possible to scroll to the bottom elements.
This commit virtually restores the scrollbar, so that in case the
Plausible dashboard grows in the future, the scrollbar will appear and
still give access to the whole dashboard.
[1]: https://github.com/odoo/odoo/commit/b8c1976e933628182496929d348dda11b5051a0c
task-2993773
closesodoo/odoo#102852
X-original-commit: 616eb5384df085fdc94cb18ab8e14336f9b68702
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- set demo to receive notifs in Odoo
- go to employees
- click "launch plan" for demo user
- login as demo user
- Click on the link for the activity that is sent in discuss
Issue:
There is no chatter in the view
Explanation:
the view of en employee coming from messaging is always
hr.employee.public that does not contain the chatter.
opw-2990577
closesodoo/odoo#102851
X-original-commit: 93b95317315a1ba70ce0331c63321ab8eaa487d3
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Rationales:
- having a textual display "Unsaved changes" implied to the user that they
had to save
- having buttons "hiding" behind a hover effect on a span of text was
very unintuitive
- since we don't want an hover anymore, having text buttons would draw a
lot of attentions => use icons + tootltip instead
closes odoo/odoo#102757
Forward-port-of: #102605
Related: odoo/enterprise#32570
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit the creation of the message(s) was done within a for loop in a big function.
Due to this there is no easy nor clean way to override and modify values on the mail.message record(s).
By placing the preparation of message data in a subfunction it can be overwritten and modified as wanted.
closesodoo/odoo#102825
X-original-commit: 6d6d7c12ac456e648bd35645f9617cd1d8ff60e6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In case an employee has multiple contracts in several companies, we need
to only keep the contract of the current company of the employee, as
there can be only one in the main view hr_contract_history.
Before this patch, contract_information CTE returns the same ID for both
contracts:
employee_id | company_id | id | is_under_contract
-------------+------------+--------+-------------------
681 | 1 | 146842 | 0
681 | 14 | 146842 | 0
After the patch, it returns:
employee_id | company_id | id | is_under_contract
-------------+------------+--------+-------------------
681 | 1 | 4009 | 0
681 | 14 | 146842 | 0
We need to fix the WINDOW clause to make sure the id of the contract
that is selected is the one in the same company as the employee/contract
being selected in the contract_information CTE.
This way when an employee has multiple contracts, there will still be
1 line for each contract, but each with a different contract ID.
closesodoo/odoo#102821
X-original-commit: 88fa430be8a0c164e100b5f3c2f16ae906cc9a54
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
When there is too many options inside search view, they didn't wrap and will overflow outside the screen.
closesodoo/odoo#102812
X-original-commit: 8a63d9773b14e212618c3d0d298f0926547e1045
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The RPC that the m2o widgets used by snippet options make are cached at
the widget level. When two m2o widgets make the same RPC, they are
indeed made twice. This commit just move the cache outside of the
widget instance and thus makes it so the same RPC made across multiple
m2o are cached.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC. Then each further drop of snippet made the exact
same RPC for no good reason.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
closesodoo/odoo#102800
X-original-commit: 8e08c896df9ed5a7a0e559f1dbd8812f87908a39
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a snippet option uses a m2m widget, the domain used for the
internal m2o widget which allows to select records evolves to receive
the subdomain `['id', 'not in', <selected-ids>]` with `<selected-ids>`
indicating the m2m records which are already selected.
M2o rpc are cached... based on the whole query object from which they
are created. The domain is part of that query object.
Both those concepts actually conflicted: the initial RPC when no ID is
selected was made with no subdomain, while the subsequent RPC when no ID
is selected were made with the `['id', 'not in', []]` subdomain. The
cache system did treat the resulting domains as different requests. Now
we avoid adding the useless `['id', 'not in', []]` subdomain as it
should already have been done without a cache system in place.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC with the initial domain. Then on click on the
snippet, a new RPC was made with the problematic subdomain, making the
first click on snippets being needlessly slower.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
X-original-commit: 017a468547eafa3e34f584379d3f05b3ed1db487
Part-of: odoo/odoo#102800
The website edition system is based on a main mutex to guarantee the
order of user manipulations. Meaning that if an user follows any flow
really quickly, each part of the flow should be guaranteed to be done
in the order the user asked for, independently from the duration of each
part. The mutex system to ensure that is not robust yet though, or at
least it is not easy to use and should probably be replaced by something
more easier to use in the future. Indeed, some operations are badly
implemented around this mutex.
This is the case of the drag and drop of a snippet into the page. Drag
and dropping a snippet is a long series of operations, to name a few:
1. The user mousedown on a snippet thumbnail
2. The user drags the snippet around
3. The user drops the snippet in a dropzone
4. We scroll the page to the position of the snippet
5. The snippet is built (options' `onBuilt` methods)
6. The snippet public widgets are started
That whole series of operation has to be reduced to an atomic work to
be added to the mutex queue. Meaning that for example, if the user
manages to click on the save button while he is dragging a snippet
around... the editor should only save the page after the whole series
of operations of the drag and drop has completed. This is not the case
right now: the mutex lock is released between (4) and (5) because we
have too: (5) and (6) use the mutex themselves and would thus induce
a deadlock if we only release the mutex after (6) as it should be. This
means that during the scroll to the snippet (4), if the user manages to
click on the save button, the save operation will be scheduled to be
done before (5) and (6). It is thus technically possible to save a
snippet which is not built** (even if it would not be critical most of
the time). Worse, before building a snippet, its options have to be
instantiated... and that operation is not mutex protected so this is
probably (not 100% sure) possible that this happens:
a. Drag and drop a snippet. During the scrolling, click on save.
b. End of scrolling, the mutex lock is released, we create the first
option and its widgets as part of the onBuilt process. Creating each
widget is async, once the first one is created, the saving process
starts as it was scheduled in (a).
c. Saving the content, destroying all snippet options and their widgets.
d. Continuing building snippet options widgets started at (b)... but
previously-made ones were destroyed at (c)... possible crashes***.
Fixing all of this probably requires a change in the system, maybe the
use of multiple mutexes, maybe the saving operation can always be
delayed at the end of the queue somehow, ... but this requires some more
thinking and probably not possible in stable. In stable, it could be
enough to disable the saving entirely during drag and drop (like drag
and drop of another snippet is currently disabled during another drag
and drop). This will be done in another commit if this is decided.
Meanwhile, this commit just changes the behavior in tours for now:
waiting for drag&drop to fully complete before clicking on save, like
an human would.
** It is possible to reproduce by using the ALT + S shortcut: start
dragging a snippet which has a onBuilt method in its options, hover
the dropzone where you will drop, ALT + S to save (the editor waits
you drop your snippet), drop your snippet -> the snippet is saved and
the edit mode is left... but the onBuilt was not executed.
*** a crash was indeed found during a specific theme tour (out of ~30
Odoo themes because of this after the other commit of this current
PR). After those other commits especially, it is also possible to
reproduce with the ALT + S trick, although not consistently. It may
be linked to the specific last snippet added by that theme tour
instantiating specific options. But as explained saving just after
drop is an issue independently from this potential crash problem
(snippet not built, etc).
X-original-commit: e96167ae20d2a143d7def4347166b37e158003b0
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
Commit [1] added back the user context to every RPC called from the
legacy env when it's mapped to the WowlEnv but in doing so, overrode
the params' context keys.
This is incorrect as the params could very well have context params that
are different from the session's params for a reason.
For example, in master, after [2], editing the menus of a website
displayed in a language different from the user's will lead to incorrect
languages in the context when the page is saved. This is cause the
language in which the page is edited is passed as a context param, and
the language of the user is in the session (under the same `lang` key).
[1]: https://github.com/odoo/odoo/commit/d959638e23a92cf880049a760c42da33e5908f41
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 8cdb2293f294558c3bea4ed59a49e0f52b3d217e
Part-of: odoo/odoo#102799
Before this PR, the chat window hidden menu dropdown would have been
opened to the bottom of the corresponding button. The issue is that,
this button is position at the really bottom of the page, causing the
dropdown to be outside of the page.
This PR fixes this issue by adding the missing `data-bs-toggle`
attribute.
task-3011161
closesodoo/odoo#102765
X-original-commit: a4b69feb13852dd13160564bce3b0ae1cb453c0b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
It is technically nearly impossible to delete a company
when it actually dealed with customers
(emitted invoices, received payments, ...).
Hence, if you want to get rid of a company,
for instance because you closed one of your subsidiaries,
giving the possibility to archive your company,
thanks to an active field, would be the best way to go.
We are hesitating to do a related field to the
`partner_id.active`, but we are a bit afraid
some people archive the partner linked to their company
for other valid reasons than get rid of their subsidiary
(such as avoid changing the address of their company
by mistake through the Contacts app),
while still wanting the company itself to be active.
So, we make it an independant column at the moment,
so we have the actual stored column in case we need it,
and will do a related stored to the partner
later on if we change our mind.
Manual forward-port of #102801closesodoo/odoo#102586
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit, sending a message on a livechat whose visitor closed
the chat window would have resulted in a traceback being shown to the
visitor. This was occurring when a message was sent by an operator or the welcome
bot. An other related issue occurred when sending the feedback to the welcome
bot.
This commit fixes those issues by correctly guarding calls to
`publicLivechatGlobal.chatWindow`.
task-3010725
closesodoo/odoo#102752
X-original-commit: 524fc3e4cb0e63029e774e97de687998ccf06909
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
The editor's toolbar is at the very bottom of mass_mailing's sidebar,
making dropdowns pretty awkward as they often require the user to scroll
down to see them. This extends the editor's toolbar for mass_mailing so
all dropdowns become dropups instead.
closesodoo/odoo#102734
X-original-commit: d4b5527113a6092063cba3409d870c5c45a8cd03
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In mass_mailing, the paragraph alignment dropdown menu is wrongly
positioned by Popper since the upgrade to Bootstrap 5. Other dropdowns
in the toolbar had the `data-bs-display="static"` attribute but it seems
that paragraph alignment was omitted by mistake.
task-3002168
X-original-commit: 8a372800b9a035893d9f9ecdf7afce17aef3f1b2
Part-of: odoo/odoo#102734
The iframe in mass_mailing is self-resizing in order to avoid having two
vertical scrollbar side by side. This failed since the conversion to OWL
due to the vertical offset added when resizing having become
insufficient. This adds a class to the <html> element of the iframe to
identify when it's in the context of mass_mailing so we can remove the
overflow visible style that is not needed in this context. This allows
us to remove that vertical offset altogether since the scrollbar
disappeared.
X-original-commit: 4f538911d68afdeca0253f15c9e8ffdbed4e995c
Part-of: odoo/odoo#102734
One of `mass_mailing_tour`'s tooltips was overflowing the body and
causing a horizontal scrollbar. This repositions it so that doesn't
happen.
X-original-commit: 4e2ccb51991cbe4428f084f333c57b78851f73b0
Part-of: odoo/odoo#102734
Before this commit
When clicking on "create" from a form view in mass_mailing, the
"template picker" was not presented.
task-3002100
closesodoo/odoo#102725
X-original-commit: 664d5982663517e8e2f2f87b355fd7d3c72285f1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The "Switch to 1 or 2 weeks calendar" are breaking the layout by
being placed just before attendances_ids on the Working Hours sheet.
With this commit, the buttons are moved in the header of the form.
task-2996235
closesodoo/odoo#102711
X-original-commit: e81e03e6511c4d975bd7da4748f11747faf38251
Related: odoo/enterprise#32539
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
Purpose: The number of 'Late activities' are displayed on the kanban card.
The number excludes the activities for the hired applicants. Yet, once we
click on it, we are redirected to the activity view, which included the
later activities. On the one hand, this is not consistent, but on the
other hand, one might still be interested in those activities later on.
Thus the best way out is to put the filter for the "Running Applicants".
This filter will filter out the applicants in hired stage, but if we are
interested in them, one could just remove the filter.
task - 3001375
closesodoo/odoo#102691
X-original-commit: 16e025de14be3ace07191ab153259ed17b174748
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Gvaladze Sopiko (sgv) <sgv@odoo.com>
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Hides the empty label the same way as the group-by field if it doesn't
need to be shown (no default_location_dest_id/default_location_src_id).
Part of task-2985735
closesodoo/odoo#102759
X-original-commit: 6030147e12b628e8759700058b8ac3c3889007a8
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
This PR adapts the form views since the merge of #100570.
task-3002465
closesodoo/odoo#102750
X-original-commit: 03b7ed51d9bb1e0717d21cd6516f98e477a2c926
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Instead of looking to all partners inside the database, only filter on the ones that are used by accounting operations.
X-original-commit: ce0a37386f03b24f9730b8a05ea45abf6347dc0b
Part-of: odoo/odoo#102733
The full syntax should make use of eval="..." directly in XML. Doing this leads to the fact the formulas, when displayed in the UI, don't contain any call to ref(), but directly the ids obtained from these calls.
Before this commit, the shortcut syntax used to declare the same expressions did not work in the same way and kept an explicit ref() in the formula to evaluate. We now do the same in both places.
We don't want to support explicit ref() in formulas (a user modifying a formula will anyway not know the xmlid to call). The enterprise part of this PR takes care of that.
closesodoo/odoo#102718
X-original-commit: ea291e4d1dea374455cd8a15bf84662278f4a750
Related: odoo/enterprise#32542
Signed-off-by: Laurent Smet <las@odoo.com>
When selecting the "Add to batch" wizard, if a user selected "Add to an
existing batch transfer", the only batches appearing there would be only
draft batches, while it could be added to in_progress batches as well.
It also displayed waves transfers with the batches, so it now only shows
batches.
Also restricted the creation of a batch in the related field since there
is an explicit option to create a new batch transfer.
Somewhat the same for the "Add to wave" wizard as it would display
cancelled waves as well.
Part of task-2985735
closesodoo/odoo#102715
X-original-commit: a8db2c5fe4b2ea1f28c6ea788ac1976678da11aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Within Purchase tab:
- Make Quantity hidden by default.
- Move Currency right after Price.
Move Purchase Description to the right of Vendor Bills.
closesodoo/odoo#102702
Task: 3004014
X-original-commit: b3e78b5a8f825650123004a8b8677aaacfe6b43e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Before this commit, when the day of the month was smaller than 10,
multiple days were highlighted as today on the datepicker.
Now, only the correct day is highlighted.
closesodoo/odoo#102296
X-original-commit: 0545178d5d09f659d5309069ebcae9d7162356a0
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit allows to regenerate the connectors of the step block when
one of the columns of the block is duplicated or deleted.
Steps to reproduce the fixed bug:
- Drop a steps block
- Duplicate one of the columns
=> The last column of the first row has a connector to the right of the
page.
closesodoo/odoo#102797
X-original-commit: 56522f4a26c95878bb726f54eb02c8c948576875
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
For the "+New" button, a `get_modules_info` route was added because the
information cannot be built-in the page by a server-side QWeb template
anymore.
This commit removes this route and replaces it by a call to the default
`search_read`.
task-2687506
closesodoo/odoo#102791
X-original-commit: 7f83e398b68d7c7544753e2b8bb1b334fb5f7036
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Xavier BOL (xbo)