Purpose of this merge is to clean the way we manage exiting answer when
inviting partners or emails to participate to a survey.
When wizard finds that some recipients are already linked to answers it
displays a bootstrap warning with the name of duplicate recipients and
display the field allowing to choose between two options
* resend: send the same token and answer;
* new: create a new token and answer;
It will be useful notably with certifications support as number of attempts
to succeed is limited. Allowing people to retake certifications should be
made clear to survey managers.
This commit is linked to task ID 1935176 and PR #30689 .
Purpose is to clean a bit those fields. A field holding the number of send
invitations is added as well as a button. It allows to directly jump on
answer linked to an invite which helps dealing with private surveys.
This commit is linked to task ID 1935176 and PR #30689 .
A field exists to differentiate answers done manually through frontend of
survey and answers created through invitation. The field was not correctly
set by the invite wizard. This commit fixes it.
This commit is linked to task ID 1935176 and PR #30689.
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
- Set the OS in a timezone such as the current day is different from the
day in UTC (e.g. America/Nome before 10:00 AM or Australia/Melbourne
after 3:00 PM)
- Open any datepicker
- The 'little triangle' indicating the current day is wrongly set (one
day before or after)
Knowing that Odoo always creates momentjs date and datetime with the
`UTC` flag set to `true`, the `bootstrap-datetimepicker` does something
which seems inconsistent.
First, it retrieves the `viewDate`, and sets it to the beginning of the
month and week in:
https://github.com/odoo/odoo/blob/1c6c504215f3ef09e6336c92c9d350e87599eaa1/addons/web/static/lib/bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js#L725
In this part, it is important to note that each `startOf` functions
called sets the hours/minutes/seconds to zero. It means that the
reference time is changed.
Then, it iterates on this newly created date, and determines `today` by
comparing it to `getMoment()` in:
https://github.com/odoo/odoo/blob/1c6c504215f3ef09e6336c92c9d350e87599eaa1/addons/web/static/lib/bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js#L748
However, `getMoment()` returns the current date and time, but with the
`UTC` flag set to `false`.
Therefore, we compare a UTC datetime on which the reference time has
been changed to a non-UTC datetime, which fails to give the appropriate
current day.
There are two approaches to solve this. The first possibility is to
change the way Odoo defines momentjs dates and datetimes, maybe by
removing the `UTC` flag at creation. This sounds like a bad idea, since
other widgets or views (such as the calendar or the pivot view) make use
of them. This is likely to introduce a bunch of new issues with TZ in
these views. The second approach is patching the library to fit our use.
Although we usually don't do such a thing, this allows to specifically
solve this use case, and in particular placing the 'small triangle' at
the appropriate date without impacting any other part of the system or
the library. It can be easily performed by comparing the dates and the
months to make it work.
opw-1915251
closesodoo/odoo#30538
When printing multiple reports with the "Reload from Attachment" option
selected, the order of the rendered pdfs was not respected. Using an
ordered dictionary instead of a randomized one solves the problem.
opw 1915685
closesodoo/odoo#30690
This commit simplifies the code and improves the performance
of _compute_sale_order_count.
execution time from O(n^2) to pretty close to O(n)
Project : Performance Issues
Task : Geostaff : Success Pack 5 (100h) (opw-1912303)
With https://github.com/odoo/odoo/commit/ac8b0fcfc5299b5ea62543b8382cb419fed4868e,
the 'country_events' class was renamed to 'oe_country_events'. This was
done correctly for JS animations and snippets but not for the 'Country
Events' option in the customize menu. This made the option useless.
This commit solves the problem by supporting the two classes (as it
is a stable fix).
closesodoo/odoo#30662
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
Create and write rights are granted on portal and user.
We need to improve the security.
task-1934286
task-1862656
opw-1862218
opw-1862111
opw-1857912
opw-1861426
Github-24986
forum-135070
closesodoo/odoo#25671
Fedora 29 switched to python 3.7. It seems that there is no official
way to build a RPM package that could works with 3.6 and 3.7.
Building two different packages for each version could open the pandora
box of packaging.
With this commit an ugly hack is used: if python3.7 is found, the odoo
directory is symlinked into its site-packages dir.
fixes#30579closesodoo/odoo#30618
Usecase to reproduce:
- Set 1 unit of product A in stock
- Scrap 1 dozen of product A
Warning message for Insufficient Quantity is not triggered.
It happens because there is no UoM conversion between scrap qty and
product quant quantity.
Fixes#30570closesodoo/odoo#30589
- Create a SO with 2 stockable products: 1 is available, the other is
not.
- Validate, go to the picking
- Set the 'Shipping Policy' to 'When all products are ready'
The 'Unreserve' button disappears, while some products were reserved.
When changing the shipping policy, the state of the picking is
recomputed and set as `confirmed` ('Waiting').
We make the button visible in this state also, when 'Shipping Policy'
is set to 'When all products are ready'.
opw-1932658
closesodoo/odoo#30635
In a pos session:
OFFLINE
make an order with invoicing , try to validate
The order stays there because it needs to be validated by the server
make another non invoiced order, validate
ONLINE
make another order
At validation, all orders will be pushed to the server
Before this commit, when trying to validate the invoiced order
the report download couldn't find the order id, and crashed
This was because the order in question was already pushed
but treated as a non invoiced order
After this commit, an "warning" message is displayed to the customer
saying he/she has to print the invoice from the backend.
In most cases it is enough and acceptable, since a customer would actually leave the premises
and come back later for the invoice
It is also safer in terms of data consistency to keep pushing all orders once the connection is back
OPW 1918044
closesodoo/odoo#30485
Before this commit, the web client had a naive strategy to handle lost
connections: it tried to poll the server every 2 seconds until a rpc
succeeds.
This works quite well from the perspective of the user, but may be a problem
from the perspective of the server. If a server is down for a longish period,
then each users active tabs will then perform a request every 2 seconds. This
means that the server will be progressively hammered by many requests, which
will clutter the logs, and make it more difficult to gracefully recover.
With this commit, we simply exponentially increase the delay each time, and add
a little jitter to give a better distribution.
Cherry-pick of 4a3f04bcc5closesodoo/odoo#30136closesodoo/odoo#30596
Have a tax that has a different account for refunds
make an invoice and its refund
Before this commit, the refund's tax is still in the old account
After this commit, the refund's tax is in the account for refund defined on the tax
OPW 1907950
closesodoo/odoo#30325
In case the discount product is misconfigured and therefore not loaded
by the POS, a traceback appears when applying a discount.
Add a comprehensive error message instead.
Closes#30574
opw-817527
closesodoo/odoo#30582
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes#30567
The sale.order model has an expense_policy selection field, with values in 'no',
'cost', 'sales_price'.
However that value can also be set to False.
The code that handles that field expected the value to always be set to a value.
We explicitly treat False as if it was 'no' (the default value for that field).
opw 1915508
closesodoo/odoo#30336
Commit f727e9d9b6 made the rating field
of mail.message non-stored for performance reasons.
When the rating is activated on the website, it adds the possibility to filter
product reviews by rating (1 to 5 stars).
It does so by searching the messages that have a given rating value.
However the osv complains that you can't search on a non-stored field.
As a result, instead of displaying messages filtered by ratings,
it would always display all of them.
We add a search='_search_rating_value' on the field to allow that field to be
searched anyway.
opw 1931038
closesodoo/odoo#30499
Before this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb do not preserve translation
warning.
After this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb preserves translation warning.
Technical note: alertFields is now an object and an attribute
of the form renderer
that stores translation alerts per record. The translation
alerts
created for a given record are maintained unless
they are closed manually or the renderer is destroyed.
Issue-ID: 1877480
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#29377
Thibault Delavallée