Use case fixed: create a draft supplier payment, tick it in list view and launch the action 'print check'. Then, on the pop up window cancel the operation => the state was badly set to 'sent'.
Using the same journal for both the session closing and the invoices generated
from the PoS may be problematic as they share the same sequence.
In such case, gaps may appears in the invoice numbers (as the sequence is on the
account.move, closing a session increases the sequence by one).
cf opw-685660
Fixes 13242
The commit e59a7fe3ff has moved
the ACE editor from website to web_editor. As some code on ir_ui_view
was used for this widget, the code has also been moved to web_editor.
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
qdp-odoo