Prevent crash in case `base.default_user` has been deleted.
Note that the user shouldn't be deleted in a first place, but that's
another discussion...
opw-2360615
closesodoo/odoo#60821
X-original-commit: 7342cadcfe8d85edb8a53aef0ecc402dbbc7e935
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this patch, adding a field on a custom model discards all
automated actions on that model. The explanation is relatively simple.
When models are set up in the registry, the classes of custom models are
dropped then recreated. Given that automated actions are implemented as
monkey-patches on model classes, the setup of models simply loses those
monkey-patches, which explains why they stop working on custom models.
The fix introduces an `_unregister_hook()` method, that is expected to
clean up what has been done in `_register_hook()`. When the registry is
ready (i.e., not being loaded), the setup of models first invokes
`_unregister_hook()` on models, proceeds with the setup, and finally
invokes `_register_hook()` to reinstall the hooks.
OPW 2362308
closesodoo/odoo#60833
X-original-commit: 67152bf82da2674179297d32e4cec9dd534fa0c9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE:
It often happens that someone will send you a message, but you don't actually
know who is the person within the company. In this context, it would be
practical to have direct access to that person's public user or employee form
in order to get more information.
SPECIFICATIONS:
on hover, display the name of the user is bold + underlined
if the user clicks on the name, redirect to:
- the employee form if the hr module is installed and if the user is
linked to an employee
- else redirect to the partner form
LINKS:
closes https://github.com/odoo/odoo/pull/58754
task 2252924
closesodoo/odoo#58754
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To reproduce:
1. Start with empty instance with point_of_sale (no demo).
2. Install Indian localization from Invoicing.
3. Start a pos session with that config.
4. Sell a product.
5. Assign a customer to the order.
6. Invoice the order during payment.
7. Validate. [BUG] Empty receipt is shown in the receipt screen.
This is because of empty country field of the pos.config's company.
We modify the check for country code in the receipt template to
account for empty country as fix.
closesodoo/odoo#60814
X-original-commit: 86423e2da90e1d023bd616cbc719c80f087a4206
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
User is not allowed to save an empty name for the customer details.
If tried, an error message is shown. This feature has been accidentally
dropped after the pos-owl-refactoring. We are restoring this behavior
in this commit.
closesodoo/odoo#60813
X-original-commit: 025d2c9685af74f7ef00530966cb5fb306a31085
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
PURPOSE
Improve ui in CRM settings to ease user understanding and using settings.
SPECIFICATIONS
This commit re-organizes some crm related settings groups for better
usability by interchanging their positions and by putting related
groups together.
Crm PLS warning improvement: https://tinyurl.com/y67ug3fr
* Reword PLS explanation and button (followup of 9a57a7edfb)
Settings cleanup: https://tinyurl.com/y5lwqwe6
* Move "Leads" option on the right, next to Recurring revenues;
* Move "Incoming Emails" below "Leads";
* Switch "Visits to Leads" and "Outlook CRM Extension";
LINKS
TaskID - 2351582
closesodoo/odoo#60264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change the logic of the KPI "Day-1" to "Last 24 hours", so new freshly
created data in the free trial are included in the statistics (same for
last week and last month logic). This requires to change from date-based
computation to datetime-based.
Change the URL of the "connect" button from "/web/login" to the root
URL (so the user is not stuck if he didn't activate yet his database).
Task ID-2359406
closesodoo/odoo#60166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Each time the function is called, we append to the same persistent object.
closesodoo/odoo#60808
X-original-commit: d8790cce3e4a23d2b6b1c32d48d5df14fbdcfd33
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
365 * 24 * 60 is not a year, but year/60 ;)
While we fix it, it is the good time to change and use the dedicated
http.STATIC_CACHE_LONG that exists for it.
closesodoo/odoo#60807
X-original-commit: bb4d5bebaf926cbdf6f8842cd1ca0e5850523bf5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If you don't install website_event_meet_quiz or website_event_meet_quiz,
the route will not have sitemap defined.
Now we force the sitemap to False by default.
And let the override choose the presence or not into the sitemap.
It will remove the warning, if your are running test only on website_event
No Sitemap value provided for controller <bound method EventCommunityController.community of
<odoo.addons.website_event.controllers.community.EventCommunityController object at 0x7ff889bd3668>>
(/event/<model("event.event"):event>/community)
closesodoo/odoo#60806
X-original-commit: 7c7c40f6248b15274afd0cd75d0be28d1ccb1e8f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create SO 1:
- Section A, sequence 10
- Product A, sequence 11
- Create SO 2:
- Section B, sequence 10
- Product B, sequence 11
- Select both SO
- Create the invoice
The resulting invoice lines are organized as follow:
- Section A, sequence 10
- Section B, sequence 10
- Product A, sequence 11
- Product B, sequence 11
This is obviously not expected as it messes up the organization of the
lines.
This happens because the sequences of the SO lines are kept at invoice
creation, while it is necessary to resequence the invoice lines to keep
them organized.
To do so, we loop on the invoice lines before their creation in order to
assign a sequence corresponding to the order in which they have been
added in the list. Since the invoice lines are added one SO after the
other, this allows us to keep the appropriate ordering.
Note that we only resequence if there are less invoices to create than
SO, meaning that several SO have been merged. Indeed, in case a single
invoice is created from a single SO, there is no need to resequence.
This assumption is not completely true: if not all selected SO were
invoiceable, the number of invoices created is also smaller than the
number of SO. However, resequencing should be safe so in the worst case
we might resequence an invoice while it was not necessary.
We also leave the possibility for third-party addons to alter the
resequencing thanks to the `_get_invoice_line_sequence` method.
opw-2363443
closesodoo/odoo#60789
X-original-commit: 97c2f5ea51a669830b3e6d6d2d7d857742a41481
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit,Widget "qty_at_date_widget" was only displayed on Sales order line form view.
Now we are showing Widget "qty_at_date_widget" on Sales order line form view as well. (https://prnt.sc/v5inaw)
closesodoo/odoo#60797
X-original-commit: c5b72032d97df28c4797ea3b21995d685b3006aa
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit fixes few of the strings / layout for the settings related
to CRM and makes it less technical and thus more understandable and
also updates the required translation strings.
TaskID - 2351582
closesodoo/odoo#60790
X-original-commit: 55b05ed5e2cf083ac1e6d807d59e5533f4fb94b6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit updates the description_picking on stock moves once the
picking type is changed. This is needed to merge stock moves at
confirmation. The description_picking field chosen on the merged move is
the 'minimum one'. Empty string will always be chosen that way, so we
lose the information.
closesodoo/odoo#60762
X-original-commit: a3dad0f892b5394124763ceb13305fca745c95b9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit the layout of the website sale dashboard in community
was broken because it contained nested h2 headers
After this commit the layout of the website sale dashboard in community
is back to normal
Related to #26067closesodoo/odoo#60763
X-original-commit: 299d6ecd6e27f252c54370f59b2c4707014d7abb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
TLDR: zero is not always zero in js
STEPS:
* On your POS, add a Cash rounding > Rounding precision 0.10 > Rounding method
DOWN
* Set a product with a Unit of Measure with 3 decimals (kg for instance)
* In POS:
- Make an order for 0.514 kg at 429.99€ + 0.510 kg at 429.99 + 0.60€
- The total of the order is 440.90 (exact total would be 440.90976)
BEFORE: The total to pay is 440.80
AFTER: The total to pay is 440.90
WHY:
* var total = round_pr(this.get_total_with_tax(), this.pos.cash_rounding[0].rounding);
// 440.90000000000003
* var rounding_applied = total - this.get_total_with_tax();
// 5.684341886080802e-14
---
opw-2357917
closesodoo/odoo#60754
X-original-commit: 262a9dc935d74b30ffeaff6d6d88aac150793d6e
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If a merchants didn't enable a local Payment Method Type (PMT) on Stripe
side (such as bancontact), his customers eligible for it (ex.: Belgian
and paying in EUR) won't be able to pay using it.
This commit fixes this issue by adding a condition on the payment icons
assigned to Stripe: if the payment icon related to a given payment
method is not listed as a supported payment icon, the related payment
method is not offered to customers, unless the payment icon does not
exist at all.
User can enable PMTs through (Payment Acquirers > Stripe
> Configuration > Supported Payment Icons). This concerns: ideal,
bancontact, eps, giropay and p24.
This solution is not entirely satisfactory but it isn't possible to
fetch enabled PMT from Stripe.
opw-2335482
closesodoo/odoo#60740
X-original-commit: 1d0f23599bbd425c81131a5f6c1c22531ffcd0ee
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Zip cannot be required if not in format address.
It will break ecommerce, because the customer cannot
validate the adress because zip code is not displayed but required.
Fix case in JS where field is not display to avoid traceback.
This commit closes#58950closesodoo/odoo#60704
X-original-commit: 2d31892081a48c521357cef974ea23fc9228a39e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, completing an activity that was automatically
generating new activities was causing a crash as no action is returned
when they are completed.
This commit fixes this issue by handling the case where no action is
returned.
opw-2361674
closesodoo/odoo#60732
X-original-commit: ce6f6fb4e04746d28e1b959d50f50a855c7a3049
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds a test for the fix odoo/odoo/pull/58769 that
ensures that the chatter is properly cleared when creating a new record.
task-2348472
closesodoo/odoo#60731
X-original-commit: 5e46850072f142fb17b72d8738dc4f1c60e3a786
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently when unbuild a MO, we create journal entries the same as
receiving components (add credit to input account) and deliver
finished product (add debit to output account). But since the
unbuild is just a revesal of the MO, the journal entries should
alse be revesals.
In this commit, when unbuild a MO, for the journal entry about the
component change, we add credit to the output account, and for the
journal entry of the finished product change, we add debit to input
account make sure the journal entries are also reversals.
Task 2312828
PR #58150closesodoo/odoo#60730
X-original-commit: 83a3230706e1e2f4eaf9718156647821341d192b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit adds an easy improvement fixing a page speed warning: the
font awesome font (declared in a font-face in assets_common) can be
preloaded.
The only problematic point was that font-awesome defines the font by
a series of URL using different font formats. Only one can be
preloaded (otherwise you would load files for no reason). As all Odoo
supported browsers use the woff2 format, we only preload that one. At
the cost of a warning for other browsers which use a different format.
task-2350647
closesodoo/odoo#60715
X-original-commit: 60c787679260a97c58f399af1a51d7549429f979
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using or importing the ABCs from 'collections' instead of from 'collections.abc'
is deprecated since Python 3.3, and in 3.9 it will stop working.
closesodoo/odoo#60728
X-original-commit: b6907f8fad3b27400a4c2e4a046ed0f02869f863
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Thomas Dieuzeide <tdi-odoo@users.noreply.github.com>
- Create a user A with access rights to Project set as 'User'
- As user A, add a follower to a task
An AccessError is raised.
It happens because `allowed_user_ids` has the group
`project.group_project_manager`.
Since a Project User is allowed to set followers on a task, it is
legitimate to set the appropriate portal user as allowed.
opw-2369674
closesodoo/odoo#60725
X-original-commit: 5ee045b2532ce97094dea2fe6b5e354585d67691
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a sale order with a service configured with
- Service Invoicing Policy: Timesheets on tasks
- Service Tracking: Create a new project but no task
Save and confirm. Access the project and the tasks via smart button.
Create a new task.
The task will not be saved under the current project because there is no
data reference in context.
opw-2355547
closesodoo/odoo#60692
X-original-commit: 51ce1d6ca479b4d851eacef70212bf890588e1c7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit, There would be Traceback (AttributeError: 'bool' object has no attribute 'date')
on `Confirm Receipt Date` If order has no `Receipt Date`.
Now, Button `Confirm Receipt Date` will be hidden if there is not `Receipt Date` to confirm.
Closed#60222closesodoo/odoo#60723
X-original-commit: 6f37f489b065d5534709c0eaf6c647ab5ad469df
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a snippet is out of the viewport or hidden, the overlay should
not be visible. Two distinct cases we had:
- When the page is scrolled, the header is sometimes hidden thanks to
tranform: translate(0, -100%); for some kind of effect -> the header
is thus still visible but out of the viewport, any selected snippet
inside that header would still have this overlay enabled so we would
see the move and delete button on the top of the screen.
- When the page is scrolled, with the vertical header, some part of the
header are hidden for the affixed version. If any snippet in those
hidden elements was selected, the overlay is still visible floating.
task-2312878
closesodoo/odoo#60658
X-original-commit: 8a949019fd39c6c07ae5827462ee96e15f3190a1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Thanh Dodeur <tso@odoo.com>
Access of model `stock_production_lot` was already given to the group
group_stock_user in the module stock, with the rule
access_stock_move_user
closesodoo/odoo#60680
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Let's consider a sellable product P published on the shop
- Let's consider a portal user PU adding P in his wishlist W
- Set P with sale_ok = False (meaning unsellable)
- With PU try to see W
Bug:
A 430 error was raised because the product P was not sellable
opw:2362184
closesodoo/odoo#60540
X-original-commit: 8646b0049808036422fec200163a8a4ff1d0df43
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
change
Configure taxcloud, 2+ delivery carrier, card payment
Go to the website shop
Add product to cart
Checkout with USA address
On the Confirm Order page, the tax is computed via TaxCloud and shown on the right.
Pay via payment acquirer site
The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total
This occur because when selecting delivery carrier coupon lines are
recomputed. To be on the safe side with taxcloud, taxes are excluded before
recomputing coupon lines, but never added in this specific flow.
opw-2338103
opw-2362493
opw-2353048
closesodoo/odoo#60570
X-original-commit: f220e66d707654ee76dc343685dee8c2dda68dd5
Related: odoo/enterprise#14351
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install website_sale
- Go to Website > Products > Products and create a Product with "Tax 15.00%" (i.e. Product X)
- Publish the Product on Website
- Go to Invoicing > Configuration > Fiscal Positions
- Create a first Fiscal Position:
* Fiscal Position (Name): Fiscal Position A
* Tax Mapping: Tax 15.00% => Tax 15.00%
- Create a second Fiscal Position:
* Fiscal Position (Name): Fiscal Position B
* Tax Mapping: Tax 15.00% => Tax 0.00%
- Create a Portal User (i.e. User X)
- Go to Contacts and edit User X to set his Fiscal Position to Fiscal Position A
- Connect with User X
- Go to online Shop and add Product X in the cart
- Open "My Cart" => Taxes are displayed correctly
- Process checkout and enter an address, but do not pay
- Disconnect
- Change Fiscal Position of User X to Fiscal Position B
- Reconnect with User X and open "My cart"
- Open "My Cart" => Taxes are displayed as if the Fiscal Position has not been changed
The prices and taxes in the cart are still based on the previous fiscale position.
To fix that, fiscale position of SO will be compared to fiscale position of user,
even if user has not changed.
Howerver, as it is a specific use case, it will only be done if "sale_order_id" is not
in session anymore.
Also the cart from user's last visit will not be reloaded, but a new one will be created,
as it is done when used pricelist is not available anymore.
opw-2300330
closesodoo/odoo#60587
X-original-commit: bd77d0ca35a0ab724d235aca989b9c2357a25caf
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install "Accounting" & "Studio" modules
- Go to "Accounting" and switch studio editor
- Go to "Reports" tab and select "Invoices" report
- Click on any block to edit.
Not possible to edit document.
Cause
Studio cannot parse dynamic `t-call` and therefore not able
to render the corrects hooks to edit the report.
The issue has been introduced by this commit: https://github.com/odoo/odoo/commit/5c5710ae8ea045569fd94504f9d8dd5209f7b662
Solution
In the corresponding localization report template,
add an 'Inheritance Specs' (position="after") that will add a condition
where it will retrieve the rigth report name
in case localization enabled.
opw-2362257
closesodoo/odoo#60660
X-original-commit: ee1580a85c9942e9a98748fa568f9f664c67a320
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When switching immediate payment term to 30% advance then back to immediate payment term, the receivable line is back to its previous value.
This is due to the '_get_fields_onchange_balance' that is not updating correctly the business fields since price_subtotal == amount_currency.
So, when `writing`, debit/credit are removed from the dictionary because the values are the same as before. However, `price_unit` hasn't be updated with the new value and remains as its previous value.
It leads to a recomputation of accounting fields regarding the business fields and then, trigger the unbalanced journal entry.
closesodoo/odoo#60654
X-original-commit: 18b5ad16a442404061b1028c2ffd82f179beaba3
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Issue
- Install "l10n_latam_invoice_document"
- Try to add a credit note to any invoice
Cause
"l10n_latam_manual_document_number" is unitialized when
"l10n_latam_use_documents" is equal to False
Solution
Init "l10n_latam_manual_document_number" to False
opw-2366298
closesodoo/odoo#60656
X-original-commit: 6b5f40f4310f02204d98c58d45f92a27c7fad7c1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a thread with at least 21 replies, click on "show N more replies".
The first time, it does the last 10 replies.
Click again: it appends the same batch of 10 replies to the thread.
The button loads the replies starting from the last reply id,
but this id is not updated after load.
This is because the code searches for a `p.well` in the DOM
assumed to be the `o_mg_read_more` parent (see c40f184).
However, commit 59237ea removed the `.well` class of the parent.
The new button is not found, the old button is not removed, and so it goes.
Forward-Port of 4536764ad52b5b
closesodoo/odoo#60647
X-original-commit: 69dd830a15da2d7e43e6040e26d960d2e941002e
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Behavior prior to this fix:
When archiving the last variant on a template, the product template
stays active (contrary to the comment indicating that `toggle_active`
will archive the related product.template if there is only one active
`product.product`).
Behavior after the fix:
When archiving the last variant on a template, the product template is
archived. When un-archiving that variant, the product template is
unarchived as well, without un-archiving the other variants.
Note: this is a remake of a fix implemented in 77e5472c041e, as that fix
did not correctly count the inactive variants.
opw-2349862
closesodoo/odoo#60641
X-original-commit: 01160ee5e7f726f3035c566a13e26825236dedfd
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
We release a new version of IoT Box.
So we need to update the version.
closesodoo/odoo#60626
X-original-commit: d60a5896e7adaeddf0f41e28d43f9688149927ac
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
We change the OS from Raspbian to Raspberry Pi OS
So we change all occurence of raspbian to raspios
m
X-original-commit: f54f02e208f7f96e89a0b2a68c57570edb0c75d5
Nicolas Martinelli