Steps to reproduce:
-install website, website_partner, contacts and studio
-go to contacts and open any partner
-click the studio icon (top-right corner of the screen)
-add the 'website_description' field to the partner
Previous behavior:
the description field is not translatable and attempting to
change the "translatable" option in technical > fields spawns
an error
Current behavior:
the description field is translatable
opw-2155115
closesodoo/odoo#42043
X-original-commit: 186b599246321465eae937b875b6c970656b145a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to produce:
1. Go to 'Contacts'
2. Select a contact
3. Click on "More" stat button
To fix this, we need to force the padding to avoid touch_device rules.
closesodoo/odoo#42033
X-original-commit: 2761fec0e152c08dcd2d63bf5dbce94fee2b6a7b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The recent refactoring made at 30cf7bc798 introduces a new object for the different writeoff lines that could be created from a reconciliation model. Unfortunately, Billing users were forgotten during that refactoring which made them unable to read/use the reconciliation models anymore.
This patch grants them the Read and Create permission on the new account.reconcile.model.line object, as they already have to the reconciliation model.
closesodoo/odoo#42009
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In this commit we perform some small code move in order to better understand
the huge crm_lead.py file. Notably
* add some code sections headers (actions, PLS, opp/leads merge);
* move crm.lead.tag and crm.lost.reason in their own file;
* reorganize fields by main category because it is a mess;
* remove some unnecessary help messages on fields;
* merge two _auto_init methods definitions;
No functional change occur with this commit as it contains only some code
move.
It prepares some further technical cleaning in CRM application, notably
onchange -> compute move.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
CRM still holds code dead since more than 2 years about sales / crm dashboard.
Custom ugly un-onboarding not-wow headers have been removed at ea66192276.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
SPECIFICATIONS
Fixes following issue: when a lead is marked as lost, the probability is
correctly set to 0 but not the automatic one. If one clicks on the "Set to
automatic", the probability is updated, which un-archives it without really
restoring it, meaning we get in a very strange state outside the expected flow
(no Won/Lost buttons, ...).
With this commit the automated probability is set to 0 when setting as lost.
Moreover restoring a lead recomputes its probabilities.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
Issue
- Install website
- Add another language
- Edit > Click on a menu item > Edit menu
- Add mega menu & save
- Change language
- Click on the translate button
- Try to translate a mega menu's item
You can't, it always closes.
Cause
This is the default bootstrap behavior.
Solution
Override the default bootstrap behavior.
OPW-2151710
closesodoo/odoo#42012
X-original-commit: d19489350f23ed245db5a2efa9e08ba878ba77f5
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
When expending a many2x record, a field named 'name' was used to
represent the exported record.
If there was no field 'name' on the record, expanding the many2x field
raised a KeyError in the export screen with "import-compatible export"
enabled.
Use the _rec_name instead as fallback
closesodoo/odoo#42004
X-original-commit: 914d4f8ce9dbfd8380caa429a0aeac0513cf5ff9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit introcudes two changes to the multi edition in list views:
1. Editing one record does not require confirmation through a dialog
2. Successfully saving multiple records unselects all currently checked records
Task 2146429closesodoo/odoo#41099
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit 91560fae56f1cba0914, we are using sudo to write
calendar_last_notif_ack, but we need to update the real partner stored
in the context.
opw-2133566
closesodoo/odoo#41982
X-original-commit: 4d6416dbc82f07c91111457b503ccfc737f802c9
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Purpose of this commit is to better support custom styling used notably
for mass mailing and outgoing emails. Indeed styling is whitelisted when
storing html. Finding it in html requires some parsing. This commit improves
the regex used to find it when semicolons are involved. It allows more use
cases to be correctly supported.
Task ID #2125856
PR #40433closesodoo/odoo#41969
X-original-commit: 5235a49a5cd0f79f5590c96afa26dce25465fe06
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There is actually nothing preventing changing the company of some records even
there is some journal entries/items that are using them.
closesodoo/odoo#41945
X-original-commit: b3b66304eb98819cd87d6e4c7a29ca4803ffc3ff
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this fix, when a refresh of the google token was triggered
and error 400 where returned, if the user did not have write rights
on res_users, an access rights was raised
Now, the write is done and the real error is raised for the client.
Part of OPW-2123045 (needed to further investigations)
closesodoo/odoo#41777
X-original-commit: b4f794c55bdfbf2a5482b7ee30780fdef8d4978f
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Be in multi-company with companies C1, C2.
Let user U1 in company C1 create a vendor bill V.
Then U1 change to company C2.
Another user U2, in company C1, tries to print the vendor bill.
Traceback: Access error trying to access U1 to render the template
opw 2145738
closesodoo/odoo#41977
X-original-commit: 5b7b12c9907d7da03e08df4f5bac2198c3dc9cba
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Prior to this commit, there was no clean way to have a button
triggering asynchronous work (like asking user for confirmaton
for example) and close or not close the modal according to the
user choice. Your options were:
1. Swallow the pill and just accept that the modal will close
even if the user chose not to undertake the action.
2. Set the `close` parameter of the button to false and handle
the conditional closing by yourself from outside the dialog.
This commit introduces a way to tell the form view dialog that
the action has not been processed correctly and that the modal
should not be closed by returning a rejected promise. Prior
behavior can still be obtained (close no matter the result)
by having the handler not returning a promise at all.
closesodoo/odoo#33837
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
qsm-odoo