When syncing Odoo with Google Calendar, if one Odoo event has an
attendee with an email address that contains some uppercases, it will
lead to undesirable behavior.
To reproduce the error:
(Need contacts)
1. Create an event
- In attendees, adds a new partner PA
- The email must be valid and the local-part must contain at
least one uppercase (e.g. demoUP@example.com)
2. Sync with Google
3. On Google Calendar, update the event (e.g., add a description)
4. Refresh Odoo Calendar
Error: The event is updated, but the attendee has been removed.
The error comes from both Google and Odoo.
Google Calendar is not case sensitive: if a user creates a meeting on
Google Calendar and adds an email address with uppercases, the latter
will be converted with lowercases. (On step 3, on Google Calendar, we
can notice that PA's email address does not contain any uppercase)
On Odoo side, when syncing the event, the module checks the attendees.
To do so, it uses email addresses from Odoo (with uppercases) and Google
(without uppercases):
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/google_calendar/models/calendar.py#L105-L114
`email` comes from Google and `attendees_by_emails` from Odoo.
Therefore, it will consider the email as a new attendee and will run
`find_or_create` to get the associated partner. However, this method
uses the normalized email address to find the partner:
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/mail/models/res_partner.py#L50-L63
Thus, `find_or_create` returns PA and adds the latter to the attendees
and partners (even if PA already exists in partners and attendees).
After that, the module checks if some attendees must be removed:
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/google_calendar/models/calendar.py#L115-L120
Again, `odoo_attendee` comes from Odoo and `email` comes from Google.
Therefore, it will remove PA from attendees and partners.
This explains why:
- PA has disappeared
- No partner has been created for the email address without uppercase
This fix suggests to normalize the Odoo email addresses each they are
compared with the Google ones.
OPW-2464863
closesodoo/odoo#67950
X-original-commit: 01648d37b9d5ad858d3b60dacfb724a18045f007
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
link tracker tries to get title from HTML, but the url may be not an html page
or too big html to process. It's a waste of bandwidth, but may also lead to a
Server Memory Limit error.
As a solution, make HEAD request and don't proceed to GET request if it's not an
html page or it's too big. Also, limit page downloading to 50KB.
STEPS:
- Have a standard database with link_tracker and mass_mailing.
- Create a new mass mail MM
- Add a link to a large file in MM Mail Body
- Click "SEND"
- Go to Settings / Technical / Automation / Scheduled Actions
- Open the "Process Mass Mailing Queue" or "Email Marketing: Process queue"
- Click "RUN MANUALLY"
---
opw-2457640
closesodoo/odoo#67948
X-original-commit: bdec63cf97e6904604e9f1e0bf3b6f453b6add60
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Enable Notas de Venta Documents, prepare prefix and set type so they can
be used.
Also update csv escape characters for COMPROBANTES COMPRA/CONSIGNACION in
order to proper display the csv en editors and githib.
closesodoo/odoo#67934
X-original-commit: fb62b5e3d99880bce97e1bba0a92dfd5757dab91
Signed-off-by: Josse Colpaert <jco@openerp.com>
If some RR is archived and where the a forecasted demand on the
warehouse location, it Replenishement will crash will due to the
SQL constraint. It happens because the archived RR aren't take in
account in `_get_orderpoint_action` and the method will try to
create a orderpoint with same product + location which
lead to trigger the SQL constraint `product_location_check`.
Also avoid filtered in for loop to improve performance and use the
read_group instead.
task-2439019
closesodoo/odoo#67936
X-original-commit: 6737feef848dc47120cf3d2cca84e033e869c985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
The`picking_type_id` of the stock.rule wasn't take in account in
the search of BoM because the `_get_matching_bom` with a empty `self`.
fix it by call on the current rule.
X-original-commit: d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
Before this commit, when ribbon was at the right corner of a product
card, this ribbon hid the buttons in list view.
After this commit, in list view, we place the ribbon on the left to
avoid this bug. There was no better solution to fix this in stable.
task-2466120
closesodoo/odoo#67898
X-original-commit: dcddf2125652b03bf4bff385c074fef0b2096f1d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reduce eye catchiness of warning message when warning the user that
his changes on email and phone will also update customer.
Before, used a ribbon (ribbon_message). It is removed from crm lead model
and also of crm lead form view.
Now, only displays an orange alert sign at the end of the fields when a change
would update the customer profile. Hovering on the alert sign displays
the appropriate message. The warning icon is added on crm lead view for
both lead and opportunity types.
Python compute method of ribbon field is split in two compute methods,
one per boolean field partner_email/phone_update.
Also updates ribbon_message tests accordingly.
TaskId 2456105
COM PR odoo/odoo#66909
UPG PR odoo/upgrade#2258
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit renames the field is_website into is_auto_campaign
for clarity purpose.
The is_website field always meant that the campaigns were created automatically
in some instances. Could be created automatically via a link to the website
or even by simply creating a marketing campaign in marketing_automation.
is_auto_campaign is a better name as it does not wrongly imply that only
the website can generate campaigns automatically, while also pointing
out the automatic generation mechanism.
The utm campaigns behaviour rests unchanged.
LINKS:
TaskID: 2414694
PR: #65824
Enterprise PR: #16238
Related: odoo/upgrade#2146
Related: odoo/enterprise#16238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal of this commit is to add m2m between product and blog posts
to display a list of product promoted by one blog.
And in the future the list of blog that speak about a product on
ecommerce.
task-2267830
Co-authored by jke@openerp.comclosesodoo/odoo#67920
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, clicking on the "add a line" button on a
many2many list field directly opened the dialog without
switching the form into edit mode.
This is incorrect, the form needs to switch into edit mode otherwise
the selected records are saved and cannot be discarded.
closesodoo/odoo#67919
X-original-commit: 3608e724c6099f0eff5f14cbd844e0d7507d0d1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the quick edit behaviour has added, embedded lists
can be edited and display the "add a line" buttons in a
readonly form but not display the remove buttons
This commit fixes that inconsistency.
X-original-commit: 7cc17a345bc9cbe165d061300d91d1ac0e583fc1
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, the first step of the tour pos_basic_order
waited for something not precise enough, and that was true
before anything was loaded
After this commit, we wait both the the webClient and the Chrome to be loaded
with a more specific selector
Runbot issue fingerprint: bd10372b7db10c743f38312470ff528a74bfe9dcc0348a3e1f0bd47f55764378
Runbot issue id: 1357
closesodoo/odoo#67904
X-original-commit: 166e30b132fb659aa5a35a03cc73e5225575af2b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Translation overwriting was not working when forced by command line
arg --i18n-overwrite
This is due to the change of signature of the method, no longer
relying on the context
Fixesodoo/odoo#67419closesodoo/odoo#67873
X-original-commit: 44624f5d51a266c4fc37644d3fc36b810e722ee4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The crash manager doesn't recognize ImbalanceJournalEntryError as
a user error and when creating a journal entry that is not balanced,
a traceback is shown instead of the normal UserError dialog.
In this commit, we fix this issue by getting rid of the new error
and put back the use of UserError when checking the balance of an
account move. We also make sure that the feature in pos where we
show a wizard to unblock the user from closing session with
imbalance amount is intact.
closesodoo/odoo#67743
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The popup to apply the discount of the first SO line to the other lines didn't appear
when the first line was a section or a note.
closesodoo/odoo#67907
X-original-commit: 995ba0c2033455a2092439e9728b3f731381c742
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The 'addMockEnvironment' test utils allows to patch a lot of stuff,
including the session, for the sake of a test. However, it assumes
that it is only called once inside a test (or at least, that its
cleanUp function is always called before it is called again).
In this hr_attendance test, it isn't the case. 2 client actions are
instantiated, and addMockEnvironment is called for each of them,
in particular to patch the session.
The first call stores the current session (the real one), to restore
it in its cleanup (1). The second call stores the current session
(the mocked one, produced by the first call), to restore it in its
cleanup (2). The cleanup functions are called in order, so (1)
before (2), meaning that at the end, we end up with the session
being the mocked one of the first call to addMockEnvironment.
The very short term solution is to ensure, in this test, that the
cleanup functions are called in the correct order. For the long
term, we are working on a robust mechanism to correctly clean up
everything after a test.
Issue spotted in the assets revamp task, which mixed a bit the
order of the tests.
closesodoo/odoo#67891
X-original-commit: bb43c74dd10c76b8a80d5749106b86432b13909e
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Without this commit, all tests executed after that one would use
the patched version of the FormViewDialog.
Issue spotted in the assets revamp branch, by moving form_tests.js
after calendar_tests.js
closesodoo/odoo#67887
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The tour system is based on many assumptions, some of those not being
true all the time. In practice, it works most of the time, but when
some slight changes occurs, we may observe undeterministic behavior.
This was actually the case in a dev branch working on assets: the order
of some files was changed, and it caused crashes in various tours.
This helped us identify two issues in the Tip class:
- the Tip class may be destroyed before it is completely started (so,
the destroy method should not assume that the code in start was called
- the attach_to method should not resolve if the tip was destroyed
meanwhile. This is critical, because some code uses that promise to act
on the widget.
This commit fixes both of these issues.
closesodoo/odoo#67896
X-original-commit: b88b634a0363a55411290e54e37806cfec1b2de5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The code added in [1] to update style for multi image selection
is not compatible with .fa icons and causes a strange behaviour when
trying to select one.
The goal of this commit is to fix style for selected icons on media
dialog.
Also fixes the fact the icons were not centered before.
[1]: https://github.com/odoo/odoo/commit/bb65b742e7eec000248b7df0f048dda61ac3ff5aclosesodoo/odoo#67846
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Currently, In channels listing, the order of the channels is case sensitive.
The Uppercase names are listing first and then all the Lowercase ones.
but it should be displayed in the alphabetical case insensitive order.
With this commit, we have resolved this issue and now channels are listing
in case insensitive alphabetical manner.
Task : 2453592
closesodoo/odoo#67889
X-original-commit: 4445207161c84d2854055df63013c1361e5d4697
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
When deleting/archiving any user, the user’s related chat changed name due to
losing one of its members.
After this commit:
Chat name should remain the same after archiving/deleting the user.
Reasoning:
The unsubscribe was meant to target channels of type channel specifically.
`test_channel_auto_unsubscribe_archived_or_deleted_users` has been reintroduced
after having been removed by mistake in eda542c82f84d7b5589846691b9cb6b7f1021947
task-2442235
closesodoo/odoo#67884
X-original-commit: cb4bd4cbc4a36276cc6c9cb68e51c260e7c0d761
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since e86f892a7b
We have the possibility to display a "lost" and a "won" ribbon on the crm.lead
kanban view.
In this commit, we change things around a bit:
- The "WON" ribbon was removed.
Since it was redundant with the stage anyway and not very useful.
- The "LOST" ribbon is now always displayed in the kanban view.
And not only when coming from "duplicate leads".
In addition, leads displayed when coming from the stat button on the
res.partner form view now also shows lost leads (active_test=False).
This can be helpful for the end user because he wants to know "all the deals
that are in progress/lost/won with this specific contact".
Task-2349526
closesodoo/odoo#67693
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Until now, if you have 2 tags (t1, t2) on blog post (P) of blog (B),
we ask to index:
/blog/B/post/P
/blog/B/post/P/t1
/blog/B/post/P/t2
Now, we only ask to index:
/blog/B/post/P
opw-2413811
closesodoo/odoo#67845
X-original-commit: bd8268a36cbe098935555edee8c16b7667c912fc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Issue:
If we get a 'false' for the real_owner_id from the extendedProperties, we will get an error
ValueError: invalid literal for int() with base 10: 'false'
Fix:
We make sure to set a user for the real_owner_id var if it return a 'false' before
closesodoo/odoo#67840
X-original-commit: 735614a127499843bc7bd701794870234e743a88
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, when the user creates a SO with a service product
which does not generate a task or a project, the analytic account is not
set on the new SO. Then even if the user creates a task and add timesheets
for this product in this SO, the compute_timesheet_ids gives 0
timesheets in the sale.order model because the SO is not linked to an
analytic account.
This commit removes this condition and directly searches the timesheets
linked to the SO and thus provides the correct number of timesheets for it.
This bug is appeared from this commit: dc9ef81ab2
Steps to reproduce:
1. Create a SO and add a SOL with 'Service on Timesheet'
2. Confirm the SO
3. Create a task in project for the same customer than the SO or a
project with no customer set.
4. Add the customer of the SO in the task if it is not already the case.
5. Add the SOL in the task and add a timesheet.
6. Go to /my/orders
7. Select the SO that you have created and in this view, normally, you
should have the View Timesheets buttons on the left side.
Current behaviour:
The 'View Timesheets' button does not appear in the view because the
compute_timesheet_ids from the SO return no timesheets for it.
Expected behaviour:
The button should be visible in the view because we have a timesheet for
this SO.
closesodoo/odoo#67770
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit removes 2 css rules that were applied on ALL odoo reports by
mistake.
Indeed, adding rules on "*" and "body" will most likely break other reporting
layouts and is very dangerous / unintended.
If these rules are needed for the survey reports, then it should be fixed to
make them only applied to those reports instead.
We also took this opportunity to get rid of some scss variables.
These variables names were too "global" and could also conflict with other
reporting css rulesets.
If we want to use variables for that report, they should be correctly pre-fixed
to avoid collisions.
Source: 212b107fa1
A proper fix will follow to make the survey reports work properly
(see task-2483393).
Task-2341847
closesodoo/odoo#67836
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee introduced a change that
allowed field_triggers to be computed lazily per registry, this change
introduced a behavioral change that is not easy to notice, in order to
explain the behavioral change I will use the following example which was
the original bug reported:
- Install studio
- Create an app (create a new custom model M)
- Uninstall studio
-> Uninstall fails because field display_name of the custom model M
depends on field M.x_name which has been removed due to the
uninstall process.
To understand why it didn't happen before the aforementioned commit, we
must first understand what happens with said commit applied:
- We trigger the uninstall of studio, this triggers the uninstall of
any modules that depend on it, namely studio_customizations which is
the module in which all customizations done with studio live in.
- We gather all data belonging to the studio_customization and we
start deleting in the following order: ...,
ir.model.fields.selection, ir.model.fields, ..., ir.model
- During the unlink process, we first remove the actual fields from
the model instances before deleting their database reflections, this
is done in the ir.model.fields._drop_column() method, it is this
method that will delete the x_name field but **not** the
display_name field, since it is a base field and not a custom one.
- After the deletion of the fields in memory, we call modified() to
mark fields that might've depended on the fields we just modified so
that they can be recomputed later.
- The call to modified will in turn access field_triggers, but since
we're in a new registry and field_triggers is a lazy property, it
will be computed right at this moment, this means that it will call
resolve_depends on the display_name field which still exists, and
this field has a dependency on the x_name field that we just
deleted! This is what will trigger the crash.
With that context, we can now understand how it didn't crash before
commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee:
- Before the aforementioned commit, the field_triggers attribute was
computed during the registry's setup_models(), in the case of an
uninstall this call to setup_models was done way before the
uninstall step of the registry (Step 3 is the last to call
setup_models before Step 5).
- This means that the old behavior was technically a bug, because
right after removing x_name from the model, the field_triggers still
contained a dependency from display_name to x_name, the former being
no-longer present in memory.
With this commit, we simply reset the _rec_name and the dependencies of
the display_name if the x_name field is being removed, this ensures that
the computation of field_triggers won't crash and burn.
opw-2452498
opw-2478589
closesodoo/odoo#67823
X-original-commit: e6d22a43ff9f40e5fc7b8c84cd4dfe43f926d872
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Oversight of 20b34ae867
This commit fixes the display condition of the small alert block on top of the
mass.mailing form view.
The condition was not working because it would hide the alert if:
('failed', '=', 0)
OR
('state', '!=', 'in_queue')
AND
('sent', '=', 0)
AND
('scheduled', '=', 0)
Instead, we want to hide it if:
('failed', '=', 0)
AND
('state', '!=', 'in_queue')
AND
('sent', '=', 0)
AND
('scheduled', '=', 0)
This would for example prevent showing that the mailing is "scheduled" or that
it has successfully been sent with various mailing statistics.
Task-2457227
closesodoo/odoo#67752
X-original-commit: 98786b70d92d8a3bdfb961945f475b64899cc2e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before it was only done on MyCompany, but interferes easily
with other demo data. Better for the Italian localization
to try the demo immediately in IT Company.
We also added an Italian demo partner, so it is clear
which one can work immediately.
closesodoo/odoo#67615
X-original-commit: 91ff96a79121c1b7018f8a1f7fa9850170852c41
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
The problem is that the cache still thinks in the test that
it is in EUR and then it does a currency conversion for calculating the
delivery cost and the test will fail in L105 of test_delivery_stock.py
By invalidating the cache after the sql that change the currency of the
company, we solve it.
(someone should refactor those tests though)
closesodoo/odoo#67790
X-original-commit: f0a1e7c35bd8cd17149d1d54bfe5b9eec12a0814
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Documento di Trasporto (DDT)
Whenever goods are transferred between A and B, the DDT serves
as a legitimation e.g. when the police would stop you.
When you want to print an outgoing picking in an Italian company,
it will print you the DDT instead. It is like the delivery
slip, but it also contains the value of the product,
the transportation reason, the carrier, ... which make it a DDT.
We also use a separate sequence for the DDT as the number should not
have any gaps and should only be applied at the moment the goods are sent.
When invoices are related to their sale order and the sale order with the
delivery, the system will automatically calculate the linked DDTs for every
invoice line to export in the FatturaPA XML.
Task 1914640
X-original-commit: bde2be069910596df9433df684309fe9f21a494a
We need this refactor for the ddt module to be able to pass
the necessary information easily for the link between the invoice
lines and the ddts.
X-original-commit: a4fb5c93f094dc1cd4de75664b7e232bc505e05c
Fine tuning of f816c326f348ff78a982f91a736cc005d3e0cd31
We should not look at the `seq` when grouping again.
opw-2472061
closesodoo/odoo#67788
X-original-commit: fd36a69a6ed1484d6b7570dae3ff63d3f12ad035
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
- Activate "Analytic Tags" and "Analytic Accounting" Settings
- Create an Analytic Tags and select "Analytic Distribution"
- Create Product -> Product type: Storable product, Update Quantity as
100, Sales Price like 100
- Product category -> Costing Method: Average Cost (AVCO)
Inventory Valuation: Automated
- Create Analytic Defaults Rules -> select created Analytic Tags
& Product.
- Create a SO -> Confirm it -> Delivery -> Validate it
then system give validation message message:
"The operation cannot be completed: another model requires the record
being deleted. If possible, archive it instead.
Model: Analytic Line (account.analytic.line),
Constraint: account_analytic_line_group_id_fkey”
But can be validated from the Inventory app.
Technical information:
It is due to the `default_group_id` in context put in
`action_view_delivery` method, it context key allows to create delivery
(tree view of `stock.picking`) with the correct `group_id`
("Procurement Group").
But the this name field is also used in the
`account.analytic.line` model. Moreover, the
the `_prepare_analytic_distribution_line` doesn't return any value for
`group_id` which means, that at the creation of the
`account.analytic.line` the `group_id` (id of `procurement.group`)
which will wrongly used.
Solution:
Because the `group_id` field on `account.analytic.line` is a related
store of `account_id.group_id`. We can set it directly in the
`_prepare_analytic_distribution_line` with the correct value.
opw-2442493
closesodoo/odoo#67780
X-original-commit: c9f55c5ecf174414f8e9ed6df56170ac2c6d6e3e
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, in the kanban view of sale order lines, the
product's image was not visible.
This commit adds the image to be more consistent with the kanban view in
accounting.
Note: we have also tweaked the view in accounting for better clarity.
Task ID : 2200168 (6.b)
closesodoo/odoo#67691
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Issue:
On DB with a lot of product (e.g. 50K) the MO form is very slow
open/modify. It is due to the `_compute_allowed_product_ids` which
will set the `allowed_product_ids` fields with all product ids possible
(32K), then the `convert_to_record` will take a bunch of time to filter
out no-active product.
Fix:
In your case, to avoid to send bunch of ids to the web framework and
bypass the costly `convert_to_record`, we decided to simply (static) the
domain of `product_id` (`mrp.production`). The flow will be slightly
different (doesn't filter depending of `bom_id`) but still good and
maybe better (we can now modify the product without removing the
BoM/product in the MO form).
Remove `allowed_product_ids`.
opw-2475151
closesodoo/odoo#67753
X-original-commit: a1a4f4548b395127cf7f816379a63f2d47688893
Related: odoo/upgrade#2272
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this fix, the checkboxes were under the label on mobile.
The easiest fix is to not specify the col number as the field is
displayed with a width of 50%.
We now have two columns with 50% each that let more space for
long labels.
Steps to reproduce:
- Go to Events
- Configuration / Event Templates
- Go to the form view
- See "Display a dedicated menu on Website" options
closesodoo/odoo#67761
Task-id: 1929043
Related: odoo/enterprise#17022
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
The left css property computation wasn't usefull for ltr mode and
even worse, it introduced a bug when a horizontal bar was present
(as often on mobile).
The entire width of the table was used to compute the offset even
though we only saw part of it (scroll bar). It's why this left css
property was too high.
We can simply remove this logic as "right: 0" on .o_optional_columns
already do the job for the ltr mode.
Note that we still need to compute the left property for the rtl mode
to put the dropdown menu above the table. Otherwise it will be on his left!
Steps to reproduce:
- Go to Subscription
- Open an existing record
- Try to open subscription lines column dropdown
=> You need to scroll on the right to see it.
Related PR: https://github.com/odoo/odoo/pull/62472
Related Task ID: 1929043
closesodoo/odoo#67755
X-original-commit: 87c6f6338d267acaab90705f9d5ca8ad27ae30fd
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
These are throttled/debounced so the handlers are sometimes called after the
component has been destroyed.
opw-2451752
closesodoo/odoo#67754
X-original-commit: 852781cf64ad6bb10c552e106e93e2bb6035e34b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
when sale order is created from website sale then onchange is not called so value is empty
So here we use computed readonly False, store True for l10n_in_gst_treatment and l10n_in_journal_id in sale.order
X-original-commit: e44b9f44c81f418e0afea4aa24ed5bb41a2d210b
*: website
When declaring a SnippetOption, it is now possible to specify if the
display of the handles overlay should be visible on the snippet element.
By default, it is set to false, and if the selected snippet element does
not have any option that require the handles to be displayed, we will
display them on the first parent element that needs the handles to be
displayed.
In the context of an image, the handles will be displayed on the parent
column, as the image does not have an option that require the handles.
Part of https://github.com/odoo/odoo/pull/66550
task-2431684
closesodoo/odoo#66550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From the editor, when clicking on an image there is a new refresh icon
next to the delete icon that will open the media dialog to allow for its
replacement.
Part of https://github.com/odoo/odoo/pull/66550
task-2431684
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closesodoo/odoo#67739
X-original-commit: a3732031d38d7c7e93565cdd3cd4fdf838ae54ec
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Current behavior before PR:
When having a small screen, the composer in a chat window has no actual
shortcut to send the message.
Desired behavior after PR is merged:
'CTRL-Enter' keyboard shortcut will work for small screen size.
LINKS:
PR https://github.com//pull/65241
Task-2446076
closesodoo/odoo#67724
X-original-commit: 2542f731c5b06c3b451ecde7992d3bb45adb2c60
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
With this commit, 2 changes are made to the way that the
fields.Selection.ondelete cleanup action works:
1) We manually delete ir.model.fields.selection **before** the deletion
of ir.model.fields purposefully to **avoid** SQL CASCADE deletes, as we
do not know which selections are deleted in cascade and thus we cannot
perform the corresponding ondelete cleanup action (which is implemented
within the ORM).
2) In some actions, namely 'set default' and 'set null', we write a
"safe" value to the records containing the Selection being deleted,
before this commit this would go through the ORM (records.write()) but
this is problematic if there's a write override for the record's model
that raises an error for the field being written to. With this commit,
we first try to go through the ORM but if there's a failure (because of
the raise in a write override) then we will bypass the ORM and set it
with SQL.
opw-2451126
closesodoo/odoo#67616
X-original-commit: f5c7e861ee3ca0cdeb6c2f06d227ada07f923ed0
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Adrien Widart