The fields `start_datetime` and `stop_datetime` are the exact miror
of fields `start` and `stop` respectively.
The field `display_start` is never used.
Hence those fields are removed.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit removes the `state` field of calendar events.
The field was not displayed on any view and never used by any business code.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Some fields of a calendar event are private.
The previous implementation was deleted while refactoring recurring events.
This commit cleanly re-implements the feature.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit refactors the event attendees and notifications according
to the recurring event refactoring.
Some (very) basic reminder tests are also added.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.
Purpose
=======
The current implementation of recurring events uses "virtual events" to represents all
events in the recurrence. Only one event is stored in the database. All other events are
dynamically built and sent to the web client which sees them as real records.
This implementation is old, difficult to read (6 years of changes and bug fixes) and
has become more and more difficult to maintain.
A fresh start would be welcome.
Specification
=============
When creating a recurring event, a `calendar.recurrence.rule` record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.
This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut
to create a recurrence running for 720 events.
Inspired by Google Calendar, new possibilities are introduced when modifying a recurring
event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events
In a similar way, when updating the rrule of an event (e.g. from every Monday to every
Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains
unchanged but now ends when the second recurrence begins. The second parts is the
updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)
Note: when events are "moved" because the rrule changed, the events are not actually
moved. They are unlinked and new events are created (See "Some design choices explained"
section).
Some design choices explained
=============================
Where to store the rrule?
-------------------------
Two options were considered.
1) Store the rrule on an event, each event of the recurrence having a Many2one
to the parent_id, aka the Master Event of the recurrence.
2) Store the rrule on another model: `calendar.recurrence.rule`. Each event in the
recurrence having a Many2one to the recurrence record.
Both options have pros & cons. But there is no clear winner.
However the actual business logic of handling the recurrence creation/update
would be the same.
Where the rrule configuration is stored is the only main difference between both options.
And this is probably the easiest part of implementing recurring events.
With that in mind, option 2) is chosen. It allows to clearly separate recurrence
logic from the events themselves. It is also the "correct" way of modeling data to avoid
many empty columns for most records.
Reusing events on rrule update
------------------------------
When an rrule is modified, events should also be updated.
In most cases, current events are unlinked and new events are created from scratch.
Only events exactly at the same time before and after the rrule update are kept.
Trying to reuse other events would require an obscure and arbitrary heuristic.
(Imagine an rrule every Monday that is changed to every Tuesday and every Friday.
What would you do?).
This implies that any change to a specific event (name change, attendee added, chatter
messages) is lost. This tradeoff seems acceptable as updating an rrule should not be
that frequent. Moreover, Google Calendar also works that way so why not Odoo?
Reusing events on events shifts
-------------------------------
On the calendar view, drag and drop an event to shift the entire recurrence.
One way to handle the recurrence shift is to apply the same timedelta to all events.
Now events are correctly positioned... except for events that were specifically
moved. Those outliers needs special handling.
This also introduces some behavior inconsistencies:
when an rrule is directly modified, events are not reused, but when the rrule is
modified by drag & dropping an event, events are reused. This option needs more code to
handle the shift and the behaviors are not consistent.
The chosen option is to find the rrule configuration from the dragged event (this is
easy) and update the recurrence with those new rrule values. This brings us back to
an rrule update (see above): code reusability yeah; one behavior to rule them all yeah.
One downside is that outliers are lost (but Google Calendar also works that way).
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
When creating a record and clicking on the go to website button before
saving it previously saved the record and browsed it on the website.
Currently it does not save it and the redirection is broken too.
This is fixed by using the same trigger as the other stat buttons.
Introduced by: https://github.com/odoo/odoo/pull/34261closesodoo/odoo#49262
X-original-commit: 700f57ef13e45527c2d249fc431e1d54e0bc1955
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
When duplicating a calendar, duplicate their global time off too.
closesodoo/odoo#49255
Taskid: 2230549
X-original-commit: b1417a8f094331246120ce5f0a5d25db6c6eb8a7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Currently, when setting a global leave for a company, the
leave validation raises an UserError if there is already a
leave on those dates.
Specification
=============
Manage the conflicts for easy tests cases:
- The global time off is taken in days
- The conflicting leaves are all in days/half days
For those use cases, refuse all the conflicting leaves
and recreate other one before and/or after the global time
off, according to the use case.
Taskid: 2230549
X-original-commit: 20ef422fea7793fc87dbf51c43699bb7872036f9
Steps to reproducethe bug:
- Create a SO with N units of a storable product P
- Confirm the SO, cancel it, reset it to a quotation and confirm it
- Change the quantity of P to N-1 units on the SO
Bug:
The canceled picking linked to the SO had an activity exception
opw:2199962
closesodoo/odoo#49267
X-original-commit: 916071a06ebfb11b0a2d0d420b7682ee64a7c3d2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
opw-2230833
* What are the steps to reproduce your issue?
1. Goto https://runbot.odoo.com/runbot and connect to latest enterprise
version
2. Create a vendor bill with with 2 invoice lines, both having an
analytic account.
3. Click save.
4. Click Edit
5. Change analytic account on 1 line.
6. Click save.
* What is the current behavior that you observe?
The other invoice line has it's analytic line resetted to default (null,
exept if analytic_account_default is used), even though that line was
not edited, by the user.
* What would be your expected behavior in this case?
No extra changes on lines that were not edited when saving the invoice.
I checked that if you comment out '_onchange_invoice_line_ids' method
from account.move this issue disappears, so maybe start looking for the
bug from there.
closesodoo/odoo#49174
X-original-commit: a3e9598a1d964675a545680c34ee87a6136ef71c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Creating new `account.move.line` is already blocked at List/Form view but it was not disabled at Kanban views since it is needed for mobile views. Creating new AML from Kanban leads to traceback due to the required field.
In this commit, we pass `'create':0` in the action so user can not create new AML from any view.
closesodoo/odoo#49244
X-original-commit: 1db71a9968b09bc56eff11e54d4e5b52693196cf
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Let's assume an editable="bottom" list view with handle widget and a
required field. Moreover, there are less than 4 records in the list,
so there are empty lines at the bottom of the list s.t. there are
at least 4 rows.
Click to add a row: a new row (in edition) is added at the end of
the list (instead of an empty row). Do not fill the required field,
but instead move another row after the new one (which is still in
edition). Then click on discard.
Before this commit, the discarded row was replaced by an empty one
(s.t. there are always at least 4 rows in the table), but that
empty row wasn't added in the bottom of the list.
task-2209076
closesodoo/odoo#49251
X-original-commit: 22f43536cb78e07aaab3fd806f3c6c5f068824f3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
* Reword tasks in the sample project
* Add a "Create and Edit" button on the project creation modal
* Open the file chooser in "Set a cover image" if there are no images
set
* Correclty display the kanban state button on archived task
* Add a button to list the tasks when deleting a project
* Open file chooser for cover image: Automatically open the file chooser
when setting a cover image on a task if there are no attachments to chose
from.
closesodoo/odoo#47306
Taskid: 2209133
Related: odoo/enterprise#9141
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before the commit, when there is no pricelist, we set the unit price to be 0
on the PO. After the commit, when in the same situation, we use the cost
set on the product form.
Task 2072560
PR #49067
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Switch position of leaves taken / remaining
- Change the "To" date when requesting a leave
- Take into account the leaves to be validated in the dashboard
- UX improvements to the popover
closesodoo/odoo#46210
Taskid: 2198615
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit if the loading of the registry failed because of an
AttributeError or a psycopg2 error the http dispatcher would redirect
the user to the database manager.
This can be problematic because integrators (e.g. odoo.sh) may choose to
disable / forbid access to the database manager, and when the registry
crashes because of e.g. a migration, the real error will be overshadowed
by an AccessDenied error or somesuch depending on the path taken to
forbid access to the database manager.
With this commit, the real exception is simply reraised
closesodoo/odoo#49238
X-original-commit: de4e67dcc52916337251370387aea6aea893a60e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit is another fine-tuning of 348a5d0.
The buttons size is sometimes problematic so
we should reduce it.
OPW-2220893
closesodoo/odoo#49227
X-original-commit: 57999ea32c0cc85283faf06f6edb8649af784838
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently, sometimes users are getting confusing between the concepts
of 'objects' and 'models' when doing advanced configuration or
customization.
So, In this commit we replace 'object' label by 'model'.And also add
quicksearch on the relation field.
TaskId: 2209594
Related Ent PR: https://github.com/odoo/enterprise/pull/9556
closes odoo/odoo#48647
Closes: #48647
Related: odoo/enterprise#9556
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, the Employee picture stays on top of the card of the employee
we're looking for. The image does not disappear after a search is validated.
Steps to reproduce:
>> On employee kanban focus cursor on search panel, then mouse over
to employee image so it will be zoomed, now without mouse leave just
type in the search panel and enter, the big zoomed image stuck on
screen and don't even know how to make it go away.
So in this commit, We fix that on keudown hide the zoom image so
when user search on search panel it will hide the zoom image.
OnShow of zoom bind the generic even keydown and on that just
hide the image so it should not stick on screen.
TaskID : 2212808
Closes : #48253
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
During theme install, theme.ir.ui.view are copied as ir.ui.view for the
requested website.
During theme update, those already created ir.ui.view will receive the
theme.ir.ui.view modifications, including the `arch`, even if it was changed by
the user, meaning the user changes would be lost.
Here are some examples which will be wiped away when the theme
is updated (only if the view is loaded from the theme module):
- Changes made from website HTML/CSS/JS editor.
- Changes made from website builder e.g. Theme modify footer with XPath
and user make changes in footer then user changes will be gone on theme update
- Changes made directly in the arch of ir.ui.view in the backend.
This commit fixes that behavior by not updating views which were modified by
the user.
closesodoo/odoo#49224
X-original-commit: 9906e1d403c4e9137a0313c342a455f425e95b8e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Kishan Gajjar <kishanegajjar@gmail.com>
Before this commit, invoices do show the reference in the body of
the document, while the stock moves don't. it wasn't consistent.
After this fix, the stock move title is now displayed on mobile too.
closesodoo/odoo#49217
Task-id: 2182609
X-original-commit: 4c12aff2998c436b5bc05f119bc3d7a5f95cdfcd
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Issue
- Access rights > archive ir exports & line
- Any list view
- Select all > action > export
Access rights error
- Export all (next to import button)
Export done
Cause
Action > export does a search_read which checks
access rights
Export all is bypassing that check
Solution
Do a search_read when clicking on export all
before doing the export process
OPW-2230048
closesodoo/odoo#49203
X-original-commit: 8aa89d4c416bdcf3c7f6543f3d32006f9807c938
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
* add a `raw` computed field, though only update some of base to use
it (addons for which that makes sense can be migrated progressively)
* avoid working with base64 data when it's possible to work with the
actual data
* improve datas (base64 encoded content): should depend on bin_size
closesodoo/odoo#47212
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With website_slides installed go to website, select a course in which
the user is enrolled, try to upload a pdf
Traceback will occur because the category recordset is needed but the id
is passed to _resequence_slides
opw-2229756
closesodoo/odoo#49198
X-original-commit: 6d9b367a79d09d3d7a9dde890ca651aa09b93987
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Followup of #48896, ensures that the registry is correctly cleaned up
after the installation of the different l10n_* modules and that the
subsequent setup_models is done with the correct registry
closesodoo/odoo#49197
X-original-commit: bfd6bdcd89724f04442bbe07307177c523bed5f0
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
After cb76a0022, three more Qunit tests were found to fail randomly.
closesodoo/odoo#49190
X-original-commit: 9809c53e65059d53a9f115ab29ef02583f84bdb5
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This commit fixes timer related issues on survey flows, for both regulars
surveys and survey sessions.
The timer was unreliable in its completion by a whole second, which had not a
big impact at the user level but could make some tests fail (randomly).
Side changes from this commit:
- Reduced delays in the survey session tests to speed up testing
- Removed some timer flickering on survey views
LINKS
Task 2230526
Runbot error ID 535
closesodoo/odoo#49178
X-original-commit: 15c72aec71d42624685fb0fc9df25279c7855310
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- A tag has been added next to the title of each tab in the profile when the user come from a specific forum. The goal is to indicate to the user that the displayed content is specific to a given forum. The tag can be clicked by the user to remove the applied filter.
- Change label in edit profile page from "real name" to "name"
Task Id: 2214425
closesodoo/odoo#48665
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before 13.0, when there is no salesperson on the customer or company or
website, when a ecommerce sale order is done we get the OdooBot as
salesperson because we update partner on sale order in superuser.
In 13.0, since superuser doesn't change UID, the salesperson will be
assigned to "Public User" or the customer that create this order.
opw-2232201
closes#49141closesodoo/odoo#49161
X-original-commit: 0b6a2569920b6584652c39b3465998649fe305b4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Current Behaviour:
As Admin:
- Install timeoff and enable Multi company
- Create new company and switch to that company
- Go to timeoff > Managers > All > Allocations > Create a record
An AccessError is raised from `_onchange_type` because it try to
access `employee_ids[:1].id` and it may gives employee of another company.
Expected Behaviour:
After this commit, it will not raise the AccessError. if employee of
that company is exist then and then set on leave allocation.
so we have already compute field `employee_id`, it will gives employee
of current company.
closes odoo/odoo#49120
Taskid: 2179571
Closes: #45381
X-original-commit: 73b3d11a0b443116ce91d889397c6d85a13ca1eb
Related: odoo/enterprise#9712
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Lucas Lefèvre