Before this commit it was rather painful/cluncky to find a way to remove this block.
By setting a name on the block we can easily xpath it to replace it or add extra content within.
This makes it easier for external devs to influence this view.
closesodoo/odoo#68010
X-original-commit: d418e4e16a46a0d499e606598b3524eabd19e5fd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The current behavior was to set the label as memo in the payment register wizard.
However, this is to restrictive when a vendor bill hasn't any payment reference but a bill reference.
In that case, the user is expecting to have the bill 'ref' in the payment 'memo'.
Since the matching rules in the reconciliation widget are matching line.name, then line.move_id.ref and then line.move_id.name, the same logic is applied here to construct the payment 'memo'.
closesodoo/odoo#68004
Opw: 2440389
X-original-commit: 92ceb86d58f4d78c8a4256f29d101d3730517b93
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The Lunch module can automatically send an email to a supplier with the
daily orders at a configured time. It can also remind the users via chat
so they don't forget to order their sanddwish.
Before, two high frequency cron jobs were responsible to check every 20
and 5 minutes if we reached the moment when to send the email to the
suppliers or the notification to the users. Together the two crons were
executed 360 times a day.
The new model uses a dedicated daily cron per supplier record and per
alert record, the dedicated cron is created on the fly and its moment of
execution automatically updated to reflect the supplier/alert record.
See also #41858 for prior work.
closesodoo/odoo#63749
Task: 2416741
Related: odoo/upgrade#2044
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
It shouldn't be possible to create refunds on misc journals, as the tax report would compute the wrong multiplicator sign, and hence end up being entirely wrong.
Introducing the constraint also allowed finding an issue within _move_autocomplete_invoice_lines_create: some tests directly create an invoice by giving it line_ids instead of using the invoice_line_ids helper. The former implementation of this function made it so that the default type wasn't set in the context properly, and these tests were putting their invoices on misc journals. We fix this here as well.
closesodoo/odoo#67965
X-original-commit: fdc96de0e411760f84a78c36543f9157332346de
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Install 'Blogs' module
- Create a blog post
- Set published_date to 01/01/1997
- Go to website
- Edit any page and add a 'Blog Posts' Block
- Set 'Layout' to 'Cards' (or 'Horizontal')
- Save
In snippet cards, the blog post date is not the published date.
Cause
Displaying update date ('write_date' field) instead of
the published date ('post_date' field).
Solution
Replace 'write_date' by 'post_date'.
opw-2443104
closesodoo/odoo#67985
X-original-commit: 681e709b239c2456c71d1c16bb40de055dfb927c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Client issue: when updating the company of a contact, the Display Name
keeps using the previous company's name, so given Bob in company A, if
Bob is moved to company B the form's title remains "A, Bob" instead of
becoming "B, Bob". More annoying, if Bob is moved back to A the name
becomes "B, Bob".
On res.partner, `display_name` is a stored computed field which
depends on `commercial_company_name` (via `name_get` -> `_get_name` ->
`_get_contact_name`). This is an other stored computed name, which
depends on `commercial_partner_id`, which is yet another stored
computed name, which depends on the `parent_id`.
The dependencies are meh but usually resolve fine, the issue occurs
when a base.automation rule is created with a non-empty
domain (including an empty literal list, which was the case here):
when the first field of the sequence is computed, base.automation's
`_compute_field_value` is called. This calls `_filter_pre`,
which (because `filter_pre_domain` is non-empty) calls `search` on the
model.
This would normally be innocuous as `search` will only flush the
fields used in the search, however for `res.partner` the default
`_order` is... `display_name`. Meaning we flush that computation,
forcing the computation of `commercial_company_name`, but since
`commercial_partner_id` is being computed we reuse its old value (or
something), which is not re-recomputed after the
`commercial_partner_id` computation ends.
So rather than resolve a full search involving an order, filter the
records in-place.
OPW-2427264
closesodoo/odoo#67987
X-original-commit: 221ea6079b2beeb66c4cfa48b237791e1b380c5e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.
Fixes https://github.com/odoo/odoo/issues/63306closesodoo/odoo#67986
X-original-commit: 71b6fc7341dfec5e8fc2352c3143b1e324a880f8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closesodoo/odoo#67978
X-original-commit: e795ce5bff14b6b748c1f4a2651946aafdc299f4
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When adding a variant product, if the option "Variant Grid Entry" is
enabled, it will reset the delivery date of each purchase order line.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Variant Grid Entry"
2. Create an RfQ
3. Add the field "Delivery Date" to purchase order line view
4. Add a basic product (e.g. "[FURN_6666] Acoustic Bloc Screens")
- Keep its delivery date in mind
5. Add a variant product (e.g. "[E-COM12] Conference Chair (CONFIG)")
Error: The delivery date of the first purchase order line has changed
for no reason. Moreover, suppose that in step 4, the user defines a
specific date: the latter will still be changed after the variant
product is added.
When adding a product, the delivery date of the purchase order and its
lines are recomputed. However, an override of `onchange` ensures that
the new delivery date of the lines will be ignored if the `onchange`
concerns the field `order_line`. Here is the problem: when using the
Variant Grid Entry, the `onchange` concerns the field `grid`. As a
result, the new delivery dates are kept. This explains the creation of
`_must_delete_date_planned` in this fix.
However, when returing the result of an `onchange` linked to `grid`, the
result contains the existing lines (on client side) and the new ones
(from the Variant Grid Entry). If the field `date_planned` of the new
lines is deleted, the client will raise an error when it tries to render
these dates (it has no information about their value). Since existing
lines are of the form `(0, <client_id>, <values>)`, this fix only
deletes `date_planned` field for lines with <client_id> defined.
OPW-2454164
closesodoo/odoo#67972
X-original-commit: d2d495bca3e91862470702f1ef07aa27c33d8e2d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Allow creating a journal entry in the past after having changed the
sequence number reset on newer sequences.
opw-2445559
closesodoo/odoo#67963
X-original-commit: 26a43f23ec2b2490aec0731e25568703729581f0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
odoo/odoo#48362 updated the systems to not show the "Statistics"
section when it's empty, but left an @invisible, leading to not
showing the section at all, ever (which technically does avoid showing
an empty section).
Remove the `invisible` attribute, since the section is now added by
`digest` it should never be hidden. This doesn't fix existing views
tho.
closesodoo/odoo#67964
X-original-commit: 09d8b027e39d1d2eb15abb8d9fe564292fa96d32
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
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>
root