before this commit:
while changing subtypes of the project it was only
propagating those subtypes to the task, whose parent_id is set.
internal subtypes are not propagating in the task of a project.
So, filter internal subtypes and concat them with the subtypes which
have parent_id.
after this commit:
internal subtypes will also propagate to their tasks
closesodoo/odoo#64767
X-original-commit: f29e9e5edbe08e1a356ceb7c2dbb2f60fb6d3ff5
X-original-pr: odoo/odoo#47336
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit contains a followup / rewrite / backport of #34150 :
* odoo/odoo@16dd3da
* odoo/odoo@0b11ed8
Fix: propagate generic internal subtypes from parent to childs with auto
subscribe.
With this commit, when the user subscribes to internal subtypes like
activities on a parent record (e.g. a project) then the user follows them
by default on every sub record creation (e.g. all new tasks of this project).
Fix: do not reset existing subtypes when changing parent of a record using
auto subscribe mechanism.
With this commit, when changing subtype subscription from a parent record
(e.g. project) avoid resetting all subtypes subscription on existing sub
records (e.g. all new tasks of this project). Only new records will use the
parent chosen subtypes. This is done through propagation of followers
existing policy (see Follower._insert_followers() for more details);
Note that fix done here is slightly different from the one done in odoo/odoo@16dd3da
as there was some mismatch with internal model-related subtypes. Thix fix
will be forward ported and improve the previous one.
Task ID-2205643
COM PR #47336
X-original-commit: 01254f06e8ea37887e190758cc479a098591ab8e
X-original-pr: odoo/odoo#47336
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Alexandre Khun <aku@odoo.com>
Co-authored-by: Priyanka kakadiya <pka@odoo.com>
We recently found a bug about generic internal subtypes not being correctly
propagated when doing auto subscribe.
For example: subscribe to a project, check an internal subtype like activities.
Auto subscribe done on project tasks should include actitivities subtype but
is currently not the case.
This test highlights the issue and a fix will be provided soon. In this test
we check both
* generic subtype propagation (comment- or activities- like subtypes);
* model-specific subtype propagation through parent relationship (like
following New Task on project to follow New on task);
* internal subtypes not being propagated to portal users;
* auto subscribe at create with both create and parent follower reasons;
LINKS
Task ID-2205643
COM PR #47336
X-original-commit: 1e29d48f5b10deca9ed7b991ea92ffc36f61c725
X-original-pr: odoo/odoo#47336
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Priyanka kakadiya <pka@odoo.com>
Before this commit the dimensions of the tour tip text obtained from
the text content was forced onto the complete active tooltip, sometimes
hiding a part of the text because the complete tooltip had additional
borders that prevent the text from using the same space as during the
measurement.
After this commit the dimensions of the tour tip text is computed by
taking the measure on the full tip by temporarily switching it to the
text display during initialization.
task-2391201
closesodoo/odoo#64771
X-original-commit: 8bd038c74c2e3b89b78e54385e5a2380fa1b54b7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This test at least ensures that a SCSS edition through the editor can
properly be done and indirectly tests that the assets order is correct
(in prevision of a future asset refactoring).
closesodoo/odoo#64770
X-original-commit: fe19b48831df17352ea7dbb0b7fa2497ac2da38f
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
We were using 'onExit' instead of 'mouseExit' as the value of the
data-attribute 'display' in the .js code of the s_popup.
task-2312878
closesodoo/odoo#64751
X-original-commit: bca1a13a846b3398a70f12be259a425df140a8f7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when the project is billable, we need to define a
customer to have the list of SOL. The problem is the customer field is
in "Settings" tab and not "Invoicing", it can be confused for the user
to directly understand why he does not have the list of SO.
This commit moves the customer field (that is partner_id) to the main
sheet of the form view. Thus, the user can see directly if the customer
is set or not in the project.
task-2424382
Before this commit, when the user can only see his own timesheets, this
user can see more than his own timesheets in timesheets portal
(/my/timesheets). It is because we use the domain defined for portal and
we don't use the access rights defined for this intenal user.
This commit uses the access right if the user has the lowest group for
Timesheet App. Otherwise, we use the domain for portal as before.
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
task-2424382
Before this commit, the user need to select in these both fields to
configure the pricing type of a project. Three choices are possible :
1. Task Rate
2. Project Rate
3. Employee Rate
This commit merges the both fields to have single field called
pricing_type and the user selects the one of three options cited above.
The goal of this changes is to facilitate the configuration of a
project.
task-2424382
This method was triggered when the employee_id field changes to change
the so_line field of the timesheet. However, the _compute_so_line
method does the same processing. Thus, this onchange method is useless
and replaces by this compute.
task-2424382
When the remaining_hours field is stored, we can search the last
SOL and the remaining hours on SO is greater than 0 for a customer with
only a search in SOL model. With this changes, we increase the
performance because before this commit, we search and retrieve a list of
SOLs and then we filter this list to find the last SOL with remaining
hours on SO is greater than 0.
This commit stores this field in sale.order.line model and we update the
_get_last_sol_of_customer method in project.task.
task-2424382
In 14.0, we removed the warning displayed in onchange methods. These
onchange methods were only used for this use case. Then, this commit
removes these onchange methods.
task-2424382
In 14.0, we try to add a timesheets table in Invoice portal and Sales
Order portal. Unfortunately, this table is not suitable for the use
case. Because this table can be too long for the customer, it is better
to redirect the user to the timesheets portal and filter these
timesheets to have the ones that the user want to see.
task-2424382
The sale_timesheet_edit is a new module created in 14.0 to allow to the
user to manually edit the SOL in timesheets from task form view.
This commit adds this feature in the sale_timesheet module and removes
the sale_timesheet_edit module.
task-2424382
This commit removes all reference to project.task non_allow_billable.
This also implies:
* account.analytic.line non_allow_billable
* account.analytic.line timesheet_invoice_type selection value
'non_billable_timesheet'
task-2424382
This context key has been added in the 14.0 for a fix in helpdesk to
create a sale order form a ticket.
But, now we remove the 'create sale order' button in the ticket to add
sale order line field in the ticket, this field allows to link the
timesheet in this sale order line selected in this field.
Thus, this commit removes the context key used 'ticket_timesheet_ids'
since this key will never be given again in this wizard.
task-2424382
Purpose of this commit is to rewrite channel tests, notably moderation
tests. In this commit we
* use standard users instead of admin/root: this allows to test ACLs and
more real life oriented use cases;
* remove unnecessary tests or merge tests belonging to the same category;
* add some coverage for corner cases;
* make tests more readable;
We also improve some notification code and error messages that are not
really helpful for users.
Followup of odoo/odoo@e9571a403e
Task ID-2421795
closesodoo/odoo#64459
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Do not update the date_planned of section/note purchase lines when the
date is changed on the order.
Based on f3ebab6eb52e3dc8be1f030aecfff348a22f7e09
opw-2429853
closesodoo/odoo#64458
X-original-commit: c1d5a077f26d5cb5f42888f21dafd78e3432853f
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This is mandatory for PA customers, and required by several enterprise customers as well.
Related Ticket: 2425845
closesodoo/odoo#64443
X-original-commit: bb898e663019942a6fd99ce96ce5742a8ff7ea56
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Consider a constraint method with two fields: a normal field, and a
field with an inverse method. When calling write() with both fields,
the constraint method should be invoked once.
closesodoo/odoo#64433
X-original-commit: 25760348859f594abb796b5bc7b28f63e298cd53
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Steps to reproduce the bug:
- Create a user with only access rights, Inventory = Administrator, Purchase = user
- Enable feature Purchase order approval in Purchase > Settings
- Agreement Type = Exclusive, lines of Agreement, Quantity of Agreement
- Login as a new created user and navigate to a menu Purchase > Purchase agreement and
create a new Purchase agreement, confirm it
- From the button create two PO (having a total > 5000)
- Cancel one of the PO first and try to approve another one
Bug:
A UserError was riased: You have to cancel or validate every RFQ before closing the purchase requisition.
opw:2368999
closesodoo/odoo#64431
X-original-commit: dfee34b0b9c83beca9aca0b21e7f130ae86c0ee6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
If we change ``active_model`` in context, we have to reset active_id(s),
otherwise we read a random records which may not exist.
STEPS:
1. Activate Developer mode
2. Go to Settings > Technical > Automation > Automated Actions
3. Define a new Automated Action with the following settings:
- Model: Lead/Opportunity
- Action To Do: Execute Python Code
- Trigger: Based on Form Modification
- Trigger Fields: Customer (crm.lead)
- Python Code:
```
raise Warning(records)
```
4. Go to Contacts, create a new contact and save it.
5. Click on the "Opportunities" Smart Button on the top left of the contact record.
6. Click "Create".
BEFORE: ``records`` in context read crm.lead, while id is for res.partner
record
AFTER: ``records`` is None
---
opw-2424392
closesodoo/odoo#64421
X-original-commit: 6fd6d68ee6eee6460ffda8b7dd691c0ef93b7a30
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Previously, when changing the background-color of an icon in the
s_process_steps snippet, the line that goes through the snippet would
disappear from that block. This was caused by our font-application code
attempting to remove extraneous DOM nodes when changing a font color or
backrgound-color, but not considering elements with a ::before or
::after pseudoelement has having content, and subsequently removing
them.
opw-2423785
closesodoo/odoo#64412
X-original-commit: 6b363d202d9c35e8249f7bb2b0730b995fdf4a7d
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
In order to make the expense form more intuitive, it was necessary to distinguish between whether the product has cost different from
zero or not. Depending ot this context, some fields are shown or not. Also 'Bill Reference' is shown only to account managers.
Now the expense can be submitted in different currency and it can be reimbursed in company’s currency.
In case the latter two currencies differ from each other,
the conversion is done automatically and the rate is also displayed.
Suggestion - untaxed_amount can be removed
Task - 2366775
closesodoo/odoo#61920
Related: odoo/enterprise#14838
Related: odoo/upgrade#2028
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Let's consider two pricelist PL and
- Create a new order O
- Add a line L
- Set PL as pricelist
Bug:
The button Update pricelist didn't appear
Closes#64269
opw:2429987
closesodoo/odoo#64734
X-original-commit: 77436f674d84666511b8b5c2b1355b95beaace94
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Prevent duplicate SN through python constraint (requires SN to be
attempted to be created) instead of assigning existing one (and
causing a duplication). Steps to reproduce:
- create a SN tracked product + activate "storage locations"
- assign a SN to tracked product
- create a planned receipt for the tracked product and assign same SN
(i.e. same name).
Warning will pop up about repeat SN, but it is still possible to
validate the picking and create a duplicate SN.
Also add an extra `limit=1` to lot search for performance/safety.
Bug was discovered while working on related task: 1924758
closesodoo/odoo#64714
X-original-commit: cd81b7accad63ec433ff66e58f286626cfc1ac65
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The calendar reminders are emails or web notifications sent moments
before an event start. The mechanism to send web notifications is
controlled by the browser, it fetches all the future notifications and
uses `setTimeout()` to delay them. The mechanism to send emails was
controlled by a cron, every 30 minutes the cron would look for the
coming events and send the mail reminder.
The cron was running every 30 minutes even if there was no event. The
best precision was 30 minutes.
The new mechanism use cron triggers, every time one add email reminders,
triggers are created to call the cron at the precise moment the alarm is
set. The cron no longer send emails for events in the coming 30 minutes
as those will be triggered too.
closesodoo/odoo#64560
Task: 2416741
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
There is code that automatically enable or disable the cron whether it
exists alarms. As alarms are automatically added, the cron is actually
always enabled.
Steps:
- As admin, go to "Contact us" or any other page on the website (1)
- Go to Pages > Page Properties > Publish
- Change the visibility to Signed In
- Save
- As demo, go to (1)
Bug:
The user "demo" is signed in but is returned a 403 Forbidden
Explanation:
When landing on a page with visibility: 'connected', the only way to see
the page is to have a group matching the groups of the page as seen
here: https://github.com/odoo/odoo/blob/28b748a559e1ffb5fb7c3631bf77adba121b2ebf/odoo/addons/base/models/ir_ui_view.py#L625-L626
This fix lets any connected users see the page.
opw:2431700
closesodoo/odoo#64720
X-original-commit: b02a99bec709b5a6dc4dabb6cb81435dadc24e7e
Signed-off-by: backspac <backspac@users.noreply.github.com>
The emails sent via Odoo reveive a poor score on various spam tools,
the reason being the missing `MIME-Version` message header. This header
inform what MIME version is in use in the message. Even if there is only
one standardized version of MIME (1.0), the header is mandatory.
Citing [rfc2045] "MIME: Format of Internet Message Bodies" section 4:
> the MIME-Version header field is required at the top level of a message.
Setting the charset on the envelop forces the EmailMessage API to also
include the missing `MIME-Version` header.
[rfc2045]: https://tools.ietf.org/html/rfc2045#section-4
Task 2393865
closesodoo/odoo#64715
X-original-commit: 8663f1e20727c315924bb20fc1de1accf3014c61
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This fixes some details and reorganize the order of the tutorial. It
also introduces a more detailed section for the SCSS customization. A
very detailed and updated version of this tutorial is being made for the
14.0 version and later.
task-2440442
closesodoo/odoo#64700
X-original-commit: 08d44d444490713ca39618a67f441bbd84b8b900
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Accounting" module
- Create a new bill :
- Set vendor
- Set no payment reference
- Set a bill reference
- Add products to bill
- Confirm and click on Register Payment
Memo field has no value.
Cause
The memo field is based on lines name.
Lines name is computed in `_onchange_payment_reference`
and depends only on payment_referecence.
Solution
If no `payment_reference`, fallback on `ref` to set line name.
opw-2440389
closesodoo/odoo#64692
X-original-commit: 31bc04afc3ed4ea74cd20f71ea10943b1026629c
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When using a tracked product in a MO, the lot/serial number reservation
disappears even if the product is still reserved.
To reproduce the error:
(Need mrp)
1. Create two products P and P_compo
- Both are storable
- P_compo is tracked by lots
2. Update P_compo's quantity
- Set the on hand quantity of lot L to 5
3. Create a MO
- Product: P
- Quantity: 5
- Add a line: (Product: P_compo, To Consume: 5)
4. Confirm
5. Check availability
- The P_compo's reserved quantity has been updated to 5. If you
click on the line's details, you can see that 5 P_compo has been
reserved from lot L
6. Back to the MO, in edit mode, change the done quantity: 3/5
- There are still 5 reserved P_compo
7. Click on the P_compo's line details
ERR: the line we saw on step 5 disappeared. The MO says that 5 P_compo
are reserved, but when checking which lot is reserved, the latter is
no more visible. Moreover, if you click on "Confirm" (so you leave the
"Detailed Operations" pop-up), the "Reserved" field of the line will be
reset.
The lot reservation should stay so the user can complete the "Done"
field.
OPW-2420347
closesodoo/odoo#64684
X-original-commit: 8dfee8cb2d60942641b73eaa6489b02aa378c5ac
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closesodoo/odoo#64683
X-original-commit: 69cadbe1be6320d96fe9bc5bf8dd808f87d735c0
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Priyanka kakadiya