Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.
For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.
With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.
It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.
Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature. This allows us to increase the global
timeout for the js test suite without fear!
Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community. The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.
What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
action
- the tour is broken.
The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive. This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.
The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous
Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.
In saas 11.2 a _message_log shortcut has been added to log notes. This
method should have the same behavior when author has no email. Currently
there is a crash when trying to encode its email. After this commit an
exceptions is raised like classic post.
This commit is related to task ID 1823990 .
Commit 0cd656b5af improved onboarding of mass mailing application. Notably
mailing domain computation has been improved. However rewriting has not been
done correctly as there were strange formatting and encoding. This commit
fixes the issue and correctly uses a list to format a domain like expected.
This commit is related to task Id 1831211. Closes#23883 .
Query count for some mail tests is not always the same for a given test.
This leads notably to runbot being randomly red although there is no real
error. This commit lessen the issue of having red runbot or wrongly
incremented tests by using the recently-introduced margin parameter on
performance tests.
Some work is still ongoing to find why some tests are not completely
reproducible. In the meantime let us have some warnings instead of errors.
Purpose of this commit is to avoid errors for some performance tests that
have a slightly variable number of queries. Indeed some tests in test_mail
module vary of 1 or 2 queries due to a behavior still not found that does
not seem deterministic.
This should not be considered as a real error, but should not be considered
as completely valid. This is why a margin is accepted in some tests that
will raise a warning instead of an error. This warning tells people to
check if they have increased the query counter or if it is due to a random
effect in query count.
This reverts commit d565596868. Indeed whole purpose of having tests
based on query counters is to fail every time query count is greater than
expected. Query count could be greater than expected because
* either it is required by a bug fix or a feature and tests should be
updated accordingly in the same commit;
* either implementation can be improved to avoid or lessen query count
impact and code should be updated accordingly;
* either we have some random queries due to nondeterministic behavior;
It seems purpose of the commit was to solve the third case. However we think
hiding first two cases can be dangerous compared to solving third case.
Moreover having a threshold of 10% does not make sense. It means some complex
test case could take 30 queries more without being noticed. Some tests could
fail after several commits adding queries and finding them afterwards could
be complicated.
Another solution based on flagging some tests that have a small random
behavior will come soon.
This commit format the display_name of sale.order.line,
without context key.
The webclient trigger the name_search with context
key, but display the field without it.
So on task form view, when searching an SO line, user
will see 'SO0001 - my product' in its dropdown, but the
complete SO line description when saving.
This commit proposes, in aggreement with AL and FP, to
a global (and non conditionnal) format, since it seems
task form view is the only one place requiring the SO
line name_get.
self is a rml_parse instance, not a BaseModel
create new environment to call ORM methods
prevent crash when calling formatLang on a RML report
Closes#24068
When not draft, the partner_id field is readonly and cannot be modified
anyway, but it makes the form invalid, so form buttons cannot be used,
e.g. to access the journal items, etc.
When the `partner_id` is not set (it is not required at the model
level), we can still compute the default destination account based on
the company chart of account configuration.
This is necessary to allow creating "customer" or "supplier" payments without
selecting a specific partner.
Commit d39856db prevents crawler to crawl and index blog tag URL which could
lead to possibly millions of URLs combinaison.
Still, it would crawl (but not index) second level of tags combinaison.
This commit ensure that crawling is prevented when already one tag on the URL.
Before this commit, when some records were created from an `onchange`,
we have the following weird behaviour:
Suppose that this record has some required fields that are empty.
When we click on this record, then somewhere else, the record
disappears from the list.
This is because the records contains invalid fields, and it is wrongfully
assuming that the record to be discarded comes from "Add an item".
A previous commit [1] fixed a bit this issue with `default_get`, but since
it relied on a fragile heuristic, we decide to apply the correct fix with
this commit.
[1] https://github.com/odoo/odoo/commit/b09f0c99be2b13d33986414485556d87da186d65
Before this commit:
If a blog had multiple tags on the page, the crawler would click on every one
of them one after another until every tags combination got crawled.
With a lot of tags, this could result in million of URLs.
Now, we prevent URLs with more than one tag to be crawled.
Eg: With tags 'A', 'B', C':
/A
/A/B
/A/C
/A/B/C
/A/C/B
/B
/B/A
/B/C
/B/A/C
/B/C/A
/C
/C/A
/C/B
/C/A/B
/C/B/A
Create a hr.attendant in a stage where a mail template is present.
Fill the email field as: Name Surname <name@surname.com>
Before this commit:
- the created partner's email has been rendered as name@surname.com>
- the email failed to be sended because of this
This was because Jinja rendered that snippet escaping the special characters
Putting a 'pipe' safe in the snippet does the trick
After this commit:
both the partner and the email are created successfuly
OPW 1830739
closes#24059
Also when there is both a docstring and directive-level content put
the docstring first. That seems to match what Sphinx's autodoc does
and looks less odd.
Possible future improvement: a parameter to suppress the docstring?
Possibly a way to reorder the non-docstring content (e.g. members
documentation)?
- Install Website
- Load the 'Norwegian Bokmål' translation, and choose to translate the
website
- Logout
When accessing the website, the language displayed is not consistent to
the browser language.
1. `no` shows homepage in `nb_NO` (Firefox only) => expected since
Bokmål is the main language in Norway
2. `nb` shows homepage in `en_US` => unexpected
3. `nn` shows homepage in `en_US` => expected since 'Norwegian Nynorsk'
is not a language available (this will be the topic of another PR)
The issues comes from Babel's side, since `nb` is not in the
`LOCALE_ALIASES` while `no` is. We monkey-patch the value to avoid this
while Babel is corrected.
opw-1827258
* add UUIDs to XID sections (4 bytes / 8 hex digits) so it's not
necessary to handle collisions & add a fallback generator
* use COPY for performances over executemany: executemany just
performs an implicit loop on all statements (in psycopg2)
* ~pure SQL was possible:
INSERT INTO ir_model_data (module, model, name, res_id)
SELECT
'__export__',
'{model}',
'{table}_' || A.id || '_' || uuid_generate_v4(),
A.id
FROM {table} A
LEFT JOIN ir_model_data B
ON A.id = B.res_id AND B.model = %s
WHERE B.res_id IS NULL;
but would have required installing pg extensions (problematic
especially in stable) and performances are about the same as
the COPY version
task 36343
Fixes#22493
Using `break` when looping over a recordset in a compute method could
have side effects. Computed field are computed in batch, according to
the order of the recordset, the value may only be computed correctly for
some records
related to rev c493569866
opw-1833347
- Create a vendor bill, save and validate
- Duplicate the bill, save
- Click on "Create"
A customer invoice is created, while the user expects a vendor bill.
After duplication, the new record is loaded but the context is lost.
Since the default value for the invoice type is based on the context key
`type`, a loss of context leads to an incorrect invoice type.
opw-1826453
Co-authored-by: Géry Debongnie <ged@odoo.com>
Géry Debongnie