Prevent duplicate SN through python constraint (requires SN to be
attempted to be created) instead of assigning existing one (and
causing a duplication). Steps to reproduce:
- create a SN tracked product + activate "storage locations"
- assign a SN to tracked product
- create a planned receipt for the tracked product and assign same SN
(i.e. same name).
Warning will pop up about repeat SN, but it is still possible to
validate the picking and create a duplicate SN.
Also add an extra `limit=1` to lot search for performance/safety.
Bug was discovered while working on related task: 1924758
closesodoo/odoo#64714
X-original-commit: cd81b7accad63ec433ff66e58f286626cfc1ac65
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The calendar reminders are emails or web notifications sent moments
before an event start. The mechanism to send web notifications is
controlled by the browser, it fetches all the future notifications and
uses `setTimeout()` to delay them. The mechanism to send emails was
controlled by a cron, every 30 minutes the cron would look for the
coming events and send the mail reminder.
The cron was running every 30 minutes even if there was no event. The
best precision was 30 minutes.
The new mechanism use cron triggers, every time one add email reminders,
triggers are created to call the cron at the precise moment the alarm is
set. The cron no longer send emails for events in the coming 30 minutes
as those will be triggered too.
closesodoo/odoo#64560
Task: 2416741
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
There is code that automatically enable or disable the cron whether it
exists alarms. As alarms are automatically added, the cron is actually
always enabled.
Steps:
- As admin, go to "Contact us" or any other page on the website (1)
- Go to Pages > Page Properties > Publish
- Change the visibility to Signed In
- Save
- As demo, go to (1)
Bug:
The user "demo" is signed in but is returned a 403 Forbidden
Explanation:
When landing on a page with visibility: 'connected', the only way to see
the page is to have a group matching the groups of the page as seen
here: https://github.com/odoo/odoo/blob/28b748a559e1ffb5fb7c3631bf77adba121b2ebf/odoo/addons/base/models/ir_ui_view.py#L625-L626
This fix lets any connected users see the page.
opw:2431700
closesodoo/odoo#64720
X-original-commit: b02a99bec709b5a6dc4dabb6cb81435dadc24e7e
Signed-off-by: backspac <backspac@users.noreply.github.com>
The emails sent via Odoo reveive a poor score on various spam tools,
the reason being the missing `MIME-Version` message header. This header
inform what MIME version is in use in the message. Even if there is only
one standardized version of MIME (1.0), the header is mandatory.
Citing [rfc2045] "MIME: Format of Internet Message Bodies" section 4:
> the MIME-Version header field is required at the top level of a message.
Setting the charset on the envelop forces the EmailMessage API to also
include the missing `MIME-Version` header.
[rfc2045]: https://tools.ietf.org/html/rfc2045#section-4
Task 2393865
closesodoo/odoo#64715
X-original-commit: 8663f1e20727c315924bb20fc1de1accf3014c61
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This fixes some details and reorganize the order of the tutorial. It
also introduces a more detailed section for the SCSS customization. A
very detailed and updated version of this tutorial is being made for the
14.0 version and later.
task-2440442
closesodoo/odoo#64700
X-original-commit: 08d44d444490713ca39618a67f441bbd84b8b900
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Accounting" module
- Create a new bill :
- Set vendor
- Set no payment reference
- Set a bill reference
- Add products to bill
- Confirm and click on Register Payment
Memo field has no value.
Cause
The memo field is based on lines name.
Lines name is computed in `_onchange_payment_reference`
and depends only on payment_referecence.
Solution
If no `payment_reference`, fallback on `ref` to set line name.
opw-2440389
closesodoo/odoo#64692
X-original-commit: 31bc04afc3ed4ea74cd20f71ea10943b1026629c
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When using a tracked product in a MO, the lot/serial number reservation
disappears even if the product is still reserved.
To reproduce the error:
(Need mrp)
1. Create two products P and P_compo
- Both are storable
- P_compo is tracked by lots
2. Update P_compo's quantity
- Set the on hand quantity of lot L to 5
3. Create a MO
- Product: P
- Quantity: 5
- Add a line: (Product: P_compo, To Consume: 5)
4. Confirm
5. Check availability
- The P_compo's reserved quantity has been updated to 5. If you
click on the line's details, you can see that 5 P_compo has been
reserved from lot L
6. Back to the MO, in edit mode, change the done quantity: 3/5
- There are still 5 reserved P_compo
7. Click on the P_compo's line details
ERR: the line we saw on step 5 disappeared. The MO says that 5 P_compo
are reserved, but when checking which lot is reserved, the latter is
no more visible. Moreover, if you click on "Confirm" (so you leave the
"Detailed Operations" pop-up), the "Reserved" field of the line will be
reset.
The lot reservation should stay so the user can complete the "Done"
field.
OPW-2420347
closesodoo/odoo#64684
X-original-commit: 8dfee8cb2d60942641b73eaa6489b02aa378c5ac
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closesodoo/odoo#64683
X-original-commit: 69cadbe1be6320d96fe9bc5bf8dd808f87d735c0
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
WHY: it's computed field that is not supposed to be editable. In previous task
it was asked to make it visible, not editable.
closesodoo/odoo#64676
X-original-commit: f7788fdf03bcf81710f5b01fbf67a90aa30e1e58
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When the customer use Anglo-Saxon stock valuation and have already
reconciled some `account.move.line` related to an open `pos.session`,
closing the session will fail.
(You are trying to reconcile some entries that are already reconciled)
Now, the reconciled lines are ignored.
The inventory valuation is still correct as these lines were already
reconciled.
opws:
2374559
2376187
2377958
2391395
2425197
closesodoo/odoo#64668
X-original-commit: 3f939af62df65dcb9c8cdd2ecc3ac3d4c2983a2f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
BEFORE: sms templates from these modules become inaccessible if any module from
the list below is installed
* crm_sms
* event_sms
* stock_sms
* enterprise/account_followup
* enterprise/marketing_automation_sms
* enterprise/sale_subscription
those modules add security rules for sms.templates, which adds additional
conditions to get access: at least one security rule has to be passed. So, we
need to add such rules to give access not only to Superuser
closesodoo/odoo#64661
X-original-commit: 23c82340c1cbd3d5a25d5c2ecec6c7d0f988cd90
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When reconciling a statement line with multiple lines in a multi-currency environment, it could lead to a rounding issue due to the currency rates. It could lead to an auto-generated open-balance of 0.01 amount to auto-balance the journal entry but the result is wrong since the partner has an open amount left on the receivable/payable account.
closesodoo/odoo#64636
X-original-commit: 4d4e6e588d14742f153a1c6b67d510e0c21e5d64
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Restore Project Kanban view for mobile.
Added a name for the default stage of the tasks in the Internal project
Removal of redundancy for the creation of the Internal project and its tasks
Fix task_reccurrence for the type 'after'. (too much task created or bad task created)
Task-2326258
closesodoo/odoo#64607
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In order to clarify the purpose of the account_lock module, slightly
update its description.
Task id #2382740closesodoo/odoo#64559
X-original-commit: f15188907a63d3f50c80c8254e60b9f31a666c55
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
From Invoice list view select 2+ invoices (A, B), click Action>send and print
In each invoice 2 invoices will be sent:
- In A, you'll find A and A
- In B, you'll find A and B
This occur because the composition_mode of the composer is computed
after the attachment has been generated.
When the composer has an attachment, it is included into
the sent mail along the relevant one, generated on the fly for each record.
opw-2428544
closesodoo/odoo#64445
X-original-commit: 9b585963a4b4f53b856b219004322232c2acf318
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit:
- The precision on geolocalisation fields were set to (16,5) which
caused rounding when data was comming from Goolge.
After this commit:
- The precision on geolocalisation fields are set to (10,7) which is
aligned with what Google does.
This precision of (10,7) is actually already used in the Sign App.
task-2426985
closesodoo/odoo#64401
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Currently, the signature of the admin defaults to 'administrator'. Odoo
does not take into account the actual name of the user. The onboarding
experience would be better if the signature was personalized
for the user.
SPECIFICATIONS
The default signature of the admin is his name (Mitchell Admin) instead of 'Administrator'.
Task-2416715
closesodoo/odoo#63914
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this task is to improve the various modules like crm_iap_lead, hr,
hr_timesheet, product, project, web.
So in this commit done the below changes:
- timesheet: project is open in the form view insted of the quick view
- earlier the popup window notification is sticky so after this commit it will
disappear automatically after a few seconds
- product form view: 'extra prices' display as a link
- project sample data: move the helper a bit higher in mobile view
- CRM > Generate leads > industries > search more: rename 'tag name' into
'Industry'
- preferred_role_id: 'ceo' written in all caps
- employees kanban view: the chat icon aligned to the bottom of the card
- move the project tour droplet to the right of the add button.
closesodoo/odoo#63693
Task-id: 2374726
Related: odoo/enterprise#15426
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit groups creation and posting of account moves related to
stock valuation in case of automatic valuation product.
Previously, the account move were created one by one and posted right at
the creation. Which can really slow (for instance running
_run_fifo_vaccum with a large amount of remaining quantity layer)
closesodoo/odoo#62700
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When using the route `/report/barcode/...` in a report, wkhtmltopdf
makes htpps requests on the server to retrieve the barcode image.
If a lot of barcodes have to be printed, this can overload the server
with too much requests and makes wkhtml crashes.
With this commit, the qweb barcode widget is used to include the barcode
as an img tag with inline barcode image as base64 data.
closesodoo/odoo#64211
Related: odoo/enterprise#15619
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When printing barcodes for a large amount of records, wkhtmltopdf will
make the same amount of http requests to the server in order to retrieve
barcodes. This can lead to performance issues or wkhtml to crash.
Fortunately, an already existsing qweb widget exists that include
barcodes images as inline base64.
With this commit, the web widget is a bit improved to accept attributes
for the generated image tag. Each option dictionary key starting with
`img_` will be converted into a tag attribute with the corresponding
value.
e.g.: `'img_alt': 'Barcode'` will result in `<img alt="Barcode"...`
The `alt` img attribute now defaults to `'Barcode %s' % value` with the
barcode value.
Also, the `quiet` reportlab option is also avalaible in the widget
options, as well as the `mask` option.
Finally, if the `symbology` option is not given, the widget defaults to
`Code128`. If `symbology` is set to `auto`, the action report will try
to guess the barcode type, based on the len of the value.
The design was not properly adapted to the last changes before the 14.0
release and still contained some invalid properties. Now the list inputs
match the design of the normal inputs.
closesodoo/odoo#64400
X-original-commit: fe102c04c0526cb7aa547f146974cdfb80629723
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, when opening a colorpicker in safari, the crash manager
would open with the message "An unknown CORS error occured [...]". This
is actually odoo's default message when an error has no file, line or
column, which is usually the case for security reasons on CORS error.
This is however not a true CORS error, but a "ResizeObserver loop
completed with undelivered notifications" error, which also does not
report file, line and col for the error.
This error is caused by the fact that in webkit, the baseline of an
empty input is considered to be at the bottom of the input element,
rather than at the baseline of the text of the input once it has some
content. (see https://bugs.webkit.org/show_bug.cgi?id=142968 )
In the case of the colorpicker, it uses a ResizeObserver to update its
UI, including updating the content of its inputs. This will cause the
first _updateUI to fill the empty inputs, which changes the layout of
the widget content and changes its size. Changing the size of an element
inside of a handler of a ResizeObserver on that same element will cause
an error and not call the callback again, so as to prevent infinite
loop.
This commit fixes that by filling the inputs before attaching the
ResizeObserver, so that it has its final size from the get-go, and
_updateUI will no longer change the layout/size, causing this error.
opw-2419296
closesodoo/odoo#64389
X-original-commit: 5e9e35ef0d7b0cdecc5c25dc4db04925ed0408a6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Let's make a bancontact payment with Stripe on mobile from the web shop
- Stripe redirects you to Odoo
- Your phone asks on which browser you wanted to redirected to Odoo
- Choose one
Bug:
An internal error was raised.
When you clicked on a browser (the same you were using or a new one, whatever)
Odoo will resend a request to Stripe. But this request will have wrong data in it.
Stripe will answer with:
Stripe: entering form_feedback with post data {'error': {'code': 'resource_missing',
'doc_url': 'https://stripe.com/docs/error-codes/resource-missing',
'message': "No such payment_intent: 'py_1I6c4UKhH8RhRq18TJs2CP0z'",
'param': 'intent',
'type': 'invalid_request_error'},
'reference': 'S00002-1'}
opw:2422031
closesodoo/odoo#64385
X-original-commit: a42075c9f913f4a20b28f97f0f6786f5a7b2968a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider a partner P linked to an employee E and a vehicle V
- Let's change the mobility card of E with 12345
Bug:
The mobility card on V was not changed.
opw:2431316
closesodoo/odoo#64343
X-original-commit: 81e574aae3059844179dd9f54a241cd51a2474fd
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previously, when double clicking and image, video, icon, or document in
the web-editor and replacing it with a different media type, it would
lose its custom classes. This means among other things, that it would
lose margins and paddings from bootstrap classes, or in the case of the
three columns snippet, that the new media would not be properly rounded
in its top corner, or not show up at all in the case of the video. The
only exception was when changing any media type to an icon, but in that
case it would also keep some of the media-specific classes that are
supposed to be removed (eg img-fluid or media_iframe_video).
This commit fixes that as well as some _clear behaviour that didn't
remove all classes that had to be removed, eg some fa-classes would
linger depending on their order, and the o_image class from documents
would always remain
Part of https://github.com/odoo/odoo/pull/64234
task-2282542
closesodoo/odoo#64234
X-original-commit: 99531f5dd8966fc4ad89d1e9c2886ad701527f3a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, changing a media from a video/icon/document to a different
type would leave empty elements in the DOM, this is because summernote's
range API `range.insertNode` function deletes the content but not the
structure (HTML elements).
This commit fixes that by using jQuery's replaceWith method instead of
summernote's insertNode when a media was found, and only using
summernote in case no media was found (eg. a text range).
Part of https://github.com/odoo/odoo/pull/64234
X-original-commit: 63f80995a05eeab1061b769c7733a1cfa98c726e
Clicking on save on html editor is taking quite some time. The user might think
something is not happening and need to click again.
If he does click again, 2 write RPC will be sent, making the COW business code
being triggered twice, ultimately leading to create 2 COW.
Instead of
A
/ \
B B'
It will be
A
/ | \
B B' B'
With as many B' than there is click on save.
This commit adds a generic helper to make a button load/spin.
closesodoo/odoo#64366
X-original-commit: 80592abda266ef3f9f463854c3101eb3f728087b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
STEPS:
* configure rounding:
- cash_rounding=True
- only_round_cash_method=True
- round method: 1.0 Down
* open a session
* add products with subtotal in decimals (such as 6.35)
* select Bank payment method and process the order
BEFORE: error "You have to round your payments lines"
AFTER: order is processed and marked as paid
---
https://github.com/odoo/odoo/commit/42425996e36d9cb1fc1391402cf6d00df4aea019
opw-2426027
closesodoo/odoo#64351
X-original-commit: db0b65e547defe3d49c1a31c4671f546aa5156e8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The intent of the test was to count renders but it counted calls to `onUpdate`
which was the same "by luck", but the function was changed to be called more
often than renders to fix another bug.
Proper way to count renders (after the initial mount) is just to use `patched`.
closesodoo/odoo#64352
X-original-commit: c7375ebaf8d4baa6e02534425ed634c7264ce90f
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When sending several invoices, customers also receive those that do not
concern them.
To reproduce the error:
(Need mailcatcher)
1. Go to Invoicing
2. Select two invoices
- Status must be "Posted"
- Customers must be different
3. Action > Send & Print
4. Uncheck "Print", then click on "Send"
5. Repeat 2-4
Err: Each customer receives both invoices. (In some cases, a third mail
is event sent). Each customer must receive his own invoices.
The mail composer wasn't correctly configured.
OPW-2422117
closesodoo/odoo#64340
X-original-commit: 603752df5444f60ac7282758c7e6596940747889
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Free reservation is called each time an extra quantity is
used on a move (and for each immediate transfer). It means
that the function is called many times on a database with an
inventoy activity. Also _free_reservation method do a search
on fields that are not indexed, and is slow on large database.
This index is specific to _free_reservation.
On a live database with an important stock, the queries dropped from 265ms
to 1.5ms.
closesodoo/odoo#64327
X-original-commit: 74ea87d0a354b7414afb76d98ed39ecde45a8fb1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When running the scheduler, if one of the concerned product is a
kit, it will always generate a RfQ for the components, even if there
are already enough of them.
To reproduce the error:
(Need purchase)
1. Create 2 products P and P_compo
- Both must be storable products
- P_compo must have at least one vendor
2. Go on P-product page
3. Add a reordering rule (e.g., min: 5 and max: 10)
4. Add a BoM
- Must be a Kit
- Add P_compo to components
5. Inventory > Operations > Run Scheduler
6. Go to Purchase, find the generated RfQ
7. Confirm the order, Receive Products, Validate
8. Go on P-product's page
- As you can see, you have enough P-products on hand
9. Repeat steps 5-6
=> You should not find any RfQ since you already have enough P-products.
When checking the P-product's page, you can see the correct quantity on
hand because it uses the `_compute_quantities` method and this one has been
overridden in the mrp-module so a kit will be correctly computed.
However, when running the scheduler, it uses another method to get the
current quantities: `_compute_quantities_dict`. Since this method has
not been overridden in mrp-module, it will use the basic implementation
and this one does not consider the possibility for a product to be a
kit.
This fix creates an override of `_compute_quantities_dict` so it can
compute the correct quantities of products with 'phantom' as BoM type.
Moreover, for the code to be simpler and clearer, thix fix also merges
`_compute_quantities` and the new `_compute_quantities_dict`.
OPW-2421841
closesodoo/odoo#64326
X-original-commit: 609e2f4427082431b56aa8f999d74ed9d39db653
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps:
- Install accounting
- On the dashboard, try to upload an "encrypted" PDF like this one https://launchpadlibrarian.net/24827090/DS-0157.pdf
Bug:
Traceback:
PyPDF2.utils.PdfReadError: file has not been decrypted
Explanation:
In 13.0, these errors were caught in a catch all `except` as shown here: https://github.com/odoo/odoo/blob/4e089041252c25cc197a30f9e285d82f7162d809/addons/account_facturx/models/account_move.py#L303-L328
From this SO comment: https://stackoverflow.com/questions/52047944/pdfbox-extracting-blanks-from-pdf-encrypted-with-no-password#comment91054285_52047944
> A PDF can be encrypted with two passwords: a user password and an owner password. When a PDF is encrypted with a user password, you can't open the document in a PDF viewer without entering that password. When a PDF is encrypted with an owner password only, everyone can open a PDF without that password, but some restrictions may be in place.
From time to time, we get a PDF encrypted with an owner password. The
content is still readable, but PyPDF2 fails because it thinks the PDF is
encrypted. With this fix, we try to unwrap the PDF by providing an empty
user password. This way, PyPDF2 thinks the content is now decrypted.
However, PyPDF2 only supports decrypting versions 1 and 2 of the
encryption implementation. If the version is different, we skip reading
the attachments and carry on to allow the user to upload the document.
opw:2375993
closesodoo/odoo#64320
X-original-commit: 851fe64f7789bb398383c22e3ebbaebb051791f6
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Fine tuning of 78286851034b8f3ef4dcab78e50b7220c0bdd213
The link to view Cash Statements on the dashboard openned the wrong
action.
Also in some cases, removing the context key `search_default_journal`
was not enough so we set it to `False` instead.
closes#64118closesodoo/odoo#64279
X-original-commit: 95ffa9fd122eae82d12d40db3cb7364cf3d3c919
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Tiffany Chang (tic)