The `timesheet_uom` is a fake widget: it is bind in field widget
registry on other existing widget depending on the session_info
preferences (e.i.: float_time, float_toggle, ...). Therefore, it
does not have formatter/parser methods in the field utils method.
This commit binds the formatter and the parser of the widget on which
`timesheet_uom` is bind, to make it coherent. This avoid having a
traceback on pivot view when the `timesheet_uom` widget is set on
a field node.
The default value when creating a project is true for 'allow_timesheet'
field. This will automatically create an Analytic Account (if not
provided). However, the old onchange reset the allow_timesheet to false
if no AA was given, which is a contraction with the expected behavior
on project creation. But, we might want to uncheck 'allow_timesheet'
when we remove the AA on an existing project (Users can not log
timesheets without an active analytic account).
This commit fixes the erasing default value on creation by checking
the record is currently existing in the database.
Task #1886691
The calendar view does not make many sense for timesheet. Moreover
recording timesheet from it is strange since there is no end date
on the timesheet model.
Removing this view avoids confusing for users.
Task #1883326
During the super of write, a check constraint is done
in python. So, if writing allow_timesheet=True the constraint
will raise is no AA is set on the project.
This commit restore the exepected behavior.
Since the employee is not required on a timesheet, and that
the employee implies the uom, and that the UoM is required
for the timesheet unit amount to be included in the delivered
quantity of a SOL, we now deduce the uom from the company of
the AA, and not from the company of the employee anymore.
When coming from project form view, the user can see
the list of timesheet. Before this commit, the employee
does not appears in the columns, which makes the view
less usefull for users.
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
When a subview is defined in a form view, the fields_view_get
extracts it from the global view arch returned. So extending the
field_view_get does not work to change label on subview.
This commit make this work by extending private implementation
instead.
Task #39079
Impacted modules: hr_timesheet, sale_timesheet
When task is changing project or sale order line, we
don't want anymore to change the linked timesheet.
We now consider a timesheet is done in a specific time
at certain condition that does not have to change when
the environment is modified afterwards.
So, a timesheet linked to an analytic account for a
certain project on a task (and mybe linked to a SO line)
will still be linked to the same object if the task is
billed with another SO or move into a new project.
The idea is task actual configuration (project, AA, SO
line) are the default value at timesheet creation. As
consequences, timesheet from another project can be linked
to a task that does not belong to that project.
Project and task can be modified thougth the UI of timesheet
app. SO line and analytic account of a timesheet can not
be modified as they are more sensitive field (in a business
point of view), especially for invoiced timesheets.
This commit revert opw-1803811, as at that time the
'inheritS' between project and AA was still effective,
and there was only one billable type (task rate) for
task. The introduction of 'employee rate' billing type
will complicate timesheet transfert.
Tasks #34703
The option `digital` has been added. It allows to display "01:00" instead of "1
hour". This behaviour was implemented in a report (timesheet) but the logic
was done in the XML, which is not adequate.
This commit also allows to have a negative value for this widget.
With the report editor in Studio, some reports were not easily editable (not
idiomatic XML, too much Python logic in XML, etc.).
These reports have been cleaned up.
Since uom management has been extract in a separated module, we
can now add the possibility to use it without product.
This commit brings the ability to record the timesheets in
an different UoM than 'Hours'. The user can now set an encoding
UoM for its timesheet on the company. This will display the
timesheet field `unit_amount` with a different widget.
For instance, timesheeting in hours will still use
the traditionnal float_time widget, when timesheeting in 'Days'
will displayed a toggle button with a range of defined possible
values.
The widget used by UoM is customizable on the UoM. The `unit_amount`
field should now be decorated with the 'timesheet_uom' widget.
This one will bind the correct widget (float_time, float_toggle, ...).
If the encoding UoM has no widget associated, the fallback will
be 'float_factor', using the uoM converstion factor.
Everything will still be stored in the database in 'Hours' (the
UoM set on the `project_mode_time_id` field on the company).
For more details, please have a look at the subcommits.
Task #39079Closes#24893
We want the UoM name (encoding timesheet) to be
displayed in the label of unit_amount field.
To do so, the field_view_get is extended to change
the label on the field decorated with the `timesheet_uom`
widget, in the view arch
If a string attribute is set on the field, it is prior;
so we only add label if no one is set to avoid breaking
view inheritance.
Task #39079
This commit provides a mecanism to allow user
to log their timesheets using any time UoM
they want. Everything will still be stored
in hours in the database (in the UoM selected
with project_mode_time_id field of the company).
The chosen encoding UoM will provide a widget to
help the encoding (float_toggle for Days,
float_time for Hours, ...). The widget will use
the UoM rate conversion.
Task #39079
As timesheet duration (unit_amount) is already
stored in hours in database, the pivot reporting
view should use the float_time widget, even when
encoding in days.
Task #39079