The normal flow to render a template is now to use `render_public_asset`
which bypasses the read access rights if the user matches the groups
the view declares.
For public users, we still cannot use that as they do not have access
to calling model methods at all. The route `public_render_template` is
thus still needed, but it should use the `render_public_asset` util.
Related to task-2412544
closesodoo/odoo#64167
X-original-commit: 3fd40ba2030fef7dccf4046a932e3b3a172dc53f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of the task, is to prevent users from inadvertently
creation/opening countries from country_id fields.
Countries should be managed from their dedicated menu item.
so in this commit, we have set both no_open and no_create to True
so user should not update and create a country from the many2X fields.
closesodoo/odoo#63773
Taskid: 2241677
Related: odoo/enterprise#15464
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously, when saving a custom snippet, the outerHTML of the snippet
was naively read directly and saved as a new custom snippet.
Unfortunately this completely bypasses all cleanup mechanisms that we
have before saving, such as stopping the public widgets, or creating
attachments for cropped or optimized images. This would result in weird
bugs, where public widgets would appear twice when dropping a custom
snippet containing one, as well as the creating a new attachment for any
image that was optimized or cropped before saving the custom snippet
every time it was dropped in the page again.
Unfortunately there is no good mechanism for an option to ask the editor
to clean the DOM without actually saving it, as a temporary measure, the
snippet-save option will instead save the whole page (which will clean
up the DOM) and save the custom snippet after the save, before
refreshing the page and reopening the editor, not unlike some theme
options.
task-2341612
closesodoo/odoo#64166
X-original-commit: 38569777935a7939182f49ca978d98f4079e8f2f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Ecommerce" app
- Go to 'Shop' page and edit it
- Add a "Dynamic Products" block
- Click on it to edit it :
- Select any template
- Select `Desks` as product category
- Save
- Go to "Website -> Configuration -> eCommerce Categories"
- Delete the "Desks" category
- Go back to Shop page
Error : "Record does not exist or has been deleted".
Cause
The search domain is looking for child categories of dataset.productCategoryId
(who does not exist anymore in the above case).
`child_of` do a browse() to fetch the records, and therefore generate
an error if category not found.
Solution
Check if dataset.productCategoryId exist before updating domain.
opw-2416231
closesodoo/odoo#64157
X-original-commit: 0de069b8ca9fb005ba5b076984f5677de25889ee
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Do not switch to text tools if the cursor is in an empty oe_structure
(to encourage using snippets there and actually avoid breaking tours
which suppose the snippet list is visible).
Part of https://github.com/odoo/odoo/pull/64088
Related to task-2352339
This commit has been merged twice as it was lost during JW revert.
closesodoo/odoo#64104
X-original-commit: 455f4ec1c5d60d1868f181075ce97a24ee6bc62e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
On editor start, "the cursor enters editable text" at a "random" time
thus switching immediately to text tools or not depending on the fact
text tools switching was initialized or not. We now only allow to do so
after some fixed delay after the editor is ready, to prevent any
automatic switching on editor start (which may break tours).
Part of https://github.com/odoo/odoo/pull/64088
task-2352339
This commit has been merged twice as it was lost during JW revert.
X-original-commit: 8e0efcd42b6254343aae8faf402e3d8dc630dd14
*: web_editor, website
In stable versions, [1] was made as a fix to allow access to read
the colorpicker template for mass mailing users when they do not have
the read access right on ir.ui.view records.
This commit, for master, remove the need of using the confusing
read_template method by using render_public_asset instead (thus turning
the read into a render, which is the same for our colorpicker but might
be a change for potential custo). At the same time, this allows to
remove the read_template public method entirely.
Related to task-2412544
[1]: 8af75e00bdcda3d5ff4facd2f5f146e1d6bf79e4
closesodoo/odoo#64100
Related: odoo/enterprise#15580
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Create a new sales journal;
- Start creating a new invoice using the new journal (the name/sequence
will be editable) and before saving, change the journal to the
old one;
Before this commit, the invoice will be on the old journal and will have
the new journal name/sequence and after validate the invoice all the new
invoices on the old journal will have the new journal name/sequence.
Now, when you change to the old journal the name of the invoice came
back to 'Draft'.
opw-2415975
closesodoo/odoo#64146
X-original-commit: 3b64640076af472b64a72c7061696772d0e118de
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Fix typo preventing a correct management of won/lost when creating
multiple leads in a row.
closesodoo/odoo#64149
X-original-commit: 0024b592b2d589138f34e27c724b8d471d213a4d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since commit [1], it is no longer possible to unselect a row in a
one2many editable list if there is an html field in the form view.
The reason is that there is a '.modal' element (several actually)
in the DOM of the html field. This element is considered as an
opened dialog by the list renderer, which is wrong. This commit
refines the selector that determines whether there is an opened
dialog or not.
[1] 7d04ec7cca4f355295a06c1ce6f112b6cc533c87
closesodoo/odoo#64134
X-original-commit: 6be8997807e4fbfeeefe273a335d9182490d0ac5
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, we replaced occurences of manual creations
(using ".create") with the use of "this.data"
task-id:2336360
closesodoo/odoo#64092
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
the field can be used in reports for any payment method
---
opw-2423290
closesodoo/odoo#64105
X-original-commit: c37afdf3e9f680cd186872e509c6ab8e47b70782
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Fixes 3a6ac95 that ignores computation of recursive stored fields during
creation of records.
The problem happens when we have:
* a recursive stored computed field
* an `api.depends` of this field which is a relation to another record
When this "another record" is created and should recompute the recursive
field, it is ignored.
closesodoo/odoo#64117
X-original-commit: 9fe4fe404b73e9ab18ab6b3b913f075c64bb6954
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet (rco) <rco@openerp.com>
- Remove unused `sequence_tracking`
- Group data by models when it is possible, which implies
to remove `procurement_data.xml` file (data into `stock_sequence_data`).
- Clean messing comments
- Reorder the manifest (when it is possible)
task-2373638
In the model `stock.quant.package`, the `_compute_complete_name`
and the `name_get` mimics the default one (`_rec_name = "name"`).
Then remove clean it.
task-2373638
- make `bom_id` required. No sense to have a operation without BoM
- `company_id` of operation is now related
- Clean the multiple `allowed_operation_ids` into related
fields instead.
task-2373638
In order to have always a picking_type_id on a stock move (and
consistent with his parent model), make it compute store.
Then clean the call of picking_type_id without change the behavior
(/!\ `move.picking_id.picking_type_id != move.picking_type_id` because
of mrp). Fix some test where the location(_dest) was unset in moves.
Also:
- Clean the mess in the create of `stock.picking` about that
and add a onchange to keep location(_dest) consistent with moves.
- The move `description_picking` is set when the `picking_type_id`
change, not only at the create method.
task-2373638
Hi i detected an issue on POS, to reproduce just get into a customer on the POS UI, change something else than the name, then try to save changes, this trigger the if in line 47, making the user to mandatory edit the name field then save again and it works.
The only change on the file is on line 47 where I check if the name is already on the prop so that it works as intended.
Its a mild UX issue with a very easy fix. hope you can upload it soon to the repo so that users on Odoo SaaS or users with no code skills dont have this Issue anymore-
Best regards
closesodoo/odoo#64091
X-original-commit: 94a735ec6a9caa334eca6c4d7a4ca89bf3b5eaf9
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Follow up on d0a4b20d36
The `lang` at this step is compared to the locale `code` (eg. fr_BE) so the
split is a mistake.
To reproduce the issue:
- change the language of a website to fr_BE only
- allow free signup
- register as a new user
Notice how the language of the user is set to en_US before this PR instead of
fr_BE as it should be.
closes#63616closesodoo/odoo#64089
X-original-commit: ba21dadf17ba96ecbba917f666a3b385d9b9fd5e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
before this commit: when you have o2m which has optional fields and optional
field dropdown is bigger and o2m does not have records and when you open
optional dropdown it hidden behind o2m table. The reason is optional dropdown
is child of table.
after this commit: put dropdown as child of listview.$el so it is no more child
of table so when it is opened it is displayed on top of listview table, here we
also have to calculate position of optional dropdown as it is no more child of
table element, so we have to set left position based on table width and if
language direction is rtl then dropdown width.
task-2370860
Closes#62681closesodoo/odoo#64085
X-original-commit: a14c74d926b35dc499914edcbb7b93e638fe3bce
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in editable list views with a many2one, when
the user clicked inside the many2one dropdown, in the padding above
the first item or below the last item, the dropdown closed itself
and the row was removed (if it wasn't dirty yet). This commit fixes
that issue by ignoring clicks at those specific spots.
Task 2377864
closesodoo/odoo#64084
X-original-commit: 2ddb8e07ab9fcce3427266247069de8546a87fb5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
What are the steps to reproduce your issue ?
1. Install contacts in a db with demo data
2. Create a contact with complete address
3. Click on Add button (edit mode)
What is currently happening ?
The address get copied but not completely (no zip code, state, street)
What are you expecting to happen ?
The whole address have to be copied
How to fix the bug ?
Don't call the onchange if the record is not yet created
opw-2415891
closesodoo/odoo#64071
X-original-commit: b731afa7918d9d69132af825c414d902aa57541e
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
RATIONALE
"Incoming Emails" option has many flaws
* it creates collision when you try to set an alias that is already used
and it is not easy to find them back;
* it has no default value (no sales team, no type, ...) and works through the
'owner' field. This is set with the admin on activation of the feature
which is not correct. The admin is potentially not a salesperson. If you
set the field to blank, you get leads without team and without assigned
responsible.
* this alias is not team-bound which thus asks the question: in which team
should the lead ever go? To the first team? Why?
All this make it seem way healthier to handle this through the Sales Team.
=> By default, we'll already have one working with an alias.
If users really want a global lead alias it can be setup manually through
alias menu in configuration. Shortcut and default alias in crm are removed
but feature is still doable if requested.
SPECIFICATIONS
Remove the s "Incoming emails" setting that allows to setup a global alias for
leads / opportunities with a default value being 'contact'. Also remove related
alias data as it has no use anymore.
When changing "use leads" from CRM settings automatically regenerate apply this
option to all sales teams using opportunities. When de-activating it no team
should have this option activated as menus and options are hidden. When
activating it we consider that all teams should be upgraded by default
LINKS
Task ID-2414079
Sort of follow-up of Task ID-2373095
COM PR #63160
UPG PR odoo/upgrade#2017
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When alias domain is not configured always display "Configure a custom
domain" link instead of an email having only a left-part or "Inactive
alias" if left part is void. This is already the case in edit mode but
not in read mode.
New specification is
* domain is not configured: display link in both read and edit mode;
* domain is configured and left part is set: display alias;
* domain is configured and left part is not set: display "Inactive alias"
in read and display alias name for edition in edit;
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
SPECIFICATIONS
We do not want to explicitly set an user as responsible when an incoming email
creates a lead or an opportunity. We prefer that assignment is done either
automatically (scoring) or manually.
Using environment user would lead to set either root (gateway user - already
prevented) either alias owner (through alias_user_id) either user sending
email if email_from matches. Doing it also allows to exclude portal / public
users that would send an email to the mailgateway.
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
SPECIFICATIONS
When changing "use leads" from CRM settings automatically regenerate apply this
option to all sales teams using opportunities. When de-activating it no team
should have this option activated as menus and options are hidden. When
activating it we consider that all teams should be upgraded by default.
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
RATIONALE
"Incoming Emails" option has many flaws
* it creates collision when you try to set an alias that is already used
and it is not easy to find them back;
* it has no default value (no sales team, no type, ...) and works through the
'owner' field. This is set with the admin on activation of the feature
which is not correct. The admin is potentially not a salesperson. If you
set the field to blank, you get leads without team and without assigned
responsible.
* this alias is not team-bound which thus asks the question: in which team
should the lead ever go? To the first team? Why?
All this make it seem way healthier to handle this through the Sales Team.
=> By default, we'll already have one working with an alias.
If users really want a global lead alias it can be setup manually through
alias menu in configuration. Shortcut and default alias in crm are removed
but feature is still doable if requested.
SPECIFICATIONS
Remove the s "Incoming emails" setting that allows to setup a global alias for
leads / opportunities with a default value being 'contact'. Also remove related
alias data as it has no use anymore.
LINKS
Task ID-2414079
Sort of follow-up of Task ID-2373095.
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
When emails related to calendar events are sent email_from is set from
templates like invite template. Author of those email is however not set
and current user is used as default value.
In this commit we do as done in templates and try to set event responsible
as user, and fall back on current user if not set.
This notably solves an issue when using website_calendar. Appointments are
done using public user and mails have public user as author. This leads to
emails not being accessible or having a false email_from.
Task ID-2413792
closesodoo/odoo#64061
X-original-commit: c01d95d371e859002f09520d3a97436f3b3087b8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reason: In Employees app, it is confusing for the first time users to see
both 'Employees' and 'Employee Directory' folder. Also, first user
is not assigned to any departments.
Solution: If the user can see the folder 'Employees', don't show
the folder 'Employee Directory'. Assign the first user to the
'Administration' department.
Task - 2377506
closesodoo/odoo#63038
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Let's assume an editable list with a many2one field. The user types
something in the many2one and then clicks outside (mousedown, not
mouseup, and thus click, yet). A dialog opens to ask the user if he
wants to quickcreate a record.
Before this commit, the dialog and the row disappeared as soon as
he released the click, because the click was considered by the
list renderer as an "external click", and the row was discarded
(alongside the many2one it contained).
Task 2411029
closesodoo/odoo#64053
X-original-commit: 7d04ec7cca4f355295a06c1ce6f112b6cc533c87
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This improvement allows user to review mail attachments that were sent using
composer in mass mail mode while creating a mass mailing on the fly. This is
achieved via `Action > Send email` menu and setting a mailing name.
For example, you sent different mails to different set of partners and you want
to check that you sent correct attachments and didn't miss anything. This
behavior is doable in Email Marketing apps. Before this commit you would need
to open different partners in Contacts app and check messages in the chatter.
Now attachments are displayed in composer.
STEPS:
* Install mass_mailing
* Open Contacts menu
* Select any number of records
* Click `Action > Send email`
* Set **Mass Mailing Name**
* Attach a file
* Send
* Open ``Email Marketing`` app
* Open the created mailing
* Check ``[Settings]`` tab
BEFORE: Attachments field is empty
AFTER: You can see the attachments sent to the partners
WHY: In 2014 attachments were added to mailing.mailing, but not to composer
https://github.com/odoo/odoo/commit/7e1e475d89694d09e62c33d2529fa061c7983dff
---
Task ID-2418997
opw-2410938
closes#63065closes#63470
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Update the standard_price outside the loop to avoid recompute
quantity_svl at each iteration. quantity_svl is not modify in the
process and the standard_price is not read in process.
NewPrice = OldPrice + (cost_to_add_x1) / quantity_svl + (cost_to_add_x2) / quantity_svl
Becomes
NewPrice = OldPrice + (cost_to_add_x1 + cost_to_add_x2) / quantity_svl
which is equals.
opw-2374405
odoo/odoo#64011closesodoo/odoo#64032
Forward-port-of: odoo/odoo#63742
X-original-commit: b8d7e48f27fc4f0868c538977be8276058944e57
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Improve performance of SQL in `_compute_allowed_picking_ids`.
This one can be costly for a simple read of the `allowed_picking_ids`.
Grouping the result to avoid useless big thoughtput and a
add a where clause on company_id to filter out useless row.
opw-2374405
odoo/odoo#64011
Forward-port-of: odoo/odoo#63742
X-original-commit: 209f421b7360a42ab43c09d9aacec6b53ad24917
Previously, if you double-clicked an image in the web editor with the
intention to change it, but the image had already been optimized, and
then repicked the same, already optimized image, the image would be
optimized again even though it had not changed. This commit fixes that
by making the media-dialog not trigger an image_changed event in those
cases, and by leaving the initial image untouched.
Linked to issue #57604closesodoo/odoo#64038
X-original-commit: 4d3655304205cc9785ef696a47a17a41242d297a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
There is no way for _error_checking() to detect conflicts in work
entries that have been introduced in concurrent transactions, because of the transaction
isolation.
So if 2 transactions create work entries in parallel it is possible to create a conflict
that will not be visible by either transaction. There is no way to detect conflicts
between different records in a safe manner unless a SQL constraint is used, e.g. via
an EXCLUSION constraint [1]. This (obscure) type of constraint allows comparing 2 rows
using special operator classes and it also supports partial WHERE clauses. Similarly to
CHECK constraints, it's backed by an index.
1: https://www.postgresql.org/docs/9.6/sql-createtable.html#SQL-CREATETABLE-EXCLUDEclosesodoo/odoo#64028
Taskid: 2357844
Related: odoo/enterprise#15546
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, we check if the bill_type in the project is equal
to 'customer_type' but this field can only be either 'customer_task' or
'customer_project'. Thus, this condition will always be False.
This commit changes the condition to check if the bill_type is equal to
'customer_project'. Then, this condition can be True if the project has
a SOL and his bill_type field is equal to 'customer_project'.
closesodoo/odoo#64012
X-original-commit: d8f7d7369f060f444bcebc0118cc5a2a650f6361
Related: odoo/enterprise#15540
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
No need to force a new title on duplicate if something is already given.
Task ID-2265556
PR odoo/odoo#52391
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if a badge is set on the survey, duplicating it always
results into a traceback due to sql constraint. Indeed due to uniqueness
constraints between survey and badge having the same badge for a duplicated
survey was leading to an error.
We had two options
* duplicate the badge itself;
* remove sql constraint and add a required on badge in view when having
a certification (aka, survey giving a badge);
First solution is somehow limited. It means updating badge name, checking
its goal, ensuring all parameters are ok. Moreover it is quite hidden when
duplicating survey. End users will maybe not see what to are doing.
We choose to remove copy flag on flag and badge. That way end users have to
manually re-check the flag, and create a new badge. We remove the hard
constraint and set a required in the view so that functionally behavior
is the same.
Task ID-2265556
PR odoo/odoo#52391
The button "Group By" and "Measures" were untranslated
opw-2421769
closesodoo/odoo#64015
X-original-commit: b4249c9125bd9b6077425636f67dec0303554da8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Benoit Socias