- 02 Oct, 2019 27 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
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 !938
-
Jérome Perrin authored
This adds a new field on Test Suite Repository to configure a "gitlab connector". If this is set, then the commit from this repository will be annotated with the test status (failed or success). Gitlab uses these annotations to show that status on the merge request. At the same time, fix a few minor problems on `erp5_test_result`. /reviewed-on nexedi/erp5!924
-
Jérome Perrin authored
The way consistency check select documents to check at each run when running incremental mode, consistency seems to have issues which leads to documents not checked sometimes. I noticed two reasons: * When Zope runs with a timezone that is not `UTC`, the date comparison to find new documents compares a date in zope local timezone with a timestamp in mysql timezone. First fix is to pass a date to catalog, so that catalog convert it to the catalog timezone (it's a mistake to pass a date as string when using catalog programmatically). Second fix seem that we seem to need to configure mariadb to use `UTC` by default. * `alarm.getLastActiveProcess` does not return the latest active process when alarm is executing `activeSense` so we need to pass `include_active=True` in this case. /reviewed-on nexedi/erp5!537
-
Jérome Perrin authored
Because unlike `getFoo()`, `getProperty('foo')` does not checks the permission defined on the accessor, when a form contain a `my_foo` field, the property would be displayed to the user who can view the form, even if the user does not actually have the permission to get this property. This because getter for default value of fields uses getProperty ( [here](https://lab.nexedi.com/nexedi/erp5/blob/58d4ab8efef748f522b3eaaecba3dc1133c99e72/product/ERP5Form/Form.py#L275) ). These changes modify behavior of `getProperty`, so that it enforces read permission security of properties and raise when user does not have permission to access properties. Some notes about implementation: * `getProperty` now becomes a bit slower, but it was incorrect before, so I guess it's inevitable. * some efforts have been made to keep the impact on performance minimal. This uses the same approach of in `edit` of computing the set of restricted properties and using `guarded_getattr` only on these properties and using `getattr` on non-restricted properties. The computation of this set was moved to dynamic class generation time and as a result, `edit` becomes a bit faster. * the `expectedFailure` part of `test_PropertySheetSecurityOnAccessors` was moved to another test, but I'm not even sure we want to support this (read-protecting properties with default write permission) as, to me, such configuration does not make much sense. * new performance tests were added. I don't know what to use as min/max values so I just used something that should pass. * implementation for `getProperty('*_list')` was changed a lot, I have no idea why this was getting the method on the class and passing self as first argument. Now it we just get method on the instance, like we do for single properties. /reviewed-on nexedi/erp5!181
-
- 01 Oct, 2019 2 commits
-
-
Ivan Tyagov authored
-
Ivan Tyagov authored
all repository list which will cause a mismatch between test suite class location and repository. /reviewed-on nexedi/erp5!945
-
- 30 Sep, 2019 11 commits
-
-
Julien Muchembled authored
/reviewed-on nexedi/erp5!944
-
Roque authored
-
Roque authored
-
Roque authored
-
Roque authored
bt
-
Julien Muchembled authored
-
Roque authored
This reverts merge request !916 Merged by mistake /reviewed-on nexedi/erp5!942
-
Sebastien Robin authored
This reverts commit f9f020e3.
-
Arnaud Fontaine authored
Assuming that the test database already exists and 'movement' table already contains data (from past execution for example), on '--save' before this commit: 1. Create a new ERP5 Site: 1. Install erp5_mysql_innodb_catalog. 2. Call ERP5Site_reindexAll(clear_catalog=True) (from ERP5Generator.setupIndex()). => At this point, erp5_mysql_innodb_catalog tables are recreated. 2. Install erp5_movement_table_catalog or any bt5 adding a new SQL table. => This does not recreate the table and leave the existing data as it is. 3. Dump MySQL database to dump.sql. => dump.sql contains 'INSERT INTO' for 'movement' table *before* this '--save'. This fixes random customer Unit Tests failures on SQL queries accessing 'movement' table directly and getting {non-existing,past executions} Movements.
-
Yusei Tahara authored
-
Nicolas Wavrant authored
Before the change testing the value set for category membership, "p1.setCareerSubordination(o1)" was not raising, making this test useless in reality. With the change, this now raises, but with a different message.
-