If we use the auto-complete feature to add PO's lines to an bill or we select multiple PO's then use
'create bill' button, the generated invoice line will copy the sequence line from the PO's line. This
can lead to situation where we will have all the first lines of each PO then all the second, etc, ending
with a mix of all PO's in the bill.
Example:
Purchase order 1
- seq 10 line A
- seq 11 line B
- seq 12 line C
Purchase order 2
- seq 10 line A'
- seq 11 line B'
- seq 12 line C'
Invoice created from those PO's
- seq 10 PO1:line A
- seq 10 PO2:line A'
- seq 11 PO1:line B
- seq 11 PO2:line B'
- seq 12 PO1:line C
- seq 12 PO2:line C'
After this PR this PR the lines from the same PO's will be contiguous like:
Invoice created from those PO 1 and 2
- seq 10 PO1:line A
- seq 11 PO1:line B
- seq 12 PO1:line C
- seq 13 PO2:line A'
- seq 14 PO2:line B'
- seq 15 PO2:line C'
opw-2749682
closesodoo/odoo#95343
X-original-commit: cafe5c1aff1ca1632ce4924a6b027629c283a5e9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>
Rationale
Due to business decisions mass mailing themes are moved to community repository.
As some other moves are planned, notably coupon or mobile UI that are coming
to community repository, this makes sense to have mailing templates along
with the mobile UI.
Having a responsive and mailing-friendly mailing is now part of community
standards.
For any questions please refer to decision makers.
Task-2903948
closesodoo/odoo#95379
X-original-commit: 58ec2382e4e16ca8cff468a7d731d1de84df66ff
Related: odoo/enterprise#29142
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Complement of this commit 7d7c53edf714a07409316750b2b09deaa089a12d
because added records were missed during fw-port.
opw-2862296
opw-2877133
closesodoo/odoo#95374
X-original-commit: 0ec6629de721042ed215e0e011fe38daddccb0d5
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Before this commit
There is an issue about the translatable field button not properly
shown.
A translatable field <input/> or <textarea/> should have a right padding
in order to ensure its text content does not go behind the translate
button.
After this commit
Existing style regarding this is reapplied.
Part-of: odoo/odoo#94952
Before this commit
On an empty kanban having a record in quick creation, if a user manage
to give the focus somewhere inside the bottom-left zone of the control
panel (or inside the searchview input) WITHOUT closing the form of the
record in quick creation, and then press the ArrowDown key on its
keyboard, a traceback appears.
How to reproduce?
- i.e. go to "Social Marketing > Campaigns"
- change the filter to show no records
- click on create
- make the record dirty BUT invalid (no value for the Responsible field)
- click on the search input
- press arrow down
- => traceback
After this commit
The traceback is not shown anymore because the kanban renderer makes a
safer check before trying to focus a kanban card.
Part-of: odoo/odoo#94952
Before this commit
When defining a view button in some view arch, the combination of its
class attribute with a `t-attf-class` is not correctly handled.
After this commit
This is fixed.
Part-of: odoo/odoo#94952
Before this commit
The view compiler and the kanban compiler both have code to handle
string interpolation.
After this commit
The code is reworked and factorized in a single place.
Part-of: odoo/odoo#94952
For the few remaining uses of the legacy kanban view, the utm addon
style wasn't applied.
This is due to the fact that the legacy kanban view does not have a
"o_kanban_renderer" class.
Part-of: odoo/odoo#94952
Before this commit
The quick create form view uses the new wowl form renderer, but
with the CSS style of the legacy form view.
This led to some issues, i.e. the width of some input fields
were ridiculously small.
After this commit
The quick create form view still uses the new form renderer, but with
the proper class "o_wowl_form_view" to ensure the proper style is
applied.
Part-of: odoo/odoo#94952
Since #91909, the settings form view is tested with different levels
of access rights, post install.
But when the test is run with only the base module, it crashes because
the settings view specified in base is empty, without any field.
On save, the test form reads the view fields, but read fallbacks on
all fields if no field is specified, and it breaks when we try to
compare the read results to the fields requested (empty).
This commit skips the read when no fields is present in the view.
closesodoo/odoo#95340
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The urgentSave fix at f9d27d41 was broken by 9e02cec48.
Do not wait for the resolution of the cleanForSave promise to update
the internal value in case this happens during an urgentSave as the
beforeunload event does not play well with asynchronicity. It is
better to have a partially cleared value than to lose changes. When
this function is called outside of an urgentSave context, the full
cleaning is still awaited below and `_super` will reupdate the value.
Task-2861050
closesodoo/odoo#95336
X-original-commit: 0483a778a4032fe2264cfdd5f037834cfb903845
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Pasting a list within a list resulted in wrongly nested li elements
(<li><li>text</li></li>). This applies the same principles for pasting
lists within lists as were already applied for blocks within paragraphs.
task-2879892
closesodoo/odoo#95331
X-original-commit: 49058d63b7a8d03c9b6e323cac19b66bf542a5b3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This refactors the insertion loops in the insert command, in order to
make it more maintainable.
X-original-commit: cb87020ab4e893ca62a677c9104f16c3aa9938cf
Part-of: odoo/odoo#95331
Pasting blocks at the beginning of the editable pasted the content in
the wrong place (after the first node instead of before it).
task-2879892
X-original-commit: f810b11204a3e227d7ac98429f21b2ddf93de215
Part-of: odoo/odoo#95331
`.o-isInFormSheetBg` and `.o-aside` are mutually exclusive.
Part of task-2871070
closesodoo/odoo#95323
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Purpose of this commit to fix the UI in Manufacture app.
So, in this commit done following changes As suggested in Task:
- Able to expand next activity column of MO list view
- Added tooltip of default capacity field on work center
- Added quantity tooltip of BOM
TaskID - 2689994
closesodoo/odoo#95315
X-original-commit: 463a81eb325f624e8947f1b3444947f8ba1dc24b
Related: odoo/enterprise#29113
Signed-off-by: Tiffany Chang <tic@odoo.com>
Now the way of access to an action is using the method `_for_xml_id` of
the model `ir.actions.actions` and not reading the action itself because
they need the access of the group "Administration/Settings" which not
all the users have it, so we were having an error with users that have
the permissions to see MRP Picking Types but they didn't have the group
mentioned above.
closesodoo/odoo#95312
X-original-commit: 1554fc9f8a98f4723b4f3cc1a8c0bd772c317ce5
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit wire transfer was using this line to generate qr code
`payment_tx_id.acquirer_id.sudo().journal_id.bank_account_id.build_qr_code_base64`
But this is a problem has transfert doesn't use `journal_id`.
Instead we can use the bank_id of the company's partner_id.
opw-2855065
closesodoo/odoo#95279
X-original-commit: 15a5bc956ad865d4a6ebb001b5767a5009533782
Signed-off-by: William André (wan) <wan@odoo.com>
Commit [1] made a mistake of copy/pasting the "list_website_pages" ID in
two views related to the "search in everything" and "search in pages"
views (used when checking all results after a search using the "search"
snippet that you can configure to search in everything or in pages).
At the time, that ID induced some CSS rules and JS related to the page
manager (not made for visitors).
- For the "search in everything" page, both the CSS rules and JS had no
effect (except instantiating an useless widget in JS).
- For the "search in pages" page, the JS had no effect (except the same
instantiation of an useless widget) but the CSS had an impact on the
`<table>` used to display the results:
- The header used an hardcoded odoo-purple background color.
- The table paddings were not the ones defined by the theme.
Of course, in custos, more of the CSS could have had an impact (for
example some icons would use bootstrap blue info color by default for
no apparent reason).
Since [2], the page manager was removed (converted into a backend view)
so the CSS and JS rules actually became totally useless. The JS was
removed with [2] but the CSS was kept thinking it was necessary for the
"search in everything" and "search in pages" pages.
This commit removes the useless CSS and the useless ID in the two views.
It also modifies the "search in pages" layout a bit.
A fix could be made in stable later on to at least remove the hardcoded
odoo-purple background color in the "search in pages" page. The rest
should stay as per-stable policy.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#95272
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Hide the 'Pay Now' button for invoices which transactions total amount
equals their total amount.
When the total amount of all transactions related to the invoice is
equal to or greater than the total amount of said invoice, the 'Pay Now'
button should no longer be displayed.
task-2527323
closesodoo/odoo#95262
X-original-commit: de81225d39e7951ea9a63e24bab3a0138a6942e3
Signed-off-by: Achraf <abz@odoo.com>
Correct "Status" position in the account_portal header
opw-2817794
X-original-commit: acf1003d46360bff23b605ccb77a44d099f1c1a8
Part-of: odoo/odoo#95262
Problem:
In a kanban view with progress bars, have
- a record with a false value for the progress bar field
- "muted" be the color of a progress bar field value different from false
a crash occurs.
This happens because no fallback is found for value = false in
findProgressValueFromRecord.
Solution:
Always add a bar for the value false (as it was the case before).
closesodoo/odoo#95215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Both the CE and EE web clients don't support proper responsivity when a subtree view is inside a `<group>`.
By removing them (they were unnecessary anyway) we recover proper responsivity in these views.
@moduon MT-688 OPW-2843895
closesodoo/odoo#90946
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Enable “Expiration date” in inventory settings
- Create a Storable product “P1”
- Tracking: by serial number
- Enable the expiration date option
- Update the quantity:
- Create a new Lot “SN1”:
- select today's date as the alert date
- Go to inventory > reporting > Inventory Report
- Try to filter by “Expiration Alerts”
Problem:
The product P1 is not selected, because the filter checks the removal
date instead of the alert date
Solution:
The filter should check if the alert date is less than or equal
to today's date to display products or not, as it is for lots:
https://github.com/odoo/odoo/blob/14.0/addons/product_expiry/views/production_lot_views.xml#L30-L39
opw-2889737
closesodoo/odoo#95289
X-original-commit: 1c04bc5407f02c7299b86a7f4fef207f4aa01c77
Signed-off-by: Christophe Simonis <chs@odoo.com>
*base, event, hr_holidays
Before this commit, `<t t-set/>` nodes declared outside the main
div of a kanban card where ignored by the kanban compiler. This
commit fixes that issue. To do so, we refactor a bit the way the
compiler and KanbanRecord handle multiple root cards (typically,
several roots with a t-if/t-elif/t-else, s.t. there's a unique
rendered root), by removing the faulty logic from the compiler
that identified card root nodes (and filtered out t-set nodes),
and introducing a div for the KanbanRecord component on which we
can set classNames, attributes and handlers.
The issue could be observed on the Apps kanban view, as it
displayed the "Install" button, whether the app was already
installed or not.
closesodoo/odoo#95211
Signed-off-by: Géry Debongnie <ged@odoo.com>
When freezegun is used, the profiler and sql_db time are freezed,
Making the profile and sql perf counters invalids.
A possible solution would be to black list some modules in freezegun but
this doens't look possible in the pinned version (0.3.x).
Saving the builtin time.time is not enough, it looks like freezegun will
find all occurences and replace them.
We need to get the __call__ instead.
closesodoo/odoo#95100
X-original-commit: 9ac5fdf1e6d00e6e4b4ff4b6e94a3cd28f8cae11
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Because method _read() no longer updates existing values in memory,
those values in memory must be consistent with the database.
On the other hand, if pending updates are not performed on the database
before fetching values, it means that the corresponding database values
cannot be put in cache. This implies that one cannot empty the cache
without flushing the corresponding fields.
In order to avoid mistakes, flush automatically before invalidating the
cache. This makes the invalidation methods safe by default, and avoids
cargo-culting which would systematically associate invalidation to
flushing, which may eventually be less performant.
Part-of: odoo/odoo#66938
The idea is to avoid flushing the fields to fetch in method _read().
This delays UPDATE queries, and makes the prefetching mechanism simpler
and more effective.
We do this by not overwriting the cache values by the values fetched
from database. This simple idea allows to fetch more fields and more
records without having to care about pending computations and updates.
But it requires the cache consistency to be much more strict, because
nothing will "fix" the cache inconsistencies "by chance". And it also
requires pending updates to be present in cache.
Part-of: odoo/odoo#66938
Move the definition of class Query to odoo.tools, in order to avoid
circular imports when importing Query in core Odoo modules.
Also reorganize imports in the impacted modules.
Part-of: odoo/odoo#66938
Because MobileSaleOrderManagementScreen is rendered inside
SaleOrderManagementScreen, the `useListener` calls in
SaleOrderManagementScreen are called twice. This is because
MobileSaleOrderManagementScreen is derived from
SaleOrderManagementScreen. Because of this, when an event is triggered
in the SaleOrderManagementScreen, say the 'click-sale-order', the
handlers are called twice. To fix this, we should not render
MobileSaleOrderManagementScreen inside the SaleOrderManagementScreen
anymore. Instead, depending on the screen size of the device, identified
using `env.isMobile`, we show the appropriate screen, that is, when
`isMobile` is true, we show MobileSaleOrderManagementScreen otherwise,
we show SaleOrderManagementScreen.
closesodoo/odoo#95282
X-original-commit: 6a8a43d09a798be3dfc5581561b67bc5c5521634
Signed-off-by: Masereel Pierre <pim@odoo.com>
When opening the sale order management screen, we should always start
with the default domain so that we don't have instances where fully-paid
sale orders show in the screen.
X-original-commit: 5b8cff6a545d1fb3ee614cdd347e0aa463dc8a5e
Part-of: odoo/odoo#95282
When in mobile view, the sale order management screen don't show when
clicking the Quotations button.
This change fixes this problem. Check the comments in the changes for
more details.
X-original-commit: 4ac8c363213dec747a7ca1bf5f2b22c6e2c6abf2
Part-of: odoo/odoo#95282
Because the setup method is not properly executed, sale order management
screen crashes when viewed in mobile screen.
X-original-commit: c27716c97c4d32bb0b12f3772ea55941fa423c63
Part-of: odoo/odoo#95282
Have a Peru company setup
Create 2+ draft invoices of mixed type 'Boleta' and 'Factura'
In list view select the created moves and do action>"post entries"
The posted entries will have the same name prefix, either all 'BOL' or
'FFI', depending on the first computed name, the system will use the
same prefix for the remaining move names
opw-2860231
closesodoo/odoo#95271
X-original-commit: d7a5b34e46436f49592ab6706ac33bcf7a3fbf80
Signed-off-by: William André (wan) <wan@odoo.com>
Only users with admin rights are able to confirm and send an invoice to
the SII
Steps to reproduce:
1. Install l10n_es_edi_sii module
2. Switch to company 'ES Company'
3. Go to Settings > Invoicing > Spain Localization > Registro de Libros
connection SII and select 'Hacienda Foral de Gipuzkoa'
4. Go to Invoicing > Configuration > Accounting > Journals and open
'Customer Invoices'. In the 'Advanced Settings' tab, enable EDI
functionality 'SII IVA Llevanza de libros registro (ES)'
5. Go to Invoicing > Configuration > Spain > Certificate (ES) and import
the certificate (file named sello_entidad_act.p12 in
l10n_es_edi_sii/demo/certificates/) with password "IZDesa2021"
6. Connect as demo in 'ES Company'
7. Create an invoice with any customer and product and confirm it
8. Click on 'Send now', an access error is raised
Solution:
Call `_decode_certificate` with sudo to allow any user to send invoices
to the SII
opw-2767288
closesodoo/odoo#95259
X-original-commit: e3f768c854b41c91de399597f42685eca9534539
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Issues
------
Purchase Dashboard gives wong value for PO in RFQ and RFQ sent when
user's language is not English
Current behavior before PR:
---------------------------
1. Create some RFQ and RFQ Sent to see its statistic in dashboard
2. Swith user language to another one that is other than English
3. Statistic in the dashboard is wrong now
Solution
--------
Passing translated RFQ and RFQ Sent into the dashboard query in stead of
passing pure text without translation.
closesodoo/odoo#95248
X-original-commit: ba8ad25b413151544b85477c9aae858e99c6cfaf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
The bug this code was supposed to fix is no longer reproducible following
recent improvements in the rest of the code.
Part of task-2871070
closesodoo/odoo#95218
Related: odoo/enterprise#29077
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Thomas Beckers