This commit enables JS tooling inside the sign module, with the exception of
legacy code.
task-3338273
closesodoo/odoo#122304
Related: odoo/enterprise#41421
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
added sequence + handle for tree view and updated compute
to select company's country's structure type first.
task 3279050
closesodoo/odoo#119810
Related: odoo/enterprise#41190
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Use freeze_time to ensure the tour runs on a date where the employee is
supposed to work.
Fixes runbot build error: 21683
closesodoo/odoo#123010
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit, in the "Chatter", when a user planned an activity,
a new section appeared at the top of the chatter displaying the planned
activities. Users had the ability to collapse this section. When the
section was collapsed, a title and a badge were displayed next to it,
indicating the number of activities.
However, since milk, it was observed that the badge was positioned too
close to the title, requiring some spacing adjustments. Additionally,
the badge has been updated to adhere to milk by adopting a rounded-pill
shape.
task-3339256
part of task-3326263
closesodoo/odoo#122945
X-original-commit: fab1f6242cc0d8984a5f36876dcbf4150c340d8d
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the widget value was updated (based on the current
state) prior to updating the snippet UI. As a result, the widget value
reflected used the non-updated UI labels.
task-3112890
closesodoo/odoo#122810
X-original-commit: edc88a2ab99673427cbeac05246b8e586b121b72
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
This commit allows us to add the events on sales order templates, and then
configure them in the sales order quotations. Users will get an error when
trying to confirm a quotation if events are not configured, and they will
be able to configure said events by clicking on them.
Task-2988003
closesodoo/odoo#116974
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Currently, if you use the automatic entry wizard to change the period of
a journal item dated prior to the lock date, you'll just get blocked
with a UserError, with no workaround.
This commit changes the date of the adjustment entry to be the first end
of month after the lock date. As a result, the adjustment entry can be
created.
Based on PR #92439closesodoo/odoo#122997
Taskid: 2823170
X-original-commit: fdeaff0a879bdf1242ed0a8d85e3e0363dd3276b
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
At the moment, the lock date message is generated in
_compute_tax_lock_date_message. We delegate it to a separate function
in order to use this message elsewhere as well.
Note: this refactor introduces minor changes in behaviour:
- we remove the second part of the lock date message (that mentions
other lock dates than the most blocking one), because it is too much
information.
- we calculate the new accounting date from the existing accounting date
rather than from the existing invoice date. This should not change
anything in practice, since the new accounting date will be the last
day of the period after the lock date.
task-2823170
X-original-commit: aeb6707dfc0f4aa093d7687bbb0e488558d2a99f
Part-of: odoo/odoo#122997
Before this commit, the reversal of a passed exchange
move was not created on the correct date:
- If sequence is reset by month, the reversal should
be created at the end of the month of the exchange
move, and if sequence is reset by year, at the end
of the year.
Steps:
- With a foreign currency X activated and two different
rates few months in the past.
- Create and confirm an invoice with currency X at the
date of the first rate.
- Register a payment at the date of the second rate
(an exchange move is created).
- Unreconcile the payment from the invoice.
-> A reversal of the exchange move is created, but the
date is wrong (set to today's date).
opw-2856385
closesodoo/odoo#122981
X-original-commit: 130832942d4bd40e0c11676b030db6fb794bfbdb
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Previously, validating an order and initiating a print receipt
request, followed by an immediate exit from the receipt screen
caused an error. The error arose when the system attempted to
update the className of a nonexistent element.
This commit resolves this issue by ensuring the element's
existence before attempting any updates.
opw-3329887
closesodoo/odoo#122940
X-original-commit: 2b4553e4c9b7c0a265ae2d256a0ac99b286ee760
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
We are reverting this commit (f9da3590261b304f9c12f01f5800cec50faebc1a) because
it is not compliant to the stable policy and is blocking users that had more than one cash
payment methods in configuring their pos.
opw-3331677
closesodoo/odoo#122882
X-original-commit: 81d995cf5450956e1c664cb5528d98bb9849bb64
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Instead of a message at the top of the page, and a likely
very visible footer, the "thank you" page after giving a rating
is now reworked:
- Only the top of the website footer is now visible
- The message is centered on the page
- Other margin and structure changes
Task-3297161
closesodoo/odoo#120687
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Instead of displaying the feedback field on the rating form
in one of its two columns, we make it go below them in its
own group. As the comment can be very long, this makes the
form / comment much more readable. The max-width of the form
inner group containing the feedback field is set to 100%,
as the default max-width is set to 700px since new Milk design.
( commit 9cd8561bc1011d4224ff0d497290e8f3ec97abc3 )
Task-3297161
Part-of: odoo/odoo#120687
According to Singapore IRD documentation, Box 13 should only involve accounts of type "Income",
Currently, Box 13 calculation is based "Net Profit" which is the combination of Operating incomes, Income, Cost of Revenue, Expenses and Depreciation.
2860997
closesodoo/odoo#123003
X-original-commit: 90190314d31c94abf5d0ba3f40fb5e11c106455e
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
== ISSUE ==
With the refactoring of the `utilities_custom.scss` file, we moved our
custom `bg-*` classes to the `bootstrap_review_backend.scss` file.
While doing this, the `bg-transparent` class actually disappeared.
This commit aims to reintroduce the class in the backend.
== After this commit ==
We reintroduce the `.bg-transparent` class inside
the `bootstrap_review_backend` file. We adopt the default Bootstrap
behavior for `background` classes and use a CSS variable to handle the
opacity.
task-3326297
part of task-3326263
closesodoo/odoo#122995
X-original-commit: 49c0848c4780948d037bbe49aea86dfd0afa27a5
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
=== ISSUE ===
If you open the `Expenses` module, the buttons placed on the left inside
the Control Panel have a custom margin. One of them has a `.mx-1` and
another one has a custom `.gap` defined in the SCSS files.
=== AFTER ===
We remove the `.mx-1` class to replace it with a `.me-1` class, which
is used across Control Panels to space buttons.
We also fix a global issue with the `.o_list_buttons` inside a
`.o_list_view` class, which was adding a gap defined in CSS. Since this
gap is added on top of our `.me-1`, this was generating a higher value
than expected for the margin.
task-3330141
part of task-332626
closesodoo/odoo#122986
X-original-commit: a1d697cc32ef4f94a4a7a89c3b442f58ddb8ecea
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since https://github.com/odoo/odoo/pull/121355,
add_to_compute on no-store compute field, lead to recompute the field
at the end of request and it can lead to some non deterministic bug
(compute with a bad context by example).
Avoid to add_to_compute no-store or no-compute fields.
closesodoo/odoo#122973
X-original-commit: 533193106e6c9460d741e504babc7591cb935939
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock
Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.
After:
The qyt_available for P1 is 5.
closesodoo/odoo#122939
X-original-commit: b32554322d4c26665bdcb29fd58bb95f12faa20e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
**TicketBAI features**
- Generation of XML documents for invoices
- Automatic signing of documents with certificates
- Sending XML to the appropriate tax agency's servers
- Parsing and storing their response
- Preserving the invoice signature chain integrity
- Displaying the TicketBAI QR code on the invoice PDF
- Downloading XSD files for local validation
- Test mode using tax agencies' test servers
**Supported accounting flows**
- Posting and canceling invoices
- Foreign and national customers
- Multi-currency
- Refunds (credit notes)
- Discounts
- Simplified invoicing
**Not supported accounting flows**
- Specific VAT regimes
- Handling of third-party invoices
- XML generation and EDI operations for vendor bills (Bizkaia LROE)
- Modelo 140 (Bizkaia LROE)
- Invoice batching (Bikzaia LROE)
closesodoo/odoo#122691
X-original-commit: f8cad00a6cd5765b6f962909cf849acb1a8aa18b
Signed-off-by: Josse Colpaert <jco@odoo.com>
This way, the demo company is easier to play with as
a certificate is already there.
X-original-commit: 87079e38c388191a8304c2bdf6fa522f7087b654
Part-of: odoo/odoo#122691
Before, if you had multiple lines with noexenta, the lines could
be added multiple times. So, we only add the lines outside of the
for-loop.
For Ticketbai, we also need to make the distinction between S1 (normal)
and S2 (inversion sujeto pasivo) lines, so we return them in different
lists.
X-original-commit: 2fd357a274880e3cf2b33f81414b9145be6807bd
Part-of: odoo/odoo#122691
When we input some string in many2many field under Coins/Bills in configuration
setting of point of sale module . it will give an error with the message -
'could not convert string to float'
Steps to Produce:-
1. Go to Point of Sale then configuration
2. click on 'Settings'
3. Under 'Payment' input some string in Coins/Bills
Trace-back will be generated.
Reason -
The 'name_create' method of the 'pos_bill' model generates an error when a
string is provided as input for the 'name' field, since the expression
'float(name)' is unable to convert a string to a float.
Applying these changes will resolve this issue.
Sentry - 4122478677
closesodoo/odoo#122094
X-original-commit: 8e553f06f1a8e63dbfb4439e989ef27d577ea50f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
Steps to reproduce:
- set up a header with company logo
- print 20 sale orders in arabic
Bug:
header disapears on most pages
Fix:
add a setting to allow users to increase the delay before printing
opw-3217155
closesodoo/odoo#122983
X-original-commit: 68f7cbd15df7839aab146023399da1570b12b441
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When creating an invoice with a positive line and a negative line, with
different taxes, the DatiRiepilogo node for the tax of the negative
line contained positive amounts when they should be negative.
This is because we were applying `abs()` too naively in the XML template
and in the code of _l10n_it_edi_prepare_fatturapa_tax_details.
This bugfix commit changes the logic to no longer use abs().
opw-3316300
closesodoo/odoo#122982
X-original-commit: 0241e96fe12401f0891efc00f840e03d0c0219fd
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
*: base
In the cron updating challenges goals, we were historically filtering
in records of users that logged in since the last update. This doesn't
work because sessions can last a long time, so users are active between
cron runs but their goals are not updated and stale reports were sent.
We temporarily fixed this in v14.0 by updating all goals for internal
users, but this can lead to unnecessary computations too, and still
misses goals of active portal users.
Instead, we are here using the `bus.presence` records to track user
activity, combining it with the session lifetime to avoid indefinitely
fetching old goals that couldn't need an update.
This works for both internal and portal users.
Note: we update stale base comments in favor of exposing bus.presence
to guide developers.
Task-3148858
closesodoo/odoo#121763
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
view
The goal of these changes is to make it easier for the user to manage
their SO. They can create new tickets/timesheets/etc without being
forced to leave the application to open the one they need, nor do they
need to manually link the new record to the SO
task-2954409
closesodoo/odoo#100300
Related: odoo/enterprise#31391
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
User was not able to go through onboarding if they switched company.
By default it tried to edit default payment provider that was conected
to the main company so other companies were recieving Access Error.
opw-3281770
closesodoo/odoo#122590
X-original-commit: ffda55101739f9a99cabd6caee52dcb8d18d8fed
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Group the res_partners in self by placeholder_path value before
calling __setitem__ on each group. Because placeholders are
independent from the recordset, we can set the value
of res_partner[avatar_field] to a placeholder for a recordset
of partners. When self contains lots of partners without
image_field value, this speeds up the _compute_avatar function
noticeably. This in turn speeds up stuff like loading
the Contacts KanbanView (search_read on res_partner).
Example speedup: In a database without any image for the partners,
search_read for avatar_128 with limit=80: 609ms -> 64ms.
opw-3128771
closesodoo/odoo#122884
X-original-commit: 34e97b4c65b7392576d94b870e22e74df14f9dd2
Signed-off-by: Rémy Voet <ryv@odoo.com>
With this commit, Made the tree line clickable instead of clicking View Related
Document Button. Updated the description, to be similar to chatter in audit trail
tree view. Also Updated error message while deleting entries once it's posted for
Indian Company.
closesodoo/odoo#122566
X-original-commit: 8833329191acc56468a62b3f00171c14d0252eb7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nishant Jain(niai) <niai@odoo.com>
Before commit
1. install the localisation module
2. uninstall that module
3. try to install stock
- traceback is generated - https://pastebin.com/eGGYZ1k1
After commit
applying this commit will fix this issue
sentry - 4184561125
closesodoo/odoo#122556
X-original-commit: 95a67a24870f7ca0e9d9f865ce0279aca9fa2699
Signed-off-by: William André (wan) <wan@odoo.com>
The fix introduced in odoo/odoo#114903 created another issue: changing
the work email would change the private email also, breaking the
seperation of the contacts for the employee.
The initial behavior was correct:
- a res.partner for the work details (email, phone, etc.)
- a res.partner (of type private) for the personal details of the
employee.
task-3284664
closesodoo/odoo#122880
X-original-commit: 290465e57dfcb8503e382a418e0ba4498ea5693b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Ensure that, when creating a down-payment invoice for a SO with an incoterm, this invoice should have the same incoterm as the SO.
Steps:
1. Create a SO with an incoterm
2. Create a down-payment invoice for this SO
3. The new invoice should have the same incoterm as the SO
closesodoo/odoo#122770
Opw: 3284556
X-original-commit: d854045c4d25216394a834e44f9948303529c302
Signed-off-by: malv-odoo <malv@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, in a kanban view with a properties field, if the
records have multiple sources for their properties then the view crashes.
Why?
The kanban record tries to make properties accessible from record in the
kanban card. This is not useful, we don't want to be able to do "record.properties.hd32ndls".
Solution:
Properties must not be accessible from records in the kanban card.
How do we reproduce?
- Go to a kanban view with a properties field
- Have a record with property A of type integer and another record which
has no property
Before the commit:
The view crashes because we're trying to format the value of the second
record for property A, which it doesn't know.
After the commit:
The view is displayed correctly.
closesodoo/odoo#122833
X-original-commit: 735f34f29150ab1782f68d77c993dbe3227f998b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.
Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.
[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce
opw-3246341
closesodoo/odoo#122782
X-original-commit: ccaf4f1e52f10308ef507059316732c02ad6e6e4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.
opw-3246341
X-original-commit: 34b3770ad1ee9c872acaf4f82ac3c6cf52d5d333
Part-of: odoo/odoo#122782
When processing several SMLs at once, the 'same product' policy of a
storage category is not respected
To reproduce the issue:
1. In Settings, enable:
- Multi-Step Routes
- Storage Categories
- Packages
2. Create a Storage Category SC:
- Allow New Product: same
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Package type: Pallet
- Store to: WH/Stock
- Having Category: SC
5. Edit the warehouse:
- Incoming Shipments: 2 steps
6. Create two products P01, P02:
- Type: Storable
7. Create a planned receipt R:
- To: WH/Input
- Operations:
- 1 x P01
- 1 x P02
8. Mark R as Todo
9. Create two packages:
- 1 x P01 in PK01 (! PK01 must be a Pallet)
- 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer
Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2
To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.
OPW-3204924
closesodoo/odoo#122767
X-original-commit: 8bde894638838b449d097e7d75092aa15c646c74
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, calendar view in dark theme did not visually
show the disabled date, such as weekends.
In white theme it's fine because bg-view is white, so gray-200 on
white is visible. In dark theme, however, bg-view is identical to
gray-200, so it's not visible.
This commit fixes the issue specifically in dark theme by showing
disabled dates with gray-300.
closesodoo/odoo#122753
X-original-commit: 968b4a284acab3f67f192f1029abbbd1edb2b442
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Attribute Error: 'frozendict' object has no attribute 'default_product_id'
traceback that occurs in stock/stock_quant: action_inventory_at_date
was caught by a sentry.
steps to produce:-
- Install inventory module
- Select any product from the menu item/reporting/stock
- Click replenish button & from that replenish wizard, select the product again
- Then click the forecasted stat button and in forecast click the On Hand button
- Then click Inventory At Date.
At this moment you find a traceback.
Because default_product_id is not getting from the context in inventory.
Applying these changes will resolve this issue.
sentry:-4148733813
closesodoo/odoo#122741
X-original-commit: ca58b13d63702ac2ec8d74b855b90058bf18eb7b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug :
- Add the same google font twice with the font family selector in the
option tab of the editor panel.
- The font will be displayed only once in the font selector menu but 2
trash icons will be added, one for the added font and one for the font
that was already there.
This commit fix this and allows now the user to add the same font twice,
but only to replace a served font by a local font. The opposite does not
make sense, but if the user really wants to replace a local font with a
served, it is always possible by deleting the locale beforehand.
In addition, this commit adds a cloud icon next to the default fonts of
the theme. Since these fonts are served by Google, it is logical to have
the cloud icon. This is consistent with the cloud icon that is present
when the user adds a font served by Google.
task-2998689
closesodoo/odoo#122652
X-original-commit: 948ff01e64e5d71d60d209d074dd6be6510fe794
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The 'frontend_lang' cookie is used to 'cache' the user's preferred lang.
We want to make sure that this language preference is preserved for a
longer period of time than just the life of the browser. This means that
even if you quit your browser and come back into the year, your
preferred language will be used, until you choose to remove your cookies.
The 'utm_*' cookies are used to 'track' where you are coming from on the
instance. The purpose of these cookies is to know the tracking value
to improve the overall user experience or compute the profitability of
some campaigns. Now we keep these cookies for 1 month.
closesodoo/odoo#122573
X-original-commit: 058e0abcf621796bf23d8dcaaf3b2297f632b5fd
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The draft state should only allows setting the initial demand
This commit also allow editing the reserve quantity at the move line
creation
closesodoo/odoo#122445
Task: 3256447
Related: odoo/enterprise#41548
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Viktors Lipskis (vili)