When running action_assign on a mts move bypassing the reservation,
we always created a new stock move line with the quantity of the move.
This proved to be too naive when running recheck availability.
Exemple: Let’s say I have a reserved move of quantity 5.
If I edit the initial demand to 7 and click on recheck availability,
I end up with a move line of 5 and a move line of 7. We adadapt the
code in a similar way that what’s done in _update_reserved_quantity,
by looking for a candidate move line and only increasing the reserved
quantity by what still needs to be reserved.
With the new views, we lost a (almost unused and undocumented) feature:
the ability to instantiate custom widgets in a form view, not linked to
a particular field. For example:
<widget type="weekly_timesheet" attrs="{'readonly': [['state', 'not in', ['new', 'draft']]]}"/>
We reintroduce this feature in this commit, with a nice twist: it also
works for the list view and the kanban view.
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
opw-749752
opw-751294
opw-751348
-Make a return picking from a SO, and condigure the items to be refunded on SO(in the wizard)
-Copy the return picking.
-Validate it.
Without this fix, it would just keep decreasing the delivered value on SO.
opw:767429
Add a `peek` option in the bus event dispatcher polling in order to let
an external event dispatcher fetch the notifications and their
corresponding channels.
Impacted modules: hr_timesheet, sale_timesheet, sale
and project_timesheet_holidays
The main change is the product configuration: a service
can create a task or a project, even if the update of
delivered quantities is manual.
Some code cleaning were done to ease comprehension and
maintenability.
This merge also bring usability changes and fine tuning
to manage your service like a pro.
For details, please have a look at sub commits.
Thanks for Thibault for the review and Benjamin (and Indian
Testing Team) for testing this. And Martin Trigaux that
did nothing, since he was on a stupid mountain ...
When a so line base on ordered quantities is invoiced, the timesheet
logged after the invoice validation are not marked as invoiced. This
shows wrong number on the Project overview.
Only project user can see stat button for project and
task on SO form view, and only timesheet user can
see the detailled timesheet stat button.
This avoid to give malny access rights to user that
does not required them for their daily business.
A leave type now generate timesheet by default. So
the internal project/task are taken from the leave
type company (a default value for the company has
been added).
To allow the hr leave manager to select a project,
he should be alble to read the analytic account
(otherwise, crash when calling name_get).
Setting the default internal project/task is advanced,
so hidden in debug mode on timesheet config.
Timesheet logged on project created from a SO line are
not exactly the same as the non billable ones.
To ease the reporting, we split the non billable type
of timesheet: when timesheeting directly on a project
(whatever the product config), the billable type will
be 'no task found'.
The Overview is adapt to display the 2 'non billable'
categories.
The stat button now shows all the project involved
in the sale order (created, or linked).
This commits introduce the field `project_ids`,
containing all the project involved in the sales
order (created, or linked via products).
The stat button now shows all involded projects (if
many) or the timesheet overview of the single project.
The project name should take the customer ref into
account, when creating project.
The task name should be the first line of the SO description
to avoid having multiple tasks generated with the same name.
When clicking on kanban box, the first action is trigger; the user
have to click on the label of the box to see the 'timesheet' (for
instance), otherwise he will see the tasks.
Since HTML5 supports `div`, `table`, ... being wrapped by `a` tag,
we can use it to make the entire kanban box clickable. (See
https://www.w3.org/TR/html5/text-level-semantics.html#the-a-element)
When assigning task to a SO line (through procurement),
related timesheet should become billable (according to the
product of so line), and have their revenue recomputed.
This commits also add a test.
Tests of sale_timesheet were using many demo data. This
is a practice we want to avoid. A common class setting up
test data (product service, partner, ...) is created to
help writting good test cases.
All tests has been adapted, moved, and some were added
to cover the new flow (new product configuration).
The field `project_time_mode_id` on res.company is
already defined in project module. This came from the
good old days where timesheet was not totally depending
on project.
In sale_timesheet, the field was redefined, and a hack
with xml id was done. It is time to remove this crap.
The purpose is to simplify the product configuration.
Adding detailled options about the service tracking
(create task and/or project) make the setup less
confusing for users.
The invoice policy is replaced by "Invoice based"
(only for services). We don't support "ordered
quantities" with "manual" tracking anymore. The
supported use cases are :
- Ordered quantities (using timesheet)
- Timesheet on task (delivered with timesheet)
- Milestones (delivered manually)
Also, even when selecting 'Milestones', the SO line
can generate a task/project, but timesheeting on
thoses objects will not change the delivered
quantities on the SOL. So, a task can always be created
whatever the service invoice policy of the product.
Every generated task or project are linked to their SO
line. But this SO line is only incremented (on delivered
quantity) if its product 'service_type' is timesheet.
Since this field is an analytic account and not a project, its
name should be more explicit. This commit makes the code more
understandable. Naming things correctly improve developper's
sleep.
As so line already generate task, and project
for the SO sometimes, making it always create the
project seems to be a good idea.
Grouping all the logic is better for maintenability
and readability.
The handling of analytic lines to sell is a little
mess. We can reinvoice analytic lines from timesheet
or expenses, or manual lines.
This commit tries to clean the code, factorize it,
make proper hook (see _sale_postprocess method)
and move specific in its corresponding modules.
Code was properly split, in order to make modules responsible
for only their own features:
- sale module handle the link of SO line to an analytic
line, and increment the delivered qty accordingly.
sale also provide the mecanism of determine magically
the SO lines of an analytic line with an expensable product
to reinvoice it at cost.
- sale_timesheet identifies the so line concerned when
timesheeting on a project directly. Also provide the domain
of analytic line when setting the SO line on AAL.
Cleaning is necessary for futher dev.
Florent de Labarre