This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose: improve understanding of partner and product models as well as their
daily use. This is done by improving tooltips and labels of some fields
according to business logic.
This commit is related to task ID 1880696 and closes PR #27133 .
Thanks to @xmo-odoo for its in-depth review.
The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
The activity was incorrectly scheduled with a deadline as the now in UTC while
the state was computed using "today" in the user's timezone.
This made the nightly test fail (run at 23:30 UTC with the user in UTC+2).
Use context_today instead of today for all activity_schedule calls
To make it easier, use on the context_today default value instead of setting
context_today everywhere (which is more error prone in the future)
Never use datetime, only date objects
add a warning to detect potential errors when passing a datetime
Closes#26411
Search, form views and menu cleaned
Hide attachment button when you can not attach (record not created)
Allow to submit multiple expenses of different payment mode
list: show creation date on reports, accounting date for accountants
We need to be able to change an expense report before submitting it, for
this we add a new step in the expense process (a draft state for the
expense sheets).
Task #41700Closes#24806
Purpose is to limit the uninstallation of modules without being clearly
notified of it. In expense ticking sale_expense repair / maintenance install
and uninstall sale modules and its dependencies.
We therefore decided to remove those options from settings to prevent
users from uninstalling it.
This commit is related to task ID 1841221.
Currently the distinction between expense officers and expense managers
doesn't make sense because they both have the same rights.
This commit aims at making a clear difference between an officer and a
manager.
After this commit the rights will look like this :
* Expense Manager :
- See and approve any expense
* Expense Officer :
- Can see and approve the expenses of employees in his department
or employees for which he is the manager (field parent_id on
hr_employee)
- Cannot approve his own expenses
* Simple user :
- Can only see his own expenses
- Can only send his expenses to a manager (either the manager of
his department, his direct manager [parent_id field] or an
expense manager)
Related to task #51520Closes#23033
- Set a specific expense account on an expense product
- Send an email to the expense alias
The specific expense account is not used; a default account is used
instead.
opw-1838174
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Currently a lot of people are automatically added as followers of expense
reports. However most of them (managers notably) can choose what to follow
using subtypes on the department. We should avoid adding too much people
as following records should stay an active choice made by users.
From now on auto subscription works on
* employee of the expense report, if he has an user;
* responsible of the expense report, that is the expense manager or the
manager of the employee;
Expense report creator is not follower of the expense report by default
anymore, as previous values should be sufficient to ensure people having
to work on the expense report are already followers.
This commit is related to task ID 1819541.
Expense report has custom code to add people as followers. This code has
several issues, notably in some cases it could try to add several times
same people, leading to crash and issues.
As auto subscription has been cleaned let us clean the code in hr expense.
Using _message_auto_subscribe_followers it is now simpler to automatically
add follower to expense reports. It is not necessary to add hackish custom
code in create and write.
One change is done in this commit. Some people are set as follower after
record creation and not before. However this was necessary when tracking
messages were not correctly triggered or auto subscription done after
tracking. As process is now 1/ create 2/ auto subscribe 3/ tracking, messages
linked to tracking will be correctly push to recipients automatically added
as followers.
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
This commit improves expense flow management through a better integration
of activities and addition of automated activities. Several things are done
in this commit :
* expense sheet (report) model do not inherit from mail.activity.mixin.
This commit adds the inherit so that expense users and managers can now
schedule and manage activities on expense reports. This will help them
in their daily job;
* automatic activities generation is added for expense reports. Activities
are generated for approval. They are also automatically set as done when
validating or unlinked when refusing or resetting to avoid bloating users
with unnecessary activities;
* a menu to configure activity types is added. Indeed HR managers should be
able to see and configure activity types related to their job;
* filters are added to be able to use the systray and to filter the kanban
view based on activities
Having automated activities allow to replace some messages and tracking
that were implemented to warn people of expense reports to approve.
This commit therefore
* simplifies the tracking as tracking to confirm reports is not necessary
anymore;
* removes to approve subtype on report model as well as its parent subtype
on the department. This allows to simplify chatter in hr_expense app;
Since e9734f4975 assignation is now a notification sent in the
inbox or by email to the newly-assigned responsible. It is therefore
considered as not necessary to link a subtype to the assignation itself.
Indeed having it logged in the discussion history as a classic tracking
in addition to the notification is considered as sufficient.
This commit is related to task ID 60790. Closes#23244 .
Before this commit:
Expense emails title are parsed to find a product that match the given [CODE].
For example, an email title like '[CARD] Graphic Card $900' will create an
expense for the product having 'CARD' as internal reference.
Since the search is done with an 'ilike' and with no 'limit', it could return
multiple product: all the one containing the CODE in their internal reference.
This would throw a singleton error when trying afterward to read product.id.
Then, the mail would not go through the mail.thread flow and it would return
a Mail System Delivery fail saying the address does not exist.
Users would get stuck with this, having no way to understand where the error
comes from.
Now, we ensure to find only 1 product.
To avoid breaking the ilike behavior that could be used by users only typing
the first caracters of a long CODE, we still use ilike but force exact match if
there is multiple results.
Closes#23419
opw-1816340
Hr_expense add several people as follower of expense reports to ensure
various responsibles are notified. However depending on configuration
same partner could be added several times in an ORM command. This makes
the unicity of partner_id for a given document crash.
This issue has been introduced at ab8f5ec95d when working on task ID 30933.
* crm, hr_expense, mail
The nocontent helper can be generated either statically (in xml)
or dynamically (in python).
Before this commit, the result of some nocontent helpers was simply
the concatenation of the static and dynamic parts.
Due to recent changes (see https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417),
the nocontent helper has changed so that any of the nocontent helper
parts has to define its style for showing the face (e.g. smiling,
neutral, or folder face).
As a consequence of the changes above, the styles of some
nocontent helper screens were duplicated, e.g. two smiling faces
were shown instead of a single one.
With this commit, most dynamically generated nocontent helpers keep
only the dynamic part, so the static part is usually dropped in this
case.
Exception to above rule:
dyn_help = 'You could also add a new [document_name] by sending an email to [email_link]'
The dynamic part is appended right after the static help message, in its dedicated paragraph.
New rights were applied on hr.employee with this commit https://github.com/odoo/odoo/commit/2d777d5ade94f4a80862608e2807660f289d9923
Since, users with limited rights would see a read error when submitting an
expense to manager.
Indeed, when clicking on "SUBMIT TO MANAGER", it opens the view form for
'hr.expense.sheet' that trigger an onchange on employee_id to set the
employee's private address to the expense.
Since restricted users can't read that field, the rpc call to that onchange
was throwing an error resulting in:
1. Showing an read error when entering form view that user could close to
save anyway.
2. The hr.expense.sheet address would not be set as it should have
Now, we give sudo rights to read that field during the onchange
OPW-815786
* analytic accounts can be shared among companies
* amount on analytic lines always refer to amount in company currency of which it belongs to
* add analytic groups (hierarchical way to classify analytic accounts)
* analytic tags:
- only present on analytic lines, not anymore on analytic accounts
- can be used to distribue/split an analytic lines among several analytic accounts
- enabled by a dedicated res.group
- added on several objects (vouchers, expenses, analytic defaults...) as well as in bank statement reconciliation widget (manual counterpart and account.reconcile.model)
* bunch of fixes made related to analytic
Was PR #22124. Was task 32386. Original work by tbe.
Impacted modules: sale, hr_expense, sale_stock and
sale_expense.
The reinvoice policy has nothing to do with the
fact a product can be expensed or not by employee,
because of the vendor bills use case.
You can only choose reinvoice policy of your product
when hr_expense is installed, which is not very intuitive
for users. So this commit makes reinvoice policy field
always visible when sale is installed. 'can_be_expensed'
field determines if the product can be used in HR expense.
However, since reinvoice policy does not make much sense
for stockable products, we hide this option and reset
it to 'no' when sale_stock module is installed, as we
don't handle stock for those expensed products (when
confirming expense, the product is already delivered).
TWA