Timesheet created using the UI are supposed to all have an employee defined.
However, this field is not required and it is possible to have timesheet without
a user defined.
Feedback ged from saas-16 migration
As of saas-16 and the new web client views, the "display value" for a
record's ID is now formatted with thousand separators.
This breaks a few kanban views where the ID was inserted into a
dynamic URL. Using `raw_value` is correct too and fixes the problem.
Note: This might affect other kanban views using integer field values,
but a quick search did not yield anything. Many2One fields already had
different "display values", so `raw_value` is already used when needed.
Other integer fields, such as computed counts and sums are often
displayed but not inserted into URLs or technical values where
the problem would occur.
The inventory adjustment form is not suitable for large inventories.
First, a list view embedded in a form view is not convenient since it
doesn't provide any search capabilities. The user has to rely on the
search feature of the browser, which has restricted features in
comparison to the Odoo search field.
Then, the existing onchange mechanism coupled with computed fields
triggers heavy computations impacting all lines each time a single
line is modified. This leads to a hanging page for every inventory line
modification, which causes a non-negligeable loss of time.
This commit introduces a new tree view for inventory lines, accessible
thanks to a stat button on the inventory page. This button is available
in debug mode, if the inventory is in state 'Confirmed'. The tree view
contains the same fields than the tree view embedded in the form view,
without the flaws of the latter.
opw-760614
Fixes commit https://github.com/odoo/odoo/commit/02c748be59ac8abc44c945218587e7b8a8e06a28:
Blog content field should not have been marked for any sanitization at
all as it is a field whose content is editable only by users through the
website editor. Any content should be authorized there. In particular,
some snippets contain form elements (like <input/> tags) which are
never accepted during sanitization.
opw-752458
To reproduce:
- Buy a product costing 0.01
- Validate the cart, pay with Stripe
- Enter the credit card info, validate
Stripe cannot process the transaction (minimum charge is not met), but
the user is not warned about it. The Stripe pop-up is closed and the
error is recorded in the console silently.
opw-765775
Purpose
=======
Currently an employee can
- Create mail.followers
- Write on mail.follower if it is related to his own partner
When creating a record with followers (example: An expense sheet), the followers are created but the function fields are recomputed and stored on the table (if store=True).
In that particular case (Create: ok, Write: ko), this recomputation will trigger a write and then an access right error with a transaction rollback.
Specification
=============
Adding the `compute_sudo=True` attribute on the `res_model` field, the recomputation will be allowed for users at the record creation.
This fix doesn't imply to update the modules.
Currently, the 'environment group by', if previously empty, is set to a
view-specific default value when filtering in a Kanban view. This then
causes an unexpected 'group by' when switching away from a Kanban view,
since the expected behaviour is to only take a Kanban 'group by' into
account if it was explicitely set by the user.
This is caused by the fact that the 'search' event triggers a view
reload which takes the environment as parameter, while the Kanban view
reload overrides the group by (arrays are passed by reference).
Both result in an undesired modification of the enviroment.
We fix this bug by giving a shallow copy of the environment as parameter
when triggering the view reload.
Since rev. https://github.com/odoo/odoo/commit/ebd17217c4e7e9ff06d97028de64fb2fc44d6266
the attribute `_editionViewType` has been introduced to use the modifiers from the correct
one2many view type.
This attribute wasn't correctly populated if multiple one2manys were imbricated. The
first view type (form in the test case) was set for the second one2many even though
the view type was list. This was due to the `visitChildren` function use that browses
through all levels (and not only the first one).
To reproduce the bug before this rev. you could try to create a new survey, add a
question (one2many) then select multiple choice and add an answer (one2many editable).
If a google application has no client_id or client_secret during the update
process (e.g. was configured but the API keys have been removed and the tokens
have expired), the method will crash.
Instead of continuously try and produce a traceback, return a proper error message
Closes#18613Closes#18614
This merge mainly does 2 things:
- move frontend chatter feature from website_mail
into portal, since chatter is required for some
business model in the customer portal. This chatter
is still also responsible of displaying comments
for website object (slides, blog, ...)
- bring project customer portal into project,
and make project module depends on portal, like
it was already done for sale and account.
hr_timesheet now contains the dislaying of timesheet
on task in portal.
website_project is removed, and we do not use
website.published.mixin on project, since this
is only used to display its rating. projects are
not public object.
'project.project' should not use 'website.published.mixin',
since we don't want to publish a project on the website.
All we want is to display the rating of a project, nothing
more. So, a flag on project is enought to allow the publication.
In grouped Kanban views, the list of res_ids of the displayed
records may change for several reasons:
1) 'Load more' is clicked for a column
2) a record is moved from a column to another
3) a record is moved inside a column (resequence)
4) a column is moved
5) a column is (un)archived
6) a column is (un)folded
7) a record is created/destroyed directly from the Kanban.
When this happens, the environment must be notified of the new
list of res_ids (the order matters). Before this rev., this wasn't
the case. As a consequence, when a record was opened in a Form view
after one of the 5 operations above, the pager could display
unexpected values.
Note that before the new views, cases 2, 3 and 4 weren't handled,
and case 7 already worked before this commit.
The problem occured when opening a record from a grouped list or
kanban view. In the opened form view, the pager was sometimes
incorrect. This was because the list of ids wasn't correctly
updated when groups were opened/folded.
Before 9.0, it was possible to display aggregate values in grouped
Kanban view (like sum, average...). The aggregate was displayed in
the header of the column (see for example in 8.0 in Project >
Tasks).
This feature has been dropped in 9.0 because it didn't work
correctly, but the documentation hasn't been updated accordingly.
/mail/view controller is a generic controller that redirects to a view
on a document either on backend or frontend depending on the module,
user and some model specific conditions.
However currently url computation is not always correct as you may end
up on frontend view even when you are a regular user that should land
on backend views.
In this stable version we introduced a key in the returned action that
indicates the action is a pure front-end (public) action or not. This
way people are correctly redirected to the backend or the frontend
when going through the controller.
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
Up to this revision, clicking on 'edit' in a record with an existing pad
and discarding the changes straight away caused the pad content not to
be displayed.
The root cause of this issue is twofold:
- a hack tricks the model into thinking the pad URL has changed by
replacing it with an object yielding the URL when JSONified;
- the pad never affects the 'dirtiness' of a record and BasicModel only
actually discards changes when the record is dirty.
When a user clicks on discard, the model does not actually discard the
changes, thereby leaving the web client into thinking the pad URL is the
object mentioned above.
We fix this issue by requiring that the model always discard changes
when clicking 'Discard', regardless of whether the record is dirty.
In fact, the lines we changed were no longer correct since the
introduction of 'doNotSetDirty' (see
https://github.com/odoo/odoo/commit/72ed3a1), as a record could be
changed without being dirty. This commit thus also ensures that such
records are also properly discarded.
Before this commit there were two issues:
- The date "from and to" set in the wizard weren't working, as in not used at all
- The lines in the report did not have a date range, making the understanding of the report difficult
after this commit, only the budget lines which dates overlap at least one day of the report's dates will be selected.
Also, the first line of the report, containing the budget name also contains the dates on which it applies
OPW 743441
Closes#18737
Backport of 0280354045
Original message:
The previous trigger would recompute all sessions of a config when modifying
the cash_control flag on the config.
It was not possible to enable cash_control if a previous session wasn't in
cash control mode.
Recompute only when changing the config
OPW 761025
Closes#18814
Before this commit, it was not possible to copy the contents of a
multiline text field in read-only mode in Firefox without losing all
line breaks in the process. This is due to a bug affecting div tags
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1390115) in Firefox.
This commit ensures that the text in a text field is surrounded by a
span (as opposed to div) tag.
Note that spans were used in saas-15, so we are in fact simply undoing
the change to divs introduced by the new views.
1. Set the Decimal Accuracy of "Product Unit of Measure" to 7.
2. Create a UoM: T-LBS which is the reference for weight and has a
precision of 0.01
3. Deactivate KG (which was the previous reference for weight)
4. Create a UoM: T-GT which is BIGGER, with a ratio of 2240.00 and a
precision of 0.0000001 (necessary to avoid rounding errors)
5. Set the Product Unit of Measure Decimal Accuracy to 6 digits.
6. Create a Product T-TEST with T-LBS as the UoM ans Tracking as LOTS
7. Create a PO for 60 T-GT
8. Observe a Receipt created for 134,400.0000000 T-LBS
9. Receive 42760 by using LOT SPLIT button, and creating a LOT to hold
this amount.
10. Click VALIDATE.
11. Click CREATE BACKORDER.
The backorder is created for 91640.01 instead of 91640.00.
When the backorder is created, we should make sure to use the same
rounding method that was used to compute `product_uom_qty`, in this case
'HALF-UP'.
opw-753116
To reproduce:
- Create department 'Art' parent Department 'Management'
- Create job position and set department 'Art' & publish
- Allow 'Filter by department' from the frontend page
- As a public user, open job => Access Forbidden
The record rule should be adapted to allow accessing departments which
have children.
Actually, the rule could probably be removed since the controller
already lists only the necessary departments.
opw-765736
Currently when importing files, the parent left and right are recomputed on each record creation/update, which could lead to a lot a request.
This commit will defer the parent field recomputation to the end on the `load` function by recomputing the values from the MPTT and inserting directly the new values on the records.
Tested on a customer instance, this will reduce the execution time when importing a thousand stock.location from 15 minutes to several seconds.
The %d %h options in db-filter are case sensitive but the URL are not.
If you happen to use databases with uppercase in the name, using (?i) may be
needed to match the correct database.
Fixes#17407
As mentioned in
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49,
a resize after the first render is necessary to prevent overflow issues
with fullCalendar. As changing the date would rerender the calendar, we
also need to trigger a resize then.
From this revision onwards, a resize event is triggered every time the
calendar has finished rendering its events.
Unfortunately, I was not able to write a meaningful and successful test
(I encountered PhantomJS-specific issues). I also removed the test for
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49
because it always passed regardless of whether the fix is applied.
1. Create an attribute with create_variant boolean un-ticked (ie. don't
create variants from these attributes). For example 'Test Attribute'
2. Create attribute values related to the above attribute. For example
'Test 1', 'Test 2', etc
3. Create a product (product.template) and assign an attribute (eg.
Color: black and white)
4. On one of the product variants, add one of the attribute values for
the attribute we've created in step 2 to the attribute_value_ids
field to allow for filtering by product attributes that do not create
variants.
5. Go back to product template and add another attribute value to an
attribute where create_variant is True (eg. Memory: 16 GB)
6. Our value from attribute_value_ids is gone, and the product has been
deactivated
When attributes are set with create_variant is False, they are
obviously not used to create variants. Therefore, when we are looking
for existing variants, we should filter out these attributes.
Partially closes#18682
opw-762743
when access status hw_proxy in debug mode it's will raise error,
it's happens because hw_proxy uses subprocess module to get a list of usb
but the subprocess module not imported.
Introduced at 56456359Closes#18820
Martin Trigaux