We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
Task-id: 3052677
Part-of: odoo/odoo#114758
Allow partner to unfollow a document from a follow up email or the inbox:
- through an unsubscribe URL in the email even if not connected
- through a link in the inbox
**Details concerning the inbox implementation:**
When hovering on a follow up message with a related document followed by the
user, the interface displays an action to unfollow it that allows the user to
remove himself/herself as follower of the document. As a result of performing
that action a toast is displayed as a feedback.
Technical note:
The unfollow link is displayed on a message.canUnfollow is true which check
that the thread related to the message is followed by the user.
In order to know if the user follows the record related to the message, we now
transmit with each message the id of the follower table that link the user to
the related record if it follows it. This allows to insert the follower on
client side so that the unfollow action can use the standard mechaism already
developed to unfollow a record.
Unfortunately, that information coudn't be added in the already public method
message_format of mail message because that method is not always called on the
user retreiving the message but also by the one posting message. We didn't want
also to include all followers in the formated message so we rely on additional
method that add that information per partner.
To support unfollowing a document in the inbox no matter the current company,
we have modified message_unsubscribe in mail_thread to allow internal user to
unsubscribe themself without checking any rights. Indeed, some document have
record rule that prevents reading it if the user is not in the right company
(ex. crm.lead) and then was preventing the user to unfollow the document using
that method.
**Details concerning the mail implementation:**
It works for internal user for follow up on any document and for any partner on
follow up of document tagged as authorizing being unfollowed by any partner (
slide.channel and slide.slide).
Technical note:
The unfollow block is rendered in mail_thread and updated for each recipient in
mail_mail. We don't render it in mail_mail because we don't have the language
of the message at that point.
Depending on the partner and the related document, the unfollow block is:
- either removed if the user cannot unfollow the document (for example if it
doesn't follow it)
- or updated with partner and document information + a security token
**Query count adjustment:**
In order to display the unfollow link or not in emails or in the inbox, the
system need to query the followers of the document. This is what explains the
added queries.
Task-3061864
closesodoo/odoo#107978
Related: odoo/enterprise#34972
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add tests that check the behavior of unfollowing a record from the inbox and
the unfollow link in email.
To support unfollowing a document in the inbox no matter the current company,
we have modified message_unsubscribe in mail_thread to allow internal user to
unsubscribe themself without checking any rights. Indeed, some document have
record rule that prevents reading it if the user is not in the right company
(ex. crm.lead) and then was preventing the user to unfollow the document using
that method. We also add a test checking that internal user can unsubscribe a
record without any read and write rights. And that a portal user can't in the
same circumstance.
Task-3061864
Part-of: odoo/odoo#107978
In order to display the unfollow link or not in emails or in the inbox, the
system need to query the followers of the document. This is what explains the
added queries.
See odoo/odoo#107978
Task-3061864
Allow partner to unfollow a document from a follow up email of that document
through an unsubscribe URL in the email even if not connected.
It works for internal user for follow up on any document and for any partner on
follow up of document tagged as authorizing being unfollowed by any partner (
slide.channel and slide.slide).
Technical note:
The unfollow block is rendered in mail_thread and updated for each recipient in
mail_mail. We don't render it in mail_mail because we don't have the language
of the message at that point.
Depending on the partner and the related document, the unfollow block is:
- either removed if the user cannot unfollow the document (for example if it
doesn't follow it)
- or updated with partner and document information + a security token
Task-3061864
Part-of: odoo/odoo#107978
Allow users to unfollow easily document from the inbox for which he/she doesn't
want to be notified anymore.
When hovering on a follow up message with a related document followed by the
user, the interface displays an action to unfollow it that allows the user to
remove himself/herself as follower of the document. As a result of performing
that action a toast is displayed as a feedback.
Technical note:
The unfollow link is displayed on a message.canUnfollow is true which check
that the thread related to the message is followed by the user.
In order to know if the user follows the record related to the message, we now
transmit with each message the id of the follower table that link the user to
the related record if it follows it. This allows to insert the follower on
client side so that the unfollow action can use the standard mechaism already
developed to unfollow a record.
Unfortunately, that information coudn't be added in the already public method
message_format of mail message because that method is not always called on the
user retreiving the message but also by the one posting message. We didn't want
also to include all followers in the formated message so we rely on additional
method that add that information per partner.
To support unfollowing a document in the inbox no matter the current company,
we have modified message_unsubscribe in mail_thread to allow internal user to
unsubscribe themself without checking any rights. Indeed, some document have
record rule that prevents reading it if the user is not in the right company
(ex. crm.lead) and then was preventing the user to unfollow the document using
that method.
Task-3061864
Part-of: odoo/odoo#107978
Before this commit changing priority from sub-task
and block-by task saves the unsaved change or even create new
records even though user discard that changes.
This commit add 'auto_save' false to prevent auto save for
sub-task and block-by task page.
task-3282848
closesodoo/odoo#120925
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit state selection and priority both
field are saved we change its value even though we
are not saving records and because of that changing
state or priority in sub-task or block-by task
and discarding changes does not set them to their
previous state and it'll create new record without
saving if we change one of those field.
This commit add 'auto_save' option to prevent auto save
on state and priority from sub-task and block-by task
page.
task-3282848
Part-of: odoo/odoo#120925
This cancels the changes added to f91782279a
for minor version 16.3 as the server action is completely removed
instead of being fixed in this.
The action is not removed in the upgrade as it is still technically
working. Though it should be considered deprecated.
------------------------------------
We remove the action that was used to conditionally call a window action
The action was not called consistently and added confusing indirection.
To maintain the current behaviour of only suggesting adding a loss
reason for opportunities.
We make the reason fields toggleable in the wizard, and hide them by
default for leads.
This leaves the user with the option to add a reason anyway, and serves
as a confirmation wizard if they don't want to.
-------------------
task-3272955
closesodoo/odoo#118494
Related: odoo/upgrade#4640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this we used the context active_ids directly to determine
which leads to mark as lost in the lost reason wizard.
We now use a m2m field to store that value to make the behavior more
obvious and predictable, and to ease debugging.
task-3272955
Part-of: odoo/odoo#118494
The bank statement & transaction demo data has problems:
1. the statement doesn't have a name
2. the creation of the statement lines are postponed causing the opening/closing balances to be invalid (as the order of the statement lines is important)
This is due to the _load_data method in account, which defers the creation of records to ensure that related records are created before they are referenced in relational fields.
This commit adds a condition to avoid deferring fields that have a list of ORM create commands, and fixes the statement name and balances.
closesodoo/odoo#120975
X-original-commit: 1d219de36944685153a77aeeb72920b06728383e
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
When partially reversing a bill and paying the
difference, the payment state should be 'paid'.
In the particular case of having the bank account
as manual outstanding payment account on the bank
journal, payment state was 'reversed'.
opw-3235107
closesodoo/odoo#120967
X-original-commit: eb0baf273980957b522e3e41b5d371ba081c915d
Signed-off-by: Laurent Smet <las@odoo.com>
Co-authored-by: Habib Ayob <ayh@odoo.com> & Laurent Smet <las@odoo.com>
When the `account.journal.bank_statement_source` field is validated at that time
it won't be able to find the `file_import` value in the options of this selection
field as they are dynamically generated and the `file_import` value is generated
in the `account_bank_statement_import` module which is not installed.
So, it will cause Error.
Steps to reproduce :
1. Install only `account` module
2. Click on Configuration > Add Bank Account.
3. Fill up the details. The `Journal` field should be left empty.
4. Click on Create.
closesodoo/odoo#120923
Sentry: - 4042261837
X-original-commit: eda822ce7c3884350ecfb8bbb10accfe7ff5acf4
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit: if you add a custom one2many field to the
'res.partner', like x_related_commercial_partner_ids, that is related to the
`commercial_partner_id` in the`res.partner` model, it won't update the
display name of a contact in case of changing its parent_id name.
Here are the steps to reproduce the problem:
1. Create a new custom field with these values:
a. Field Type = one2many
b. Model = Contact
c. Related Model = res.partner
d. Relation Field = commercial_partner_id
2. Create a new Contact that is the "Company" (e.g. "My Company")
3. Create a new Contact that is the "Individual" (e.g. "My Name"), and
put the "My Company" as its parent_id.
4. Now the display_name is "My Company, My Name" which is correct
5. Change the company name to "My new Company"
-> display_name won't change, and is "My Company, My Name"
The solution is to add the 'commercial_company_name' to the
`display_name` depends.
opw-3202894
closesodoo/odoo#120908
X-original-commit: f242cad9a27fb0e58e1b9c726573b316534f6be8
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before, when the user pastes a list of tracking numbers into the move
line's `lot_name` field (through the move's detailed view), a lot is
created for each line, creating a move line for each new lot, or
assigning each lot to an existing line with no lot.
With this commit, it will also take `qty_done` and `expiration_date` (if
`product_expiry` is installed) from the pasted list if it's relevant.
Each data should be separate either by a semicolon, either by a tab, and
the first data should always be the lot name.
Valid examples for lots and quantities:
lot-01;22
lot-02 12
Valid examples for lots, expiration date and quantities:
lot-03;8;01-02-2005
lot-04 2005/02/01 12-20
The only valid separation characters for the date are the space (" "),
the dash ("-") and the slash ("/"). Examples of valid dates:
20-02-24 20-Feb-2024
20 02 24 20 Feb 2024
20/02/24 20/Feb/2024
If any of the extra values can't be converted into either a quantity or
a date, the whole line will be used as the tracking number.
Also, if dates are pasted but the product doesn't use any expiration
date, the date's part will be ignored.
task-3171866
closesodoo/odoo#115401
Signed-off-by: Tiffany Chang <tic@odoo.com>
Have an invoice marked as paid
Send by email
Issue:
Email will contain "$ <amount> due <due date>" which is confusing for
the user as the invoice is already paid
opw-3289653
closesodoo/odoo#120905
X-original-commit: 5c66a766abed5142d77835dcfda423abdcb1429f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
If applied, this commit will handle the KeyError: res_id when the user tries to
import the translation of .csv file in settings -> translations, and if .csv
file doesn't have the res_id column.
I handled the traceback by changing the logger level to warning.
sentry - 4049419481
closesodoo/odoo#120904
X-original-commit: f5b69559a04cad9a693b991497936cf11ca36aeb
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
*: calendar, iap_mail, im_livechat, mail.
Until now, one had to subscribe to the global "notification"
event of the bus service and to loop through each notification
to handle the one that was targeted.
This PR introduces the `subscribe` method on the bus service
in order to subscribe to a single notification type.
closesodoo/odoo#120893
Related: odoo/enterprise#40848
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The above two fields, which we are cleaning up, were added to fix the
resequencing issue https://github.com/odoo/odoo/pull/108450.
The other problem that remains here is that whenever we are opening the multiple
choice question from the (survey.survey) form view after changing the question
selection field, we get traceback.
The problem was generic, so a more generic fix was pushed into the JS framework
https://github.com/odoo/odoo/pull/116561 ,which solves the earlier resequencing issue. So here we are cleaning up
the earlier fix, which is unnecessary now. And by this issue while opening multiple
choice question also resolves.
Task-3127646
closesodoo/odoo#120618
X-original-commit: c65c15eaab4b6e62e671c00a25d2aef2287d4387
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Remove links to UoM form since they are useless and lead to unused
forms.
Part of task-3218314
closesodoo/odoo#119381
Related: odoo/enterprise#40153
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Displays the Incoterm code and location on the delivery slip as it's
currently displayed in the purchase order report.
Part of task-3218314
Part-of: odoo/odoo#119381
By only auto-batching pickings that are ready, it allows, if you reserve
X days in advance, to make batches for those periods, almost like batch
on the scheduled date.
Part of task-3218314
Part-of: odoo/odoo#119381
Steps to reproduce:
- Inventory -> Configuration -> [Products] Attributes
- Create new Attribute with 'Variants Creation Mode' set to
'Dynamically' with a few values
- Inventory -> Products -> Products -> New
- Set the new dynamic attribute to the product and save
- If you try to set a barcode, the field will empty itself at each save
When a product is created with 'Dynamic' attributes, the variants will
only be created once the combination of attributes is used. So initially
there is no variant, hence nowhere to set the barcode.
So we avoid letting the attribute being set when there is still no
variant.
Part of task-3218314
Part-of: odoo/odoo#119381
Use filters instead of domains for the `stock.picking` lists accessible
from the menu 'Operations', so all pickings can be easily consulted in a
single view when removing said filter.
Part of task-3218314
Part-of: odoo/odoo#119381
Steps to reproduce :
- Install stock, mrp
- Go to Inventory -> Operations -> Manufacturings
- No MO could be found
The view showed `stock.picking` having a 'manufacturing'
picking_type_code. Now instead shows a list of `mrp.production` as it is
done when clicking on the 'Manufacturing' type in the stock Overview.
Part of task-3218314
Part-of: odoo/odoo#119381
When using the Reserve / Unreserve buttons on the forecast report, this
will [un]reserve every move of the picking / production. We want to be
able to do it on a product base, so that when using the [un]reserve from
the forecast of a product, it will only affect the said product.
Part of task-3218314
Part-of: odoo/odoo#119381
Adds the storage of the product's `categ_id` in the stock valuation
layer as it is a prerequisite for being able to use a groupby in the
tree view.
Part of task-3218314
Part-of: odoo/odoo#119381
When creating an alternative RFQ, set the source document of the
original RFQ as source document of the newly created alternative.
Part of task-3218314
Part-of: odoo/odoo#119381
Adds back the direct link on the purchase line product's column when the
`product_matrix` is enabled. This allows the user to still click on the
product and go to its form when the module is enabled.
Also removes the direct link to the UoM, since it has no use.
Finally, sets a width for the product column in the purchase form to
keep it usable even when multiple columns are selected.
Part of task-3218314
Part-of: odoo/odoo#119381
It should be possible to modify the custom description of a Blanket
Order line without having to reset it to draft to do so.
Part of task-3218314
Part-of: odoo/odoo#119381
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115330
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115317
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115232
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Currently, automatically PO is generated in that PO buyer field is empty.
So in this commit, we added buyer field in partner form view, when rfq is
generated automatically and vendor has a specific buyer then at creation
of rfq, the PO buyer field will be set according to that.
TaskID - 3151213
closesodoo/odoo#113709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, all search result illustrations were displayed
before the Unsplash images.
This commit makes the search result images from Unsplash and the
illustrations alternate, beginning with the first Unsplash image.
The existing attachment results remain in front.
task-3060679
closesodoo/odoo#111481
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
And open interview forms on a new tab as well
task - 3293231
closesodoo/odoo#120903
X-original-commit: 7bed47dc59ae8c88048e585f0104db70b76a7f28
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit an ir_assets generated automaticaly by the web editor
will generate an url ending with ...custom.addon.bundle_name.ext
After this commit the url will start with /_custom/addon.bundle_name/...
This will make it easier to spot at immediately if it is a custom asset
and thus it is useless to apply the glob. Actually, it will fail on the
/_custom when trying to glob, making it faster.
This is mainly useful to clarify and debug but in a case with mainly
customised ir_asset for one bundle, it may have an impact on speed.
An upgrade script was created for this change.
closesodoo/odoo#120699
Related: odoo/upgrade#4636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This comes as a followup of https://github.com/odoo/odoo/pull/120423 where we restrict unallowed users to toggle the field allow_out_payment when writing on res.partner.bank. Similarly, we'll now do the same check at the creation of bank accounts
closesodoo/odoo#120694
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Some glob are more complex than they should.
Since `**` matches no/one or many directories, the use of /**/**/ is
the same as /**/.
Since **.js is similar to *.js except if you except to have a js file in
a directory ending with js. Moreover ** will match any directory
recursively before a js file.
closesodoo/odoo#120880
Related: odoo/enterprise#40842
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
We want to propagate the analytic breakdown on the accrued
entries that user can already create from the PO/SO list views.
task-3096126
closesodoo/odoo#120864
X-original-commit: d4d92029bf7c2a2c6a670170d3207b457dda5c68
Signed-off-by: William André (wan) <wan@odoo.com>
The action `Create Employee` on an applicant would open the form view
with the fields pre-filled, but the employee would not be automatically
created when leaving the view.
task-3301176
closesodoo/odoo#120566
Related: odoo/enterprise#40835
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Some translations could not be exported, as reported in odoo/odoo#114711.
This is due to Babel—the library we use to extract `_t` occurrences from
the sources—ignoring javascript template literals, resulting in any
gettext inside template literals not being parsed and exported as
translatable resources.
From version 2.12.0 of the library, support for javascript template
literals can be enabled by providing the `parse_template_string` option
to the Babel `extract` method.
Unfortunately, the library cannot be updated for now, as our policy is
to stick to the version of packages from the official Debian repository.
This commit refactors some code so that no gettext is inlined within
template literals.
closesodoo/odoo#119996
Related: odoo/enterprise#40457
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Bugfix: at the moment, if the environment's language is not en_US,
loading a CoA doesn't correctly load the translations: the translations
for all languages are created with the en_US terms.
Steps to reproduce:
1. Create a DB and install l10n_be.
2. Switch to French.
2. Create a new company based in Belgium.
3. Install the Belgian CoA on the company.
Expected behaviour: The accounts should be in French.
Actual behaviour: The French translation of the accounts contains
the terms in English.
Analysis:
When the records are created by _load_records(), the language of the
environment is French. As a result, all translatable terms are created
with translations in en_US and in fr_FR.
See https://github.com/odoo/odoo/blob/39292a02ab34ea86abd5601055901eb968006944/odoo/fields.py#L1762-L1771
Later on, when the translations are loaded by _load_translations,
there already exists a name->'fr_FR', so our call to
translation_importer.save(overwrite=False) doesn't want to overwrite it.
See https://github.com/odoo/odoo/blob/2780c37cfdb8560ac7c725fd27f4fe272f1d3072/addons/account/models/chart_template.py#L787
As a result, we end up with the English terms in both the en_US and
fr_FR translations.
The fix:
Set the language to en_US when calling _load_records().
closesodoo/odoo#120863
X-original-commit: 52ef69aa8423a0fd5d78af1ab018a98dba87361c
Signed-off-by: William André (wan) <wan@odoo.com>
Maximilien (malb)