Ensure the write method in account.journal is working with multiple records.
The for loop indicates it was the intention to be used on several records but
self was still used instead of journal
Some methods like _update_mail_alias work with an ensure_one
closesodoo/odoo#28246
Before this commit:
* Enable UOMs
* Create a new invoice and invoice line
* Set *only* the uom field of the invoice line
* Singleton expected error
This happens because the method _compute_price of `uom.uom` expects a
singleton, however since no product has been defined yet, it gets an
empty recordset which of course doesn't comply with self.ensure_one(),
raising a Singleton Error.
Functionally speaking, it makes sense to define a product before
choosing an uom, however a Singleton Error is an unexpected error, so
instead of doing that, we only calculate the price_unit if a product has
been chosen.
Fixes#28269closesodoo/odoo#28278
The related field `timesheet_encode_uom_id` is required
on the company, but not on the settings.
This commit makes it requried through the view to
avoid a confusing SQL error message for the end user.
Closes#27645
- The affix navbar went over the ace editor, preventing to save/close
- The ace editor went always under the new content menu
Now:
- The affix navbar is always under the ace editor
- The ace editor closes when the new content menu opens
- The new content menu closes when the ace editor opens
closesodoo/odoo#28251
When doing a sale order containing product and services, the
computed minimal expected delivery time was using the customer lead
time of the services (which is always 0) instead of the minimum
customer lead time of the products.
To reproduce:
1) Install Sales and Delivery Cost.
2) Go to the sales settings and enable the "Delivery Date" option.
3) Set a customer lead time on a product.
4) Create a quotation with that product, any service and a
delivery method.
5) Validate the quotation and the delivery.
6) The "Expected Time" written in the "Other Information" tab of
the sale order doesn't match the minimum delivery expected time.
opw-1902858
closesodoo/odoo#28208
This commit fixes the following bug:
* On a new DB, install account
* Settings > Technical > Email > Digest emails
* Open Weekly Digest, set Next Send Date to current day
* Settings > Technical > Scheduled Actions > Digest Emails
* Run manually
AttributeError: 'res.company' object has no attribute
'resource_calendar_id'
The field resource_calendar_id is added in the module resource.
The module digest does not have resource in its dependency.
In stable version, have a silent fallback on UTC if the field is not present.
The right dependency should be added in master.
closesodoo/odoo#28244
In case we create an allocation in byTag, byDepartment or byCompany, we
need to pass the accrual flag to the children of the first allocation
and only update the children allocations (namely the byEmployee
allocations only).
Otherwise the accrual allocation will fail
Closes: #27971
opw-1895302
closesodoo/odoo#28012
Before this commit, the user could not receive any notification
from the chatter of a document when having Notification Management
set to "Handle with Odoo".
This problem occurs when the user opens (or has opened) the document.
Any messages received from the document are automatically marked
as read, so it removes the notification right after receiving it.
In order to no longer have this issue, the user had to reload all
pages that have opened this document.
This commit slightly changes the behaviour of the chatter, so that
it automatically marks it as read only when accessing the document,
but not when the document is open (or has been opened). Consequently,
if the user has opened the document and then receives a notification
from this document, it won't automatically mark it as read.
Task-ID 1895359
opw-1890556
closesodoo/odoo#28114
Set a suffix on the sequence that will determines an invoice's move's name
Validate an invoice
Before this commit, there was a traceback because the regex that matches the invoice number
did not match anything due to the suffix
After this commit, it works as expected
OPW 1903326
closesodoo/odoo#28241
This fix some inconsistent error on runbot.
In mobile, some views* depend on 'jquery.touchSwipe' library which
is lazy loaded. As a result, the views become asynchronous...
It's why this library is already loaded before running tests in the
mobile test suite. So we can continue to use synchronous views whether
in mobile tests or not.
But some mobile tests weren't in mobile suite...
In desktop, 'jquery.touchSwipe' is lazy loaded and the first test will
load it for others. It's why the first one has to be asynchronous:
https://github.com/odoo/odoo/commit/da7b59045d246c159f93bc75e3f19c6b1221d31c
The inconsistency comes from the fact that all tests are sequential but
we can't garantee the execution order. So, if the test mentionned is not
the first executed one, an error will occur because the view is not
asynchronous.
Now, all mobile tests are moved in mobile suite to be sure that
'jquery.touchSwipe' is loaded.
We also set the default value for size_class because we want a
coherent environment. It is very rare to find mobile devices with
more than 474px wide.
*: form_view, kanban_view, res_config_settings
closesodoo/odoo#28195
We fix two problems with the 'unreserve' function on picking and sale order,
When a sale order is edited, we perform 'do_unreserve' on picking, it is not necessary and make us loose the done quantity put on the picking so we remove it.
When we unreserve a picking having a package level added through a put in pack or automatically added on reservation, the package level is set back to draft instead of being removed
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28188
When a quantity is increased in SO, the related picking is unreserved
then re-assigned, we can just call assign, as we don't want to lose what
has already been done in the picking.
As the decreased quantity on SO is not propagated on move, not
unreserving won't cause trouble.
This reverts commit d78b6f5e25.
This constraint is considered too harsh. It was applied to circumvent
inconsistencies when a bom is modified while being used in a
manufacturing order and the user chose to update the quantity to
produce. The current code will look at the existing move if no
intermaddite post of inventory was done else look at the new bom.
A code to re-construct the original BoM from the stock moves isn't easy
to write to handle all cases, one particularly complicated is the
deletion of bom lines of the same product.
We also considered to block the update qty button if the bom is modified
after the create date of the MO, but if we have to read all the bom
lines of all the sub bom in a computed field it may be slow on large
databases.
We thus chose to remove the constraint and think of a better approach in
a future version.
task 1891407
closesodoo/odoo#28155
Currently creating activities assigned to user not having to the document
raises an Error as people should not have activities they cannot handle
directly on a document they cannot access.
In some cases activities are created through business flow, like automatic
activities creation when creating leave requests. Assigning an activity
to someone that has no access to the document should not prevent from
creating the leave request.
This commit therefore does not check assigned user access on automated
activities to avoid having blocked business flows.
This commit is linked to task ID 1903484.
closesodoo/odoo#28139
On the user's preference, change the timezone to one that is different
from the browser.
Save the form.
Go back to the user's preferences.
Before this commit, every timezone was displayed inside the span that contain
the warning icon, and leaked everywhere on the form view.
This was because of the joint action effects of commits:
86897ca1674dfabb8f7a
Which provoked the field to be re-rendered in edit mode,
but with an $el on which a span was added. `<option/>` elements
were then added to both `<select>` and `<span>`
This did not happen before v12.0
After this commit, there is no display glitch
OPW 1895088
closesodoo/odoo#28108
* fix in the accounting config bar ('add a bank' and 'fiscal year' steps)
* better display names and icons for vendor bills uploaded manually (moved some code that was previsouly only done in document_account for vendor bills created through the DMS)
closesodoo/odoo#27882
Design: remove empty space in the dialog form.
Opening date:
-fix move line not created introduced by c4b9c51abf. This prevented saving the opening date;
-set default date to start of current year.
Add a validation on fiscal year last day:
-the automatic calculation was removed in 90cdc91638 but no validation was set;
-the help message became irrelevant;
-the fiscal year end date was set as readonly in 52a8ed3c0c and not fixed in 3f4f77fd9d.
Unsplash API requirements does not directly allow to store their images on
our server (We should use hotlinking unless the image is edited (cropped etc)).
Still, they have the `Image Beacon Alternative` to allow to store their images
on our server if we really need it with our use case.
With the Beacon Alternative, we should ping Unsplash server to notify an image
view.
To do so, we need to be able to recognize Unsplash imagesin the DOM, this is
why we are now using /unsplash/ in the URL.
The Unsplash image name should be the image ID as it will be the identifier
needed to ping their server.
This commit also adds credit to Unsplash in the media dialog next to the
unsplash input search.
It also add the `w-100` on the media dialog card as we lost that UI behavior
from BS3 to BS4.
opw-35060
closesodoo/odoo#27377
The feature was not tested, and as it turns out completely broken:
* the non-raw string means the "backrefs" were really interpreted as
octal literals
* the second backref was entirely wrong
Also add all loaded views to the field descriptor in case we might
have a use for it (and because inline sub-views are always stored on
the descriptor).
closesodoo/odoo#28194
Some people do not understand the old forgotten langage coming from R'yleh
sub-city of Helk'Yizrk. Let us use standard naming then.
closesodoo/odoo#28196
From times to times, warning are seen on the runbot during HttpCase
tests with the chrome headless browser.
Those warning are about Odoo trying to join remaining requests threads.
In the dumpstack, the thread seems blocked in the werkzeug
handle_one_request method, when trying to read the HTTP request line.
One explanation could be that Chrome opens a pre-connect socket for
a future use. When the HttpTest cleans the browser, the page stops
loading but (probably) keeps the socket open for a while.
That could explain the problem.
With this commit, a timeout is set on the request handler,
in the hope that it closes the pre-connect socket too.
Cheery-pick of f9ee8cf to avoid runbot_merge failures.
closesodoo/odoo#28193
Commit: a034a17d37
with a starking lack of foresight, erroneously put a native input date.
It wrongly assumed that the text input was a text input instead of a BS
datetimepicker, which was broken when upgrading BS3 to BS4.
Which means that it wasn't styled as the rest as Odoo, as well as not being
configurable, not working on some browsers, and subject to locale errors.
We fix the DOM so that the BS datetimepicker is correctly applied.
Related to 9a6cd4e41dda56c4f454ed898ed17adad0d8556f
closesodoo/odoo#28135
Before this commit, the code for the tour system was kind of naive and
simply activated tips for each tour. This was not really an issue,
since most user install one app at a time, so they had the time to
follow a tour, and when they install the next app, it is no longer
active.
However, since we activated the multi-app feature in our website, it now
happens that multiple apps are installed at once. Because of this, this
commit is now necessary.
closesodoo/odoo#28178
When updating to BS4, the datetimepicker library was updated to
tempusdominus.js.
It expects the DOM to be slightly different to apply correctly.
opw 1896103
closesodoo/odoo#28073
Don't compute it for public user that can have thousand of SO
Improve request to find the last one.
'Sent' state should be included, but in case of wire transfer, state is sent,
while we should not be able to update this order.
-> to imp in master
Courtesy of @nseinlet that spotted this issue and propose similar fix
This commit closes#27779#28158closesodoo/odoo#28164
widget of crm_reveal did not call the correct service name, becoming useless
Allow saas clients to access their iap accounts portal
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28163
Report refactoring and f29df7fb2e expect when printing document that the
current one is in variable `o`, so this commit enables it.
opw-1894243
closes#28143
Co-authored-by: Laurent Smet <smetl@users.noreply.github.com>
When we switched to bs4, we changed the style of the dashboard and put
the iap recap link inside a specific div which elements are hidden for
saas users.
In the portal, there is no link to the downloadable content.
This is because the content of the `super` call has been changed in
4c31a758cf. The key is now `sale_order`.
opw-1895878
closesodoo/odoo#28132
Large diffs (specifically in x2many fields) cause performance issues. They
overload the web client, which considers all returned fields as dirty.
closesodoo/odoo#27941
Swapnesh Shah