If no Undistributed Profits/Losses account can be found, Odoo tries to
create one with number '999999'. However, such an account number might
have been created manually by a user. In this case, the account creation
fails.
opw-1932701
closesodoo/odoo#30719
When a colored kanban tile is colored, and there is a color attribute on
the tile HTML element indicating a color field (eg. when a kanban view
with color dropdown is created in studio), there was a HTML element over
the whole tile preventing to click on links or other sub element of it.
This HTML element is just a transparent used for accessibility to
contain the tile color intelligible name, so this commit just size it
over the area of the color (currently in base bootstrap ~3px at the left
of the tile).
opw-1932283
closes#30717
Before this commit, when a user had some meetings planned today
and open the systray activity menu, the counter would disappear.
This was caused by a weak computation of the counter that relies
on activity having always a total counter. This was not the case
for activity that are today's meetings: Counter would be computed
as `NaN`, and since `NaN` is falsy, it won't display the counter.
Today's meetings have no reason to have a counter, so this commit
fixes the issue by letting those activities not change the
computation of the counter.
closesodoo/odoo#30695
If xlwt is not installed on the server, the option is disabled.
However, the first element was checked, even if it is disabled.
Trying to export record without xlwt was causing a traceback.
Introduced at b60de0db41 where xls is now the first choice
closesodoo/odoo#30724
On mobile, swiping right/left switches to next/previous record.
This feature prevents the horizontal scroll of the form notebook's tabs by
overtaking the swipe gesture on those elements.
This issue had different consequences depending on the platform:
- on iOS: the tabs cannot be scrolled at all.
- on Android: the tabs can only be scrolled by using a two-fingers
gesture
This commit restore the horizontal scroll on the tabs but also keep the
swipe-gesture to navigate records.
opw-1929267
closesodoo/odoo#30658
As of 12.0 the superuser account (UID 1) is only meant to be used for
advanced debugging, and non-superuser admin accounts are used for
day-to-day administration.
Adapts the admin detection system to allow non-superuser admins to
select the report layout as well.
The payment reconciliation screen can't be opened if there is no partner
on a payment, and currently crashes with a traceback.
Rather than hiding the button which could cause surprises for users, we
can raise a proper error to explain why it can't work, for the cases
where a payment has no related partner.
This could happen for example when a customer paid via a direct
/website_payment/pay link.
When we use "Send invitation again" on a survey.user_input, it will send
the first survey.user_input it finds corresponding to:
- the state "new" or "skip",
- the partner it must be sent to,
- the survey the user_input corresponds to,
- the email it must be sent to,
or if none found, it could be create a new one.
This is an okay behavior in most instance, but in the case of
hr_appraisal where a manager could have same survey to fill for
"employee A" and "employee B" and when you send them again, we would receive two
mails linking to the same employee.
With this changeset, the current behavior is kept but when an existing
user_input is resent, we prioritize itself before searching a matching
one.
opw-1934478
closes#30693
Following revision 61eef73b52
the fallback to the standard external layout when
the external layout is not set on the company has been removed.
It therefore leaded to the raise of the exception
```
The report's template '%s' is wrong, please contact your administrator.
Can not separate file to save as attachment because the report's template
does not contains the attributes 'data-oe-model' and 'data-oe-id'
on the div with 'article' classname.") % self.name)
```
when the external layout was not set,
which could happen quite easily in a multi-company environment,
if you do not set the company external layout after having created it.
This revision simply puts back the fallback as it was before.
opw-1931195
closesodoo/odoo#30687
When using the "test import" feature to import leaves request, odoo
fails with a 500 error and no error message.
The only difference with a real import is that the test dry-runs by
rollbacking. The issue here is that mails are sent *after* a commit
is done hense crashes because they do not exist anymore.
opw-1916913
closesodoo/odoo#30523
When printing a delivery order in waiting state under MS Windows, the
produced PDF does not use the proper font for the warning line.
This leads to an unreadable line full of small rectangles.
The problem comes from the fact that the 'fa' class is applied to a full
paragraph.
With this commit, the proper 'i' tag is used to display the exclamation
triangle.
opw-1931892
closesodoo/odoo#30680
purpose:
when creating a writeoff from the manual reconciliation widget (invoices & payment matching), there's no way to specify the date of the writeoff journal entry
specs:
in v12, add a date field in the js and set the date of the writeoff entry accordingly
Was PR #29794
Was OPW 1896593
closesodoo/odoo#30676
OPW 1891131
closes#27497
When creating a new bank account/partner address, the view displays the 'state 'field before the 'country_id' field, which naturally leads users to select the state before selecting the country.
But there was problem: in order to select a state, one had to first select a country, which was confusing.
Done:
- allow the user to select the state before the country (without restriction on country)
- remove the state from the form when the country changes, if the state (name) is not in the country
- automatically set the country when the state is set
- always display the country code in the name_get of res.country.state, to deal with the case where different countries have a state with the same name
To reproduce:
1) Enable multi-company
2) Create two companies: c1, c2
3) Create two users: bob in c1 and alice in c2
4) Install subscription
5) Remove the ir.rule that forbid users from accessing subscriptions
made in other companies: "Subscription multi-company"
6) Using u1, create a new subscription in c1
7) Using u2, follow the chatter of the newly created subscription
allowing the user to post messages/log notes.
8) Using u2, send a message with an attachment. Access Error.
The problem raises only for the **first** attachment. That
attchement is written on the record as the main attachment thus
raises an error if the user doesn't have write access.
There is no problem to add attachment to any following record or
when the user has write access on the model. If the user doesn't
have access to the chatter, he is blocked before accessing the
write thus it is safe to sudo it.
opw-1915606
closesodoo/odoo#30659
Before this commit, clicking "Edit in backend" from the website could randomly
lead to the backend under another menu or without module, depending on the
other modules that are installed or version com/ent used.
After this commit, it will always open the backend under the specifiec menu
or website menu if not defined.
+ uses existing website dedicated action for product.template in 'Edit backend'
task-1919436
closes#30555
Co-authored by seb@odoo.comclosesodoo/odoo#30657
Before this commit, if you installed website in community you was not able to
install web_enterprise, because the web.login_layout was replaced (by hinerit)
by website and break the xpath from enterprise login.
Now we apply the Enterprise login xpath before that website replace it.
- Install Invoicing
- Multi company Set up with no common contact book
- Create & validate an invoice with user A in company 1
- Change to company 2 with user A
- Connect with user B in company 1
- Send & Print the invoice
An error is raised on the template rendering because user B cannot read
info from user A.
opw-1928676
closesodoo/odoo#30649
Steps to reproduce:
- Edit a record.
- Log a note or send a message with an attachment.
- Save the record.
Bug: changes made to the record are discarded.
Because uploading an attachment triggers a reload without 'keepChanges',
the record values are read from database.
However displayed values are not updated, so there is no feedback that changes
have been discarded.
On save, the page is reloaded so the user sees that changes have been lost.
Introduced by 7f97c9fc05.
opw 1923824
closesodoo/odoo#30642
A sale.order is an authorised model for mass mailing but it does not have
an email or email_from field.
When trying to send a mass mailing campaign on sale orders, an error was raised
as sale_order.email_from does not exists
closesodoo/odoo#30220
Have a Lead with the contact informations (Customer Name, Street,
Street 2, City, State, ZIP, Country) completed in the 'Followup' page.
Before this commit, when the base_adress_city module was installed, the
informations of the City, State and ZIP where lost when we try to create
a new Partner from the Lead.
Now, the informations are present in the Partner form; furthermore if
the country allows enforce cities, the information is also present in
the enforce city form.
OPW-1932018
closesodoo/odoo#30644
When using the datepicker with norwegian locales, the dates are
correctly formatted using the norwegian locale but the name of
the months are shown in english. This cause a date validation
error and thus it is not possible to change the date.
tempusdominus.js uses moment.js to deal with dates, it sometimes
copies/creates some and set their option according to the ones
given at instantiation time and fallbacks on default options for
that are not set.
opw-1922437
closesodoo/odoo#30276
In stock.picking, in mode show detailed operation, add a product with
unique serial number tracking.
Before this commit, a warning about the qty is raised. This warning,
must be raised only if the qty is different from 1.
However this is not the case,
the warning is raised at each modification of the line.
This issue occurs since the rounding given to the float_compare is 0.0,
because self.move_id.product_id is not set.
Float_compare with a 0.0 rounding always return different, hence the bug.
Now, the warning is only raised when the qty is different from 1.
OPW-1932044
closesodoo/odoo#30651
Before this commit:
1. If we were editing a template with no xml_id, typically the case when
editing a specific view (COW'd), the 'Template ID' label would be left empty
as the view does not have an xml_id but only a key.
2. If we were editing a generic view, the template would be COW'd and replaced
by the specific one created during the save.
After the save, the page would be reload and will try to reopen the edited
template (stored in url `res=123`). But as this template would be replaced
by the COW'd view, the JS would crash trying to access an inexisting view.
The HTML editor would then open in a very thin modal, barely editable.
Now:
1. Display the template's key instead of its xml_id. The key is basically a
duplicate of the xml_id, mainly used in website.
2. If we are saving a generic view, we search for its newly created specific
view to upload the URL hash before reloading.
task-1934279
Fix#30447
With the following view hierarchy:
A
|
B' (oe_structure_ID view)
Before this fix, when saving multiple templates at once from the same hierarchy
the COW views (website) would not be saved correctly as the first call to
`write` would COW the parent view, then the second concurent call to `write`
would create the child specific view under the generic parent view.
Instead, the generic parent should have been cloned to a specific parent view
and then the child view should be COW under the specific parent.
A A'
| |
B' B*' (This one is the old B', without B' changes in the html editor)
Instead of
A A'
|
B'
Calling the `write` one after another will do the trick. Indeed, when the
second call is fired, the first call has already triggered the COW behavior.
Thus, the second call correctly retrieves the COW view.
Another issue might still appear, if the parent view write is sent first.
Indeed, the parent view will be COW, thus the specific child view (second write
waiting to be fired) will be deleted to be added on the new specific hierarchy.
Thus, that write will then raise an error since the view does not exist anymore.
task-1934279
Fix#30447
Steps to reproduce the bug:
1. open an app such that there is a breadcrumb (e.g. an employee form view)
2. create a chat window with a user
3. click on the expand button to open the chat in Discuss
4. unsubscribe from the thread
5. click on the breadcrumb to go back
=> Traceback
When expanding the chat window to open Discuss, it registers a callback which
triggers an event on the mail bus. This callback is called when clicking
on the breadcrumb.
Because the channel was left, any related chat window is destroyed.
Since the widget is destroyed, it has no parent, so any service call
returns `undefined`, hence `getMailBus` returns `undefined`.
Fix: check if mailbus exists before triggering.
closesodoo/odoo#30640
Have a product of type service with :
- Service tracking : Create a task in a new project
- Project template : A project of the company
- Re-invoicing Policy : No
Create a SO with the product, and validate it.
Before this commit, when the project was generated. It was generated in
the company of the super user, and not in the company of the SO.
Now, the project is generated in the company of the SO.
OPW-1927005
closesodoo/odoo#30607
Instead of searching for the driver name and return thousands of partner
ids in the vehicule search, use a database join and a search on the
driver name.
closesodoo/odoo#29288
When thousands of invoices are in a different currency than their
corresponding journals, a large number of calls are performed to
`_get_conversion_rate`, and therefore `_select_companies_rates`.
Despite the fact that the query itself is optimized, the impact of
performances on the dashboard loading time is not negligible.
In order to avoid unnecessary queries, we create a cache dictionary to
store the rate values. This way, we avoid any unnecessary query.
opw-1920188
closesodoo/odoo#30552
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
closesodoo/odoo#30530
- Debug mode,
- Add multi-company to admin (user id 2),
- Create new company (company 2)
- Activate res.partner multi-company record rule
- Create invoice
- with first company (the default one)
- with a customer having an email address that doesn't exist
- Send a message in the thread, making sure the customer is in the
follower
- Wait for the message to bounce (red mail icon in the thread on the
given message).
- Change user to company 2 (in the dropdown menu next to the user
dropdown menu in the upper right corner)
- Refresh, access error, even in the app switcher.
This is because Odoo tries to display in the notifications the email
that failed, and crashes because the user doesn't have access to the
partner of the email.
We filter out the notifications related to objects that the user doesn't
have access to.
opw-1924359
closesodoo/odoo#30348
Create record A on form view, on which a dynamic domain is added by an onchange.
Switch to kanban view. Quick create a record B. Click edit.
This sends you to the complete form view to edit the record.
The dynamic domain of A is still applied.
When discarding the changes, the _domains attribute was not reset.
Example of a model on which this flow can be reproduced is helpdesk.ticket,
with _onchange_partner_project providing the new _domain.
test courtesy of @aab-odoo
opw 1920874
closesodoo/odoo#30308
Have one move with
- one debit in receivable with a partner which has a partner.category on it
- one other debit in receivable, without a partner
- one credit wherever
Open the aged partner balance report, filter partners on the relevant tag (partner.category)
Do the same with a move with an earlier date that will put the amounts in a different column
Before this commit, it crashed because some result variable did not contain
the key "False"
After this commit, it doesn't crash
OPW 1933749
closesodoo/odoo#30603
When the function '_select_seller' in stock warehouse is called, a
datetime is passed to it. But the method needs a date, so we modify it.
OPW-1930264
closesodoo/odoo#30563
Have a journal with 1 unpaid invoice and 1 refund to be paid too
Before this commit, the data on the journal's dashboard for unpaid invoice
was the sum of the refund and the invoice
After this commit, the amount of the refunds are substracted while
the amount of invoices are added
Also, the behavior is harmonized across other amounts
that display on the dashboard and tested
OPW 1924388
closesodoo/odoo#30395
In an HttpCase test, when the browser_js method is used, an optional
javascript code can be used to check that the page is ready to execute
the test.
When no 'ready' code is given it defaults to check the
'document.readyState' status.
In some rare cases (discovered by @Xavier-Do) this status is checked on
the 'about:blank' page. As the page seems ready, the test code is
evaluated and fails.
With this commit, when no specific ready code is provided, the test will
wait for a chrome devtools event that ensure the page is fully loaded
before starting the test.
closesodoo/odoo#30584
Description of the issue/feature this PR addresses:
Order of merged pdf reports when attachment_use = True
Current behaviour before PR:
When in a report the "Reload from Attachment" option was selected
(attachment_use = True), and multiple pdfs were printed, the singular pdfs
were stored in a dictionary and appended to a list and thus merged in a random order.
Desired behaviour after PR is merged:
By mapping the pdf with their source record, and sorting the list with the table _order of
the source records of the pdfs, we seek to have an ordered output pdf.
opw 1915685
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30402
When in a report the "Reload from Attachment" option was selected
(attachment_use = True), and multiple pdfs were printed, the singular pdfs
were stored in a dictionary and thus merged in a random order.
Now, we make a list before merging them and sort it with the table _order of
the source records of the pdfs to have an ordered output.
opw 1915685
Fabien Pinckaers