Ace editor is not very smart, it does a rpc for each inherited view, it
tries to load workers before deciding not to use them, and it does way
too much work in general. This commits tries to make sure that only the
necessary rpcs are done (lazily).
fix some issues with ace editor: lazy loading
fix various issues with ace editor
This comportement was added in the DebugManager to trigger an event.
As this event could be useful in other situations (e.g. studio), we trigger
the event directly in the ActionManager. By default, the WebClient does not
use this event but an handler is added to be overwritten.
This handler is overwritten in some widgets (DebugManager, Studio, etc.) that
requires the Systray items instances so we add them in ´widgets´ in the Systray Menu.
As the module dashboard uses multiple ActionManager, the event bubbling should be
avoided in this case.
A refactoring of the js views is in progress. Those new views are used
in web studio, and this change is part of it. This is necessary to allow
web studio to correctly fetch data from the server when rendering a
preview. Note: this is necessary for special widgets (status bar,
selection, radio widgets)
Sometimes, we need better control on the cache. For example, if a view or an
action has been changed, it is required to make sure that the correct
data is loaded.
Sort systray items by sequence to allow, e.g. to force the planner item to
be the left-most item of the systray as it is not displayed in all apps, and
thus produces a flickering of the other items.
Also invert the push order of the two mail items to keep the previous order
as they are now prepended instead of appended.
* event, website_event, website_forum,
* website_hr_recruitment, website_sale
Website access rights were buggy. The editor assets and website editor
assets have to be loaded together to work so the previous behavior
which only loaded one with the restricted access right was not right.
Also, people which had the "Manager" access right for model like event
or job only got access to creation and edition of those objects if they
had the full access to website access rights.
Now the website module creates the two same groups :
* group_website_publisher: load all editor assets, give access to
page creation for model the user has access (event, job, ...) and
edition of those pages
* group_website_designer: implies the first one and give access in
creation and edition of all pages + access of all website menus
The manager access rights for event, product, jobs, etc now implies
the group_website_publisher group for the user (so that the manager
have the editor assets and editor ui).
Note: some python codes use the group_website_publisher for no right
reason, this has to be adapted.
The previous line was O(n^2). With n=1200 like we just have now,
things didn't look good for this loop and confirming an attendee
registration to such event took approx. 13 seconds.
Since the list comprehension is in no mean linked to the value
of "item" in the filter, I simply moved it out so it is only
computed once.
For historical reasons, `vobject`* Python library is not mandatory in
Odoo.
Since refactoring 6af6148a24,
get_ics_file() returns now a dictionary whose keys are calendar.event
ids and values are the corresponding ics file.
If `vobject` is not available, it returns an empty dictionary that
could cause calendar.py to crash because it always expects to find the
event's key.
Before this refactoring, this method was called and architectured in a
different manner, so no crash was happening.
This commit prevents the crash if `vobject` is not installed and logs a
warning.
*vobject allows to generate iCalendar files
There was no bug but now the behaviors are more consistent :
- Demo data now declare a black invisible filter instead of nothing.
This allows user to see the effect of filter intensity option
(otherwise it had no visible effect since there was no filter color).
- If the filter intensity is set to "None" (invisible filter) and that
a filter color option is highlighted or chosen, a "Low" filter
intensity is automatically highlighted or chosen so that the user see
the filter color he is chosing (instead of having to choose the filter
intensity first).
- Hide the "Size" option on the blog list page since it has not visible
effect there.
- Some code "performance" improvements in option selection.
Upon the creation of an event,
the list of attendees displayed in the invitation emails
were not complete because the emails were sent as the attendees
were being added to the event, in the loop.
e.g.:
- Create an event with Joseph and Michel
- Joseph received the invitation email with only him as attendee
- Michel received the invitaiton email with Joseph and him.
The invitation email of Joseph now contains all the attendees.
opw-681242
In previous versions, the quantity passed to the bom_explode was the number
of times you needed to count the BoM. If the BoM was for 2 dozens and you pass
48 units, 2 was passed to the bom_explode method. We are now doing the same
for the explode method and we check it is called this way everywhere.
When you produce or consume more than foreseen in a production order,
the system creates extra moves. Before, in case of tracking, it did this without
transferring the stock.move.lots resulting in a wrong stock. That is why now,
when we split moves, we also split the stock.move.lots
For the finished move, it is also important to split between the quantities
of the original procurement and what is extra as the extra might use a push rule e.g.
When updating quantity, it should take use a similar
method as for generating the moves, but with
the quantity already produced (and posted) deduced.
The parameters for these method needed to be changed.
When all the moves are posted,
we should create the necessary extra moves.
If the quantity is put back to the quantity posted, it
might also need to delete moves.
In byproduct, it should take into account the subproduct factor.
When the quantity produced on the work orders has reached the quantity to do,
it should not allow anymore to use the "Done" button on work orders, but
rather use the Finish button instead. With the Update button on the manufacturing order
it is possible to do more.
In v7, it could be in handy that when altering the quantities of a move, it would automatically
update the next chained move as you could change quantities on the fly without any relation
to the original documents.
From v8, this is all being handled by extra moves which might e.g. follow
a different route, so you still know what is related to the original procurement.
But the functionality stayed in the code for who would still need it.
In v10 and in previous versions, manufacturing orders however still use these moves.
When we update the quantity on a halfproduct (which we can do now all the time in v10,
it could change the consumption where it is used in the finished product (in MTO)
That is why it is better to remove this functionality.
(it might also speed up the split method on stock_move)
The propagation of quantities was something from v7, that now causes trouble in mrp for nothing
The default of the date_start on the time records was a
result of the function fields.Datetime.now instead of the function itself
resulting in the start of each blocking time as the start of the server
When changing the quantity being produced on a work order and
serial numbers are consumed, we need to delete or add lines
for every serial number in function of the quantity through the onchange.
We changed the quantity_done to be set to quantity by default (automatically)
as otherwise we forgot to set it. But for the onchange, it means
we need to take it into account otherwise the number of records
would not be diminished.
The labels of the fields say that they store hours, but actually they store minutes. Correct the code to store hours.
Add digits to fload field for a better display in the webclient
date_planned_start should also be Start Deadline instead of Expected Start Date.
We don't want the Expected dates to function as a planning tool, but as
a priority for the planning of the workorders.
This reverts commit dc02f773ce.
This commit caused a side-effect that is worse than the issue
it tried to fix, which was purely cosmetic.
Now in mass-mail mode the template is only rendered once
and all recipients receive the same PDF, which completely
defeats the goal of a dynamic report. We have static
attachments for that.
Original fix related to opw-657152
Reverts PR #10568
the onchange changed the partners of the ticket when the ticket changed project
to the project's partner, but if the ticket already has a partner it shouldn't
change.
! Note forward port: this is a partial backport, ignore when conflict
For some strange reason, the cover_full class was added when the cover
image was changed, without checking if the cover_narrow class was
already there. The cover was then a hybrid cover_narrow cover_full.
The problem was reinforced by the graphene theme which does some
animation on cover_full covers.
Martin Geubelle