The 'Configure Variant' button doesn't show any relevant information in
case of a product variant. It is only useful for a product template.
opw-2229881
closesodoo/odoo#49059
X-original-commit: d57331f5403159692591fe75c6e8e4f1e9ac6b02
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fix regression introduced with e0ed7b12ca
Issue without current commit:
When doing `abort` next updates from the bus are only received after the normal
timeout, which makes the interface unresponsive to updates during that amount of
time.
`abort` is for example called during `addChannel`, where it is specifically
documented that new updates are to be received immediately.
closesodoo/odoo#49355
X-original-commit: 888610e5e07794e000ef27edcb075cb45c1e2ccc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Create a new survey 'Test Survey';
- Add a section 'S1';
- Add a multiple lines text box question 'Q1';
- Add a section 'S2';
- Add a section 'S3';
- Don't move any of the section or question to avoid changing the
sequences, for the moment all the sequences are equal to 10;
- Change the survey layout to 'One page per section';
- Save the survey;
- Test the survey;
- Fill the 'Q1';
- Go to the last page and Submit the survey;
- Review your answers.
Before this commit, the question is empty, this occurs because the
question page_id is not set, in _compute_page_id, the sequence of the
question should be bigger than the question of the page (in this case
the section).
Now, the _compute_page_id was change to take into account the case when
the question has the same sequence as the page (section).
opw-2222045
closesodoo/odoo#49366
X-original-commit: 99f35075e3d1e418e096a29b7440152e746a1cd5
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Typo was preventing create multi to multi create.
closesodoo/odoo#49352
X-original-commit: 2c65b7283a37b8c44d91e01112843882098bfc7b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install Projects
- Change language
- Check projects
There is a word "X Tasks" which is not
translated.
Cause
This is a model attribute which is not
translatable. It can have any value
"Tasks" is not mandatory.
Solution
Make it translatable
OPW-2233084
closesodoo/odoo#49346
X-original-commit: 587160376237a12a9174ad5c4578a273b48ca489
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
SIPS sometimes send empty notifications. I have been unable to find out
why or to reproduce the issue; it seems to be linked to a delay on their
end since these notifications usually arrive after a customer is
redirected back to Odoo (at least on their test account).
I'd rather log a warning for those cases (since nothing is wrong on
Odoo's side, there's just no info to act upon) instead of a full
traceback.
closesodoo/odoo#49335
X-original-commit: 100ef1bdb7b90edbeccfa6cd10297acb824b8083
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
SIPS date format can be somewhat variable, some sanitation is required
before using the data raw for the ORM.
opw-2224926
X-original-commit: 620e987f326d6da7c3a9b2c1aca7bff16d9ce6c4
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Before this commit, the test assets were called with a `t-call-assets` and contained
themselves some other `t-call-assets` to the back-end assets. According to the current
specification, having nested `t-call-assets` will result in a compilation of the
lower levels regardless of the current debugging mode.
Now, the test bundles (desktop & mobile) have been arranged so that their `t-call-assets`
are all called on the same level.
closesodoo/odoo#49306
Related: odoo/enterprise#9797
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, When using the "Generate a Payment Link" button under the
Action menu (model=account.move), the last step of the flow is "back
to my account" , But this button doesn't generate any actions. If you
click on it, nothing happens because the button "Back to My Account"
was overlap by the payment logo.
So in this commit, we add fix the layout and use the row so the
elements do not ovelap each other.
Task-Id : 2197705
closes odoo/odoo#49012
Closes: #49012
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Install eCommerce
- Create a SO
- Add a section
- Add a note with big text
- Customer Preview
The word are not broken correctly
Cause
We added a break-all to prevent
long URL/words overflow.
Solution
Use work-break: break-word which
will break the word correctly.
Use overflow-wrap/word-wrap
(same usage but we need both
to ensure browsers compatibility)
which makes sure the long string
will wrap and not bust out of the
container
OPW-2222814
closesodoo/odoo#49321
X-original-commit: 0754590abe1b84874aa2a685fea5cbf2569383e4
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN
- Create a SO with P and confirm it
- Print the delivery slip
Bug:
The internal note NI was displayed on the delivery slip.
opw:2227613
closesodoo/odoo#49277
X-original-commit: 038221f3180a7a8888503553dbb5eb57875ef3a6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Create a product with UoM Dozens
Sold 5x via POS
Go to the product page
The smart button does not reflect the correct quantity
(0.42 instead of 5).
Fixing by editing the SQL query, the POS already provide
the correct quantity of sold goods as it is not possible
to change the UoM. This aim to match the behavior of sale (where
is necessary to account for possible differences between the uom
reported on the sale order line and the one specified in the product
page)
opw-2227482
closesodoo/odoo#49313
X-original-commit: 7af831fe47005c6a7724d8d28bf3d045a75f0f09
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Filter out section and notes from the invoice status computation.
opw-2233550
closesodoo/odoo#49301
X-original-commit: 55d3c59235cadb70aa9206eaec7ff1e4631fb019
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.
However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:
* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
lazy, which might have worked except
*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).
This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.
This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.
Related to task 2170343
closesodoo/odoo#49286
X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Update information in JS doc for 13.0 (replace control panel mixin with the hasControlPanel attribute).
closesodoo/odoo#49291
X-original-commit: 0d46f49a00c6ecb62725ab97c1f337d1b0666852
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
1/ Recurring Events
==============
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).
2/ Synchronization with Google Calendar
==============
This commit refactors calendar synchronization between Odoo and Google after the
main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
- New way of synchronizing resources efficiently[1]
Incremental sync is performed repeatedly and updates Odoo with all the changes that
happened ever since the previous sync. Each time, Odoo provides the previous sync
token it obtained from Google and stores the new sync token from the response.
- Event metadata[2]
Ability to set hidden key-value pairs with an event, called extended properties.
These extended properties are used to store the related odoo event id and the Odoo
owner id (see known limitations)
### Known limitations
- Let A and B be two new users (no tokens available). A creates an event in Odoo and
invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar
account and synchronizes his calendar. We cannot send the event to A's calendar since we
don't have any access to his Google Calendar. Hence the event his sent to B's calendar.
This leads to data de-synchronisation: The owner is A in Odoo but B in Google.
The "real" owner (user A) is stored in the Google event's metadata to be able to
reconcile the owner for following synchronizations.
- Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B
be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the
event in his calendar). If A creates an event in Odoo and invites B. The event is synced
to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his
Google Calendar.
Task 2126717
PR #42031
PR Enterprise https://github.com/odoo/enterprise/pull/8006
[1] https://developers.google.com/calendar/v3/sync
[2] https://developers.google.com/calendar/extended-properties
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
To change your Google Calendar account, the authentication tokens must be set to `False`.
But doing so leaves synchronized events in the database.
This commit adds a wizard to handle those existing events as the user wants.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit refactors calendar synchronization between Odoo and Google after the
main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
- New way of synchronizing resources efficiently[1]
Incremental sync is performed repeatedly and updates Odoo with all the changes that
happened ever since the previous sync. Each time, Odoo provides the previous sync
token it obtained from Google and stores the new sync token from the response.
- Event metadata[2]
Ability to set hidden key-value pairs with an event, called extended properties.
These extended properties are used to store the related odoo event id and the Odoo
owner id (see known limitations)
Known limitations
=================
- Let A and B be two new users (no tokens available). A creates an event in Odoo and
invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar
account and synchronizes his calendar. We cannot send the event to A's calendar since we
don't have any access to his Google Calendar. Hence the event his sent to B's calendar.
This leads to data de-synchronisation: The owner is A in Odoo but B in Google.
The "real" owner (user A) is stored in the Google event's metadata to be able to
reconcile the owner for following synchronizations.
- Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B
be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the
event in his calendar). If A creates an event in Odoo and invites B. The event is synced
to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his
Google Calendar.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
[1] https://developers.google.com/calendar/v3/sync
[2] https://developers.google.com/calendar/extended-properties
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
Since 5952928b42, the python3-mock debian package is removed from the
Dockerfile used to build the Debian package. This prevent the Odoo
Debian package to be built.
The python3-mock debian package has an inderect dependency on
python3-setuptools which is necessary to build the package.
With this commit, the dependency is explicitely set in the Dockerfile.
closesodoo/odoo#49278
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Forgot to add the vcss number on some s_title snippets.
task-2233240
closesodoo/odoo#49263
X-original-commit: 7fb36621665c739c7c91395b2bdaee12f908c88c
Related: odoo/enterprise#9773
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
Nicolas Martinelli