This commit modify the kanban card for maintenance requests/team:
For maintenance request:
Kanban view:
- Move the star priority from right to left
- Add the text 'request by' before the field owner_user_id
- Add the field for the technician with the text 'responsible'
- The image is the responsible and not the owner anymore
Forw view:
- Change the label for name from 'Subject' to 'Name'
- Change the placeholder for name from 'Maintenance Subject' to 'Maintenance Request'
- Request date field is read only and set to the date where the request is created
- Close date is read only and set when the request is in a done state
- Category is invisible if the related equipment has no category.
- Disable creation and opening maintenance team from the form view.
For maintenance team (dashboard):
- To Do button filter requests on their state
- Team name link to maintenance requests belonging to the corresponding team
Technically, there are just basic changes in the view.
This commit changes the maintenance team:
-In the form view -> replace Category name by Team name
-Replace the partner by a many2many with users
-Display the from view instead of editable list view of teams
In the model, the partner field is replaced by member_ids.
However this field is never used except in the form view.
The feature added is a count of todo request that has no schedule date.
It will also add a link in the team dashboard that redirect to all
mainenance requests without a scheduled date.
The count is computed in the existing function '_compute_todo_requests'.
It will count requests that are not done and have no scheduled date.
This commit also modify the view and add the default filter 'unscheduled'
(created by a previous commit) for the action
'hr_equipment_todo_request_action_from_dashboard' which opens the maintenance
request for the active team.
This commit add the following feature :
Add the responsible and the owner of the maintenance request as
follower.
This commit creates a new method that adds as follower the responsible and/or
the owner. This method is triggered in the create and in the write if they
are modified.
It will not remove old responsible or owner from the chatter.
When fetching record, `bin_size` needs to be passed in the context
to notify the server to send the `bin_size` and not the whole base64
of binary fields.
Before this rev., if concurrent calls to 'read_follower' were
performed, it might happen that the read followers appearead twice
in the follower dropdown.
This was for example the case when validating an invoice: the
customer was listed twice as follower.
Note: in this particular case, the record shouldn't be reloaded
twice: this is another bug to adress.
Moves back the mobile rendering part of the FieldStatus to
enterprise, alongside all other tweaks to improve the UX in mobile.
This part had been moved to community inadvertendly in the new
views branch.
This commit proposes to store the complete name of a product category.
It is formatted like parent.name / name, recursively. Storing it and
using it as a rec_name allows to search products belonging to a category
or its child categories without having to rely on a strange hack of
name_get and name_search.
Searching on products having a category containing "all" will get results
from "all" category as well as "all / saleable", and so on.
The sequence set by function next_by_code for a company must be
either defined for this company or witn company specified on it.
In the other cases, the sequence "NEW" is used.
With courtesy of @odony
opw:728554
Critical improvement,
`:)` was making a laughing guy that could be considered as mockery.
This smiley is way more friendly and should improve support feedback by at
least an order of magnitude better, maybe two.
Closes#16672
This commit merges various usability and business flow improvements
in time tracking application. Please refer to under-commits for more
details. Main changes are
* simplify user experience when logging timesheets through UX, filters
and menus improvements
* log timesheets on employees instead of users
All tribute goes to @jem-odoo .
Sale module now installs sale_timesheet module and not its auto-install
enterprise bridge. It seems more intuitive to installe real applications
and let bridges automatically install themselves.
Some wording is also improved to ease user experience through the various
timesheet related blocks of settings.
This commits mainly switches the semantic of timesheeting from users
to employees. Main points of this commit are :
* add an employee_id field on timesheet;
* replace user_id field by employee_id on timesheet views;
* provide a stat button on employee form view to access its timesheets;
* use timesheet cost as a real monetary field and handle currency
conversion;
The purpose is to allow timesheet manager to record timesheet for
employees that are not users. All employees do not necessarily have an
user account in the system. Now you can record timesheet for your employee.
Hooray !
In sale_timesheet timesheet_cost is now a monetary field. Currency convertion
is also better taken into account when computing UPDATE ME
Timesheet details
* add an invisible timesheet group on employee form view allowing to
hook on it. Indeed sale_timesheet and timesheet_grid modules override
this view to add information but have no other common module that
hr_timesheet. Using an invisible group set as visible in those modules
eases inheritance.
Sale timesheet details
* timesheet_cost is now a monetary field
* better display of timesheet_cost on employee form view, notably telling
it is per hour
* remove account_id field on employee as its only use was buggy and was
mixing account.account and analytic.account records.
Purpose of timesheet module is to track user time. This commit applies
various improvements and tweaking to better reflect this purpose.
This commit provides some UI improvements
* improve views : user_id field is not displayed on 'My Timesheet'
action, since it will always be the same user;
* simplify menus : 'My timesheet' only for current user's timesheets
and 'All timesheet' for everyone's. The latter one allows creating
timesheets for someone else, if you have the required access rights;
* add calendar views for timesheets
* some filters are added to ease time-based filtering of timesheets
This commit also reorganizes user groups. Groups are now
* new 'timesheet user' group (different from base.group_employee). Users
can record their own timesheet. New access rights were added to perform
the same operations as before.
* 'timesheet manager' (hr_timesheet.group_manager). Users can record
timesheets for other users, access to settings and reporting tools.
This commit removes document count on project kanban view. Indeed it
does not add much valuable information and bloats the kanban cards.
In order to keep the kanban card order, it was required to adapt all
inherited views. The order is 'task', 'issue', 'rating', 'timesheet'
and 'forecast'.
It also uses a read_group to better compute task count, by the way.
This commit proposes to add 35 and 38 hours/week resource calendars.
Those are considered as standard for a lot of countries. This helps
users starting with odoo time tracking.
When closing a session with cash control enabled, the session is no longer
directly closed and allows to resume selling.
This allow to have the same behaviour with cash control enabled or disabled
when clicking on the close button of the pos dashboard.
#15919
We changed the do_action method recently: before, it was calling
recursively its parent, now it simply triggers up an event. We also
moved it to the 'services' mixin. However, we did not properly connect
the 'on_success' option: it is not an option for the view manager, but
for the abstract web client. As such, it should not be in the options
parameter, but it should simply be a key in the event payload.
This commit was found by solving the two following issues:
- open sale application, click on 'Inbox' icon to go to discuss,
Discuss is opened, but the navbar stays with sales application
- after installing module website_crm_partner_assign in kanban view for apps,
it does not reload...
Both of these were caused by the need to do something after a do_action,
and the deferred was not resolved at all.
This reverts commit 75d9674d4 and revert well 551719a81e which wass done
on mail.mass_mailing instead of mail.template (on which it should not be
done).
Mass mailing `mail templates` when selected in a mass mailing are
always used in the english version.
But when another language is involved the edition of mass mailing
`templates` had a number of issue. For example saving the edited english
would only modify the user current language.
These issues are cause because the widget with snippets used for mass
mailing templates edition is not compatible.
Several fixes were proposed, what was choosen finally was to use the
correct widget with the following behavior changes:
- the snippets are not showed anymore in mass mailing templates,
- the current language can be edited and is saved rightly,
The shortcoming this give mass mailing templates can be partly
compensated by:
- editing the template back (if someone want the old behavior),
- duplicating mass mailings which keep the snippets and translations,
- doing a customization to improve the situation
closes#16255fixes#16165
opw-726746 opw-727232
note: this fix is only needed for 9.0 and saas-11.
When creating a pad before this change these were the steps:
- modify pad URL for new pad URL
- end of record loading
This caused an issue because modifying the record at this point would
mark it as dirty before displaying it (which would result in a erroneous
warning "The record has been modified, your changes will be discarded.
Are you sure you want to leave this page ?").
With this fix:
- modifying the pad URL is done after the record is ready
- deferred have been unified (to remove possible race conditions)
closes#15239
opw-702797
forward port note: this change is needed up to saas-15, over saas-15
only a small part is needed (because x2many views are loaded with the
root view and there is one widget instance per record).
code note: it would be better to modify load_record of form view and
delay `record_loaded` upto after x2many views are loaded, but possible
impacts have been judged too risky so this is done only in pad widget.
When a PoS order is closed, the payment and the sales journal item are
not automatically reconciled. This potentially leaves a lot of
unreconciled entries for a customer, which will appear in his follow-up
report.
This introduces an auto-reconciliation process upon order closing. The
process restricts the reconciliation to an order individually, i.e. we
don't try to cross-reconcile several orders for a customer.
opw-697565
Add missing sudo to allow a user without accounting rights to close a session
and reconcile entries.
Closes#16517
The context sent when performing RPCs is a mix of several contexts
(user_context, action's context, context defined in a field's node
in an arch...).
In general, the action's context should not be mixed with the
field's context:
- for global RPCs (read a record, write a record, default_get...)
only the action's context should be given
- for RPCs triggered by fields (e.g. name_search in a m2o), only
the field's context should be sent.
The exception is for onchange RPCs, as in this case, both action
and field's contexts should be sent.
Before this rev, the action context was always sent, which might
produced tracebacks (e.g. go to Sales > My Pipeline > New > click
on Customer field > Create and Edit > boom).
Haresh Shyara