1. Rename "Progress (%)" into "Working Time Recorded"
2. Remove tooltip.
3. It should always indicate the exact percentage :
a. if 2 hours planned and 2 hours consumed = 100%
b. if 2 hours planned and 3 hours consumed= 150%
c. in both cases the progression bar should simply stay full.
4. Consider sub task hours
Before this commit, many2many list views in wizards did not
handle the blur event at all, which means that the last edited
line was ignored. This is quite a large bug, but not really
visible in our standard install, because we had no many2many
in wizards.
This commit add naive support for blur events. This is only
intended to help the MRP team. A complete solution would
probably involve moving most of the code in One2ManyListView
to X2ManyListView.
Before this revision, a small function in sale was extended by
sale_timesheet to know when to (or not to) create an analytic
account for a SO.
This was nice, but since it was extended only in this module,
there's no real need for the added complexity (*reading
complexity*)
For the sake of consistency with other views and general usability, the user is allowed to create new tasks and projects from the timesheet lines list view.
Resizing a workcenter line is confusing to the user since a resize
only changes the `date_planned_end` and recalculates the `date_planned`.
However, a user would expect that a resize changes the duration, which is
not the case.
To avoid the confusion, it is not allowed to resize the tasks anymore.
opw-676762
Add inputs e-mail address and country
when creating a newdatabase
This will provide the installation of the correct
chart of accounts at the installation of Accounting
Use the provided login as the admin login,
and set the email on the partner
if the login set is an email
Set the country on the company (and its partner)
The countries are parsed from XML country list
We take the opportunity to repair the `label for`
which bind the label with the input only if
the `id` attribute of the input is set with
what is set in the `for` attribute of the label
An issue occurs in the following situation. Several cash journal are
configured for a given PoS, and a user performs a refund (the
transaction contains only a refund). In this case, the wrong journal
might be selected. This is because a payment line of zero is not sent to
the backend, and therefore an arbitrary journal is selected.
opw-676229
The _auto_init method was overriden without keeping the return value of
the super on some models.
This break the new stored computed fields computation at field creation.
Closes#11985
opw-677232
Before this commit, in some cases, clicking on 'save' button, then on
other buttons (like 'validate' in invoices) had the unfortunate effect
of applying twice the changes in some cases.
More specifically the problem appears when:
1. an onchange is triggered (for example, taxes in invoices)
2. the user clicks on 'save', buttons are disabled
3. the 'save' actions is completed, the buttons are enabled, but
the on_button_save still does some work: triggering event, and
reloading the view
4. the user clicks on 'validate'
5. the onchange completes, this triggers some more work
Our only protection against such interactions is right now the fact that
buttons are disabled/enabled. In my opinion, there should be a way
to guarantee that actions are properly serialized (that is actually what
a mutex is for... just saying). But the code of the form view/list view is
too coupled, and such changes are quite dangerous. A real refactoring
of those is needed at some point in the future.
Before this revision, the installation instructions where
Community-centric, which led some customers to believe
that they had to install first Community then Enterprise.
This commit makes the instruction compatible for both editions.
dut-odoo