Before this commit, Creating New Employee from User's form was taking default company from the current logged-in User instead of the User for which it Employee is being created.
With this commit, We take default company from User for which employee is created.
closesodoo/odoo#51014
X-original-commit: 9206cc4db2a8dc5a7fbc281c1574f09bfba76544
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Message with type user_notification are special "invisible"
notifications that are not accessible to users normally. That's why they
were excluded from the automatic message deletion in
mail.thread.unlink(), to avoid permission errors. But this caused
orphans leftover notifications in the database, and the fix here is to
instead do the deletion of messages in sudo mode, and make sure
user_notification messages are deleted as well.
Doing this is not a security risk because the deletion of the record
itself (the super call) is still done without sudo, and if it fails,
the whole transaction will be rolled back. And it is part of the
expected ACLs for messages that if you can delete a record you are
allowed delete its messages. The fact that user_notification messages
are not accessible by normal users is for usability reasons (noise in
chatter), not security reasons.
opw-2234282
closesodoo/odoo#51010
X-original-commit: 094559aef4fdfebcba43a089cec4da5f4028a8f2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
- Have a user in an early timezone (for example Samoa Standard Time);
- Open a POS session in the evening (say 20h).
- Buy something, pay and ask for an invoice.
Before this commit, the date of the order was correct (today at 20h),
but the date of the invoice was wrong (it shows tomorrows date). This
issue occurs because the invoice date wasn't taking into account the
timezone.
Now, both dates are corrected.
opw-2231820
closesodoo/odoo#51001
X-original-commit: 19e9c4a0380e7ad7af297d13909dcbc63629a20d
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the last closing date of the POS didn't take into
account the timezone.
Now, the date take into account the timezone.
opw-2231820
X-original-commit: 1b738ac4b8b52042976ad209a1968135c55a16dc
- Have a user in an early timezone (for example Samoa Standard Time);
- Open a POS session in the evening (say 20h).
- Buy something and pay with cash.
- Close the session.
- List the session orders, and open the newly create order.
Before this commit, the date of the order was correct (today at 20h),
but the date of the payment was wrong (yesterday at 13h). This error
occurs because a wrong format was used and the date was taken into
account two times the timezone.
Now, both dates are corrected.
This fix is a partial revert of 2157540768
opw-2231820
X-original-commit: 020e5547ad10583000748659de0e2b14ceabbf97
that the argentinian chart of account has been installed
closesodoo/odoo#50880
X-original-commit: 3c55cae48936e195ec3411c55f577422c56828c3
Signed-off-by: Josse Colpaert <jco@openerp.com>
We need a hook to be able to personalize the procurement values
which will be used on procurement group creation when creating MO
closesodoo/odoo#51016
X-original-commit: 9a100e99ad401e5ca6bf45bf8371388c47ec7849
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
1. Install MRP
2. Launch an Odoo shell on the database
3. Type the command
`print(env["mrp.bom.line"].browse(1).child_line_ids)`
Traceback will occur with exception
odoo.exceptions.CacheMiss: ('mrp.bom.line(1,).child_line_ids', None)
This occur due to the empty value that the computation of the field
yields, which is not saved in cache.
Fix by adding a default value.
opw-2226951
closesodoo/odoo#50950
X-original-commit: fc885499a3c75d8d564569ec4cea41a8a64f3164
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Step to reproduce:
- Go to CRM app
- Create a new opportunity and edit it
- Alter the website field under "Contact Information" tab
with "www.anywebsite.com"
- Save and click on the website field value.
Without this fix, the field redirect as it's local:
"http://www.myodoo.com/www.anywebsite.com"
porting 726fad8
opw-2247853
closesodoo/odoo#50942
X-original-commit: 072400ad12ea17438a0175d94eb887f51172e461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, It was not possible to Hide Working Time or Deleting Working Time if Resource is linked to it.
Now we add, Active field to Hide Working timw without removing it.
closesodoo/odoo#50963
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This refactoring extracts parts of sale_coupon module to create a more
generic module called coupon. This new module can be extended in
different sales modules to implement functionalities specific to modules
that extend it.
TASK-ID: 1967639
Enterprise PR: odoo/enterprise#6020
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#38382
Related: odoo/upgrade#1072
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If there is cron worker timeout logger error, there is a log for the
last cron running
If a "Base Action Rule: check and execute" fails, we need to know what
is the last base automated action based on-time running
This logger helps to looked for it
closesodoo/odoo#50493
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Write something in a many2one field, and click on 'Create "..."'
to quick create a record with the given value (name_create). When
the name_create fails (e.g. because there are mandatory fields in
the model), we open a form view.
Before this commit, when this happened for many2one fields inside
x2many editable lists, it crashed, since [1].
[1] 50bf8309f8closesodoo/odoo#50948
X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this fix, record.with_context(lang='fr').compute_url will have the url
with the slug in french.
Before, it was ignoring the lang since the field was not translatable.
The first compute was stored in cache, and next call just ignore the lang in
the context.
```py
for lang in ['en_US', 'fr_FR']:
print(record.with_context(lang=lang).website_url)
> "/my-name-1"
> "/my-name-1"
```
now
```py
for lang in ['en_US', 'fr_FR']:
print(record.with_context(lang=lang).website_url)
> "/my-name-1"
> "/mon-nom-1"
```
closesodoo/odoo#50951
X-original-commit: 43822adef4ee4c44d10786f28af46df4be260cf5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the /event/event-id/page/inexisting_page crashes with an
internal error 500:
of1 ValueError: View 'website.404' in website 1 not found
X-original-commit: d493fdd2e837b5e6931bd8c2c4d57712432f9107
This refactoring extracts parts of `sale_coupon` module to create a more
generic module called `coupon`. This new module can be extended in
different sales modules to implement functionalities specific to modules
that extend it.
An initial step to prepare the creation of coupon module. The main goal
is to just move the logic from sale_coupon to coupon. To come up with
less diff as possible, this rename/move step is beneficial for this
purpose.
Sub categories were missing and will be usefull to test the incoming
enhanced categories filtering.
task-2071602
closesodoo/odoo#37297
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The following loop crashes on the second iteration:
for record in records:
record.display_name # access non-stored computed field
record.unlink() # delete record
The cache has been invalidated by `unlink` on the first iteration, so
the field is computed. The computation is done on the whole recordset,
which fails with a `MissingError` because of the first record. The fix
is to retry the recomputation on the single record in this case.
closesodoo/odoo#50910
X-original-commit: 7f33ebf528b1415452ce549e3329c3fe89be0ad8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
... when there is no data and user clicks anywhere in the no content
helper.
Task 2239617
Co-authored-by: Jinal Patel <jip@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Purpose
=======
Even if the routes are correctly updated and the existing data is
correctly updated, the emails that were already sent to the customers
will be problematic, as we will provide a value which is not handled
anymore (10 for example).
To provide a retrocompatibility, deprecated the old route and
introduce a new one.
closesodoo/odoo#46296
Taskid: 2083096
Related: odoo/upgrade#889
Related: odoo/enterprise#10312
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Rename the 'Use Rating on Project' feature into 'Customer Ratings'
- Rename the 'Set Email Template to Stages' link to 'Set a Rating Email Template on Stages'
- Add an optional list view for the Stages menu
- display warning if the rating_template_id field is set and if one of the selected project_ids doesn't have the rating_status field set to true
- Project form view revamp
- rename the '% on tasks' stat button into 'Customer Satisfaction'
- Remove the 'no option' for the rating frequency field because it is required
- project form : Add a 'Go to Website' stat button
- Project dashboard: remove the 'Customer Ratings' menu item in more
- Ratings page: the 'Last 30 days' filter include ratings from today
- remove the Appointment / Helpdesk Customer Satisfaction / Live Support menu items
TASK ID : 1251
Issue
- Install sale_renting
- Create a rental order
- Add a "rental" product
- In Modal, change start or end time
In Firefox, user not allowed to change the time;
time select not reacting well.
Cause
The issue seems to be that in bootstrap when
we click outside a modal, we focus on the modal:
https://github.com/odoo/odoo/blob/27f67bfcb903/addons/web/static/lib/bootstrap/js/modal.js#L332-L337
and the FieldDateRange widget contains a <select/> tag
and is added outside of the modal, so when we click
on the select, bootstrap will focus on the modal which
in firefox seems to lose the focus on the <select/>
which get closed.
Solution
not propagating focusin event when the select of the
daterange widget is focused => in my opinion this is
the less risky solution, this could be done with a
code such as (in the FieldDateRange._renderEdit method):
opw-2240220
closesodoo/odoo#50906
X-original-commit: 5a1e9e32061996ca1770c9ae9b5a7e7f53c5048f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Previously, when converting a number to a string we only kept 3
decimals, it turns out that when converting back and forth between rem
and pixels, we were losing enough precision that we had inexact pixel
values shown to the end user for odd number of pixels, even with the
default rem value of 16px.
This commit increases the precision to 5 to work around this issue and
allow us to convert exactly between rem and pixels at the default
16px/rem.
task-2248360
closesodoo/odoo#50881
X-original-commit: fdce273f4fe72a9e2555acecad3c2989110dac1a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Activate a language which has comma as decimal separator
Go into POS settings, activate 'Global Discount'.
Open POS session, add some product and use global discount.
Input some number with decimals and confirm.
Discount will be not applied
This occur because of javascript type coercion:
Math.min(100, "11.0") -> 11
Math.min(100, "11,0") -> NaN
So in locales with thousands separator the statement would produce
different results. Forcing float parsing fix the issue
opw-2243482
closesodoo/odoo#50900
X-original-commit: 84a6c2a59c59b88b0ad7b1f9112d331fa2a505c5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In the sign application, it appeared that when using the default signature
in a signature SignItem that was higher the stroke at the bottom was doubbled.
This was caused by the fact that the bottom stroke is always added to the
template and that the default signature image had it already.
In order to solve this, we have added a setting 'show-stroke' that allows
controlling the stroke presence in the signature.
Task Id 2216067
Closes#48529
Related odoo/enterprise#9538
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reverse charge is a mechanism under which the recipient of the goods or services is liable to pay the tax instead of the provider of the goods and services.
GST Treatment:
* Is show that how This purchase is treated in GST
* Set default value in customer
* This is help in GST retrun filing.
* Value of treamtmnet as below
- Registered Business - Regular
- Registered Business - Composition
- Unregistered Business
- Consumer
- Overseas
- Special Economic Zone
- Deemed Export
* GSTIN is required in
- Registered Business - Regular
- Registered Business - Composition
- Special Economic Zone
- Deemed Export
GST Treatment:
* Is show that how This sale order is treated in GST
* Set default value in customer
* This is help in GST retrun filing.
* Value of treamtmnet as below
- Registered Business - Regular
- Registered Business - Composition
- Unregistered Business
- Consumer
- Overseas
- Special Economic Zone
- Deemed Export
* GSTIN is required in
- Registered Business - Regular
- Registered Business - Composition
- Special Economic Zone
- Deemed Export
Shipping GSTIN:
* GST identification number or GST number
* There can be multiple GSTIN for a single person, being an assessee under the Income Tax Act for every State or Union Territory in which such person operates from
* So When specific invoice and delivery addresses is enabled then user can enter able to enter "Shipping GSTIN" on shipping address of partner
* Add Validate of this number using regular expression
GST Treatment:
* Is show that how This invoice or partner is treated in GST
* Set default value in customer
* This is help in GST retrun filing.
* Value of treamtmnet as below
- Registered Business - Regular
- Registered Business - Composition
- Unregistered Business
- Consumer
- Overseas
- Special Economic Zone
- Deemed Export
* GSTIN is required in
- Registered Business - Regular
- Registered Business - Composition
- Special Economic Zone
- Deemed Export
GSTIN:
* GST identification number or GST number
* There can be multiple GSTIN for a single person, being an assessee under the Income Tax Act for every State or Union Territory in which such person operates from
* Add Validate of this number using regular expression
remove field l10n_in_export_type and l10n_in_import_export becouse it's covered by GST Treatment
remove field l10n_in_partner_vat becouse not use anyware.
- Enable Include in Analytic Cost in purchase tax P
- Create an expense
- Select product, purchase tax P, set analytic account and tags
- Create report, submit to manager, approve, post journal entries
The tax `account.move.line` does not have the analytic account and tags
assigned.
The information is missing at the tax line creation, so apply the same
logic than:
https://github.com/odoo/odoo/blob/784d22bd005db7825375a97caf9661bd5d463efe/addons/account/models/account_invoice.py#L1055-L1057
opw-2250257
closesodoo/odoo#50879
X-original-commit: ec6fe8cdff7a072a6d44e5a2a40ca0da43254f7d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Lable for the field `barcode` is `Badge ID`.
With this commit, We display the correct field name in the Warning.
closesodoo/odoo#50700
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this fix, in case you try to compute the pricelist_id with another
context, the computed value is set to the website with the new context,
and so another cache.
Now with compute for the env from self, and assign the computed value with the
website with ot without another context.
Before this commit, you was unable to add fields pricelist_id or currency_id in
a tree view.
opw-2233122
closesodoo/odoo#50705
X-original-commit: 2f83c5bad94775a8f85e65c129afdcf503995ecb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* A step has been added to the sale tour in order to ask the user
to update the company data. As a page reload breaks the tour test
we need to prevent it in such situation.
TaskID :2187222
closesodoo/odoo#46167
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* The first tour is starting in the sale app dashboard and ensures
the user goes through the needed configuration steps
* The second tour starts in the new Quote form and shows the flow to
send a quote to a customer
TaskID: 2187222
Closes: #46167
The ampersand (&) needs to be html encoded to be evaluated correctly
Cherry-picked from odoo/odoo#46526
Courtesy of Olaf
Closesodoo/odoo#46526closesodoo/odoo#50852
X-original-commit: 28b977d4702cd64290c5e48f39c8df2ad9819483
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- Start the IoT Box with a monitor plugged in
- Unplug the monitor
- Restart the Odoo service (i.e. connect the IoT Box to a DB)
- No devices are detected
The problem came from the fact that `tvservice -l` and `tvservice -n`
have different behaviors when a monitor is disconnected:
- `tvservice -l` still says that a device is attached
- `tvservice -n` cannot detect the name of the device so it logs an
error to stderr but still has a return value of 0 so we read an empty
string from stdout.
The `get_connected_displays` function raised an exception because the
format of the returned string was not the one we excepted. The other
loops were then not started and no devices at all were detected.
closesodoo/odoo#50839
X-original-commit: ab6ec2ab6d30a86f9741da4b1986831772004d91
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Access rights were added on transient models at odoo/odoo#43306
The _filter_access_rules method was still using the old logic of
transient, bypassing access rules
closesodoo/odoo#50828
X-original-commit: 7e0d6f7e0d725a2addb2821c16fce77aed54ca03
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Swapnesh Shah