By default, an event can be modified by any employee. This is also the
case for private events, displayed as "Busy" to other users. However,
since any user can modify an event, nothing prevents him to change the
privacy setting in order to be able to see the content.
This commit introduces a global record rule which only allows the
followers of an event to modify it.
opw-705079
Thanks to this commit: 342dad44cd
(1) Asset Account
(2) Depreciation Entries: Asset Account
(3) Depreciation Entries: Expense Account
Now it's possible in 9.0 to set the account_income_recognition_id.
So in the case of a vendor bill if the account_income_recognition_id(3) is set,
it means that the depreciation entries are debited on this account(3).
Then the asset account can be used on the invoice line.
NB: When the account_income_recognition_id(3) is not set, it means that
The Asset Account(1) is used to debit the depreciation entries so it cannot be used as an asset account.
In this case, (1) is used as (3)
And the Depreciation Entries: Asset Account(2) is used as (1) and (2) because the all assets are first debited
on this account and progressively the depreciation entries are credited on this account too.
This is why in 10.0, there is an onchange on account_asset_id on model "account.asset.category" which sets
the same value for (1) and (2).
Example with account_income_recognition_id set: Purchase of 100k with a 5 years depreciation:
on (1) debit=100k and credit=0
on (2) each year debit=0 and credit=20k
on (3) each year debit=20k and credit=0
Example without account_income_recognition_id set: Purchase of 100k with a 5 years depreciation:
on (2) debit=100k and credit=0
on (2) each year debit=0 and credit=20k
on (1) each year debit=20k and credit=0
This behavior can be analysed in function create_move on model "account.asset.depreciation.line"
opw:702265
The VAT declaration produces an error when uploaded to the official
website. Although the structure is correct, the "Representative" and the
"Declarant" contain the same information, which is not consistent.
opw-702066
Both store triggers on reconcile_ref are triggered by the same condition,
but seen on 2 tables different, but they always happen together, so no
need for both.
On regular Odoo, the only problem is the performance: the write operation
is performed twice, but on a system with connector or other parallelization
technology, this provokes lot of concurrency problems.
This fix allow to keep the same behavior of 8.0 and 10.0 to manage the assets.
In 9.0, the field account_income_recognition_id(oldname='account_expense_depreciation_id') has been
deleted from the account.asset.category.form view with 6120babb45 and
then it was not possible to manage the assets like in 8.0 and 10.0
But as this fix is in a stable version, it must be compatible with instances without any upgrade
of the view account.asset.category.form.
This issue has been solved in saas-11 with this commit: eb8d4aaa59
opw:703860,702265
When you are connected as a portal user, you can access to the list of
company users when you try to create a channel of type "Direct Message".
This is caused by a SQL request that doesn't check the access rights of
the user before returning the list of users.
To fix this, we check that the user can create a mail channel, before
returning partners information.
opw-704127
When you are connected as a portal user, you can connect to the
backend of Odoo and if you go to your discuss app through the '@' icon,
you can list the employees of the company by mention a employee
This is caused by a SQL request that store in cache the employee
list to minimize requests when mention. The problem
is that those requests don't take into account the rights of a user
to read employees information.
To fix this, we are taking the group 'base.group_user' and read the
information of its users, the 'read' is respecting, the access rights of
the users, and so the employees names, are ont shown anymore to portal
users.
opw-704127
When a journal item duplicated, the matching number is duplicated as
well. This will create inconsistencies in the information displayed to
the user, and moreover it will not allow to reconcile the item anymore.
opw-704902
On a picking, the UoM of the weight is the default UoM for the weight
category. However, weights in Odoo are always considered to be
kilograms.
This might lead to inconsistencies between what is displayed on the
picking and what is printed on a shipper label.
opw-702564
- Y axis : according to 12 hour or 24 hour format
- Event title : following time format in preferenced language
NB: The conversion from 'A' to 'TT' to match fullcalendar v1 should be
removed when fullcalendar is updated to v2, as the syntax will change.
See : http://fullcalendar.io/wiki/Upgrading-to-v2/
Backport of commit c1d813ec1c
opw-704237
By default, the default warehouse of a sale order is the first warehouse
of the company of the user creating the sale order.
In the case of a sale order created from the website,
the user who is creating the sale order is the superuser,
a.k.a the administrator.
There was a big issue in the context of a multicompany database,
with an administrator changing of company:
the sale orders coming from the website would suddenly change
of company, which is wrong.
This was even more severe when the admin changed to a company
which had no warehouse defined:
It was then impossible to create the website cart, as no default warehouse
was found, while the warehouse is a required field on the order.
This revision ensures that the cart / sale order is always created
under the website company
opw-704557
With the previous condition, the `final_date`
was not recomputed when the number of repetitions
(count) was changed alone, without changing `recurrency`
(nor with other fields, such as start/stop date)
This revision makes sure to recompute the `final_date` when
there is a change in the number of repetitions without
changing the `recurrency` fields, when the event is recurrency
and the end type is `count`
opw-703812
The double inversion introduced by 6e063188 is done to catch default 0
values.
For example '>= -3' is transformed in "NOT what is found by < -3".
There was an issue with '> 0' and '< 0' since in these instance 0 don't
match and the inversion must not be done.
opw-703929
If the user enters an incorrect grouping format, login won't be possible
anymore since the web client will crash when parsing the field value.
For example, "[3, 0,]" will trigger the issue.
Complement of commit 5959c41631
opw-704388
In 3041efb, it was introduced a partner_id reset when project_id is
False, but this causes you can't apply default values to partner_id
directly.
One use case where happens:
* Go to Sales > Customers.
* Select one customer.
* Click on the smart-button "Tasks".
* Create new task.
Before this commit, the customer where you come from is assigned.
After this, no partner is selected.
If the user writes a password larger than 4096 characters at the login
screen, it causes a crash instead of displaying the "Wrong
login/password" message.
The Python library used to hash password (passlib) is by default limited
to 4096 characters. Above this limit, it raises an error (source:
https://pythonhosted.org/passlib/lib/passlib.exc.html).
Allowing a password larger than 4096 is not necessary, we just limit the
field maximum length since such a situation should happen because of an
incorrect copy/paste.
opw-704110
When you pass a dict to `.with_context()`, it completely replaces the context,
removing the language from it.
This causes that when the publisher publishes a slide in another language, the
template gets mixed languages rendering.
Closes#15017
Fine tuning of this commit: 69c41c7
When cancelling a payment, the remove_move_reconcile function was called and
it removed the payment from the invoice and in the payment history, only the
validated payments were kept.
This commit keeps the behavior before this commit: 69c41c7
opw:691692
Set the company rounding policy to "Round Globally". Create the
following SO (or PO), with a 7 % excluded tax:
- Qty Price
- 880.000 5.79
- 120.000 4.36
- 28.000 2.88
- 68.000 11.09
- 35.000 5.20
- 35.000 5.32
The total tax on the SO is 477.48, while it is 477.50 on the invoice
generated from the SO.
FORWARDPORT UP TO 10.0
Fixes#13687
opw-703519
An italic node would be taken as a basic node containing text and thus
would be merged unexpectedly.
For example with the following content : "<i>hello</i> world" removing a
letter of 'world' would merge the text node with hello making it italic.
opw-703722
This commit fix wrong grouping when we format price via price_to_str.
where '[3,0]' was interpreted as string and not array in intersperse.
Thousand separator was duplicated ",,,320.00" e.g.
This commit fix also product page where amount for variant was formatted
js side before that RPC translation (website.ready() defered) was resolved.
'/website/translations' is only called when user have rights to edit page.
So a standard user didn't call it and l10n is not initialized.
After an update, now we format the amount with the l10n value.
To stay retro compatible, if l10n is not initialized (value = [])
we use [] for grouping as 'fallback value'.
To fix decimal precision you need to update the template product_price.
To fix the grouping, you need to update the website.layout
To fix the decimal separator, (and previous fix), you just need to pull the JS
This commit is related to #1103, #11553, #14772, #14874, ...
And fix the previous fix odoo/odoo@1f10ef8055
It should also fix (by side-effect) the translation JS for user without editor
right.
Already fixed in V9 - don't forward this commit...
Users who get an error 400 due to an invalid CSRF
token might be doing something legit. For example
they may have opened the page with the HTTP form
2 hours before posting it, and let the CSRF token
expire naturally (default lifetime is 1h).
In this situation the "invalid CSRF token" message
might be too cryptic for them to understand that
they need to refresh the form and try again.
Mentioning that their "Session expired" as well
should sound more familiar and lead to the right
reaction.
Revision 20935462a0
introduces the below regression:
When registering a payment on a customer invoice refund
or a vendor bill, with a payment difference
e.g. payment of 101 for an invoice of 100
and marking the invoice as fully paid,
the counter part in the payment account move
were wrongly computed:
In those cases,
its the payment total minus the invoice residual total
that must be performed, and not the other way around.
This revision solves this, inspired on how
the payment difference is computed for display
in the wizard on how it was before the above revision,
in the method `_compute_payment_difference`
Fixes#15000
In some case (for example the one solved with b51d21c5) we can have
write done on a field text in read only mode.
With 98ed53ce if :
- such a case happened (in b51d21c5 the fix only worked after the given
field was written one time) or a similar instance,
- and the user was in debug mode,
- and the widget used was TextFieldHtmlSimple
this could lead to an issue with the code trying to toggle the code view
mode whilst the editor is closed.
Suppose the following usecase: you scan the first product of the
picking. A server onchange is then triggered. You scan the same product
a second time, before the first onchange has returned. You expect that
the first onchange is completely executed before running the second one.
This was not the case. Moreover, some onchanges were not be able to
work with the invalid state of the formview at some times, and crashed.
The previous implementation was wrong because id didn't run the main
barcode processing mechanism inside a Mutex. It was also wrong because
it didn't correctly wait for the onchange to execute (a previous barcode
onchanges or some classic ones) before setting the barcode field.
With 98ed53ce when a form view is saved when a html field is in code
view mode, the change is not lost.
This new backend tour check that when saving in or not in code view, the
content is saved effectively.
The test not in code view would ensure issues like #14381#14351#14394
are detected on runbot.
closes#14475
opw-693052
note: the old test system is used so this test is only for up to saas-11
The intended scenario when using the code view is the following:
1) click on code view button to use code view
2) make changes
3) click on code view button to get back to wysiwyg view
4) save from the wysiwyg view
If the 3rd step was not done:
- for the inline editor, we lose the changes that have been done in
code view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
fixes#14648closes#14475
opw-678677
opw-693052
In e0c4ec54ca a change was done to improve the behavior in some
editable list instances, but this introduced a small issue for
list with line creation disabled.
With this change, doing tab or enter at last line should keep the
previous behavior of wrapping around and not creating a new line.
opw-703748
The number of records selected by a FieldCharDomain was only computed
with the base language.
But when selecting the domain with a modal window, or when sending a
mass mailing restricted to a domain, the current user language is used.
With this commit, the number of records is computed with the current
user language.
opw-693836
Nicolas Martinelli