- 03 Oct, 2019 14 commits
-
-
Klaus Wölfel authored
-
Klaus Wölfel authored
-
Klaus Wölfel authored
-
Klaus Wölfel authored
-
Klaus Wölfel authored
-
Klaus Wölfel authored
-
Klaus Wölfel authored
-
Rafael Monnerat authored
(cherry picked from commit eed6ff24799a73a63327152a662669ba3ecfc391)
-
Xiaowu Zhang authored
-
Rafael Monnerat authored
Added aggregate item and item creations actions on new portal types. (cherry picked from commit a32a565f2e4921c087803aa526bca8c853e18887) Conflicts: bt5/erp5_item/bt/revision
-
Rafael Monnerat authored
Introduce temp_object parameter on builder.build() and propagate it over until the newContent() calls. This change allow use create Temporary Documents intestead real ones, like a "preview". (cherry picked from commit 959776ce50c2e7ee2b8f9945ec91a2e0fbe08619) Conflicts: product/ERP5/Document/SimulatedDeliveryBuilder.py
-
Jérome Perrin authored
This module is not sorted, we cannot just do assertions based on line index. Instead we do two different approaches: - When there is only one "empty" draft transaction, we check locate the line based on the state cell and then check each cell relatively to that first xpath - After we had a second draft, we just check that we have two lines matching each cell predicate.
-
Jérome Perrin authored
Sometimes test fail we don't have any information about what the problem was. Using the same technique of turning a promise into "a function called several times until it returns true or false", we can get rejection failures in the selenium error message.
-
Jérome Perrin authored
The term (used for example on HTTPExchange_view/my_follow_up_title ) is "Follow-up". This will fix testNamingConventions failure.
-
- 02 Oct, 2019 26 commits
-
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
so that user can overwrite easier in html
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
For options: ${WebPage_insertFollowUpCostEffortReport} ${WebPage_insertFollowUpCostEffortDetailReport} script's name is changed to Base_generateCostEffortReportContent and parameter is changed also
-
Ivan Tyagov authored
template for Scalability tests.
-
Georgios Dagkakis authored
It was found useful in cases, so good to have it available
-
Sebastien Robin authored
Exactly like prices and other properties, it is useful for some projects to define different descriptions depending if we are doing sales or purchases
-
Romain Courteaud authored
[erp5_core] Return 400 status code when updating a dialog
-
Romain Courteaud authored
-
Romain Courteaud authored
-
Nicolas Wavrant authored
Also, this prevents logging the same information on every listbox load.
-
Nicolas Wavrant authored
This merge request aims to prevent programming errors by raising instead of silently doing nothing (which is a source of bugs). Currently, if an object as category property for a category "category", 2 families of setters were created : 1. The string setter, following the format ```_setCategory``` and taking a relative URL as the argument. 2. The value setter, following the format ```_setCategoryValue``` and taking an object as the argument. The issue is that developers may pass the wrong argument to one of these functions, having for consequences : 1. For case (1), if an object is passed, the code would silently do nothing : nothing is set as relation, but the code doesn't fail. This is the worst case. 2. For the second case, passing a relative URL to ```_setCategoryValue``` would "work" (in the meaning the relation is set to the correct object). This may sound like a feature, but in my opinion it is confusing given the way ERP5 developers apprehend these setters nowadays. For case 1, a test is existing that an exception is raised, but due to coding error the feature disappeared and no one noticed : https://lab.nexedi.com/Nicolas/erp5/blob/b3ed2210ed6b30390b901c8620de6eafcc27a574/product/CMFCategory/tests/testCMFCategory.py#L810-815 For case 2, compatibility code exists in the underlying function ```_setValue``` : https://lab.nexedi.com/Nicolas/erp5/blob/b3ed2210ed6b30390b901c8620de6eafcc27a574/product/ERP5Type/Base.py#L1840-1842 In this MR, the exception caused by case (1) has been restored (so now it fails loudly). Case (2) has been deprecated, in order to keep backward compatibility. I have run the tests with the ```DeprecationWarning``` raising an error instead of just a warning, and fixed the code were the setters weren't used correctly. Ideally, tests should always run with this ```DeprecationWarning``` being a real error so both cases crash loudly. This won't be part of this Merge Request. /reviewed-on nexedi/erp5!938
-