- 02 Oct, 2019 2 commits
-
-
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 !945
-
- 30 Sep, 2019 10 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
-
- 29 Sep, 2019 1 commit
-
-
Roque authored
Fixes, refactoring, details and more app migrations. /reviewed-on nexedi/erp5!916
-
- 27 Sep, 2019 10 commits
-
-
Roque authored
-
Roque authored
-
Roque authored
-
Roque authored
-
Roque authored
-
Xiaowu Zhang authored
This reverts commit b6b517ee. which impacts "Time Table Line" and "Public Holiday Line" portal tyle I need to check more portal type before remerge it
-
Roque authored
-
Sebastien Robin authored
-
Ivan Tyagov authored
-
Jérome Perrin authored
This field was only displayed if any of these was enabled: - by function analytics - by project analytics - by category analytics and it allows requesting reports per function, project, categories and section. The problem is that if any analytics was explicitly enabled, we never allow users to get a break down by section. Always display the field, so that user can always select section. This does not make much sense when there's only one section though. /reviewed-on nexedi/erp5!939
-
- 26 Sep, 2019 10 commits
-
-
Roque authored
-
Kazuhiko Shiozaki authored
-
Jérome Perrin authored
Our patched MySQLDA assumes that DATE and DATETIME columns are in UTC, but the TIMESTAMP columns are using mysql's time_zone variable, which defaults to mysql server system timezone. Set time_zone session variable at the beginning of each connection so that TIMESTAMP columns are also UTC.
-
Jérome Perrin authored
This API is not supposed to take into account security, unrestrictedSearchResults is usually a bit faster
-
Jérome Perrin authored
At this point, the alarm is active, but active process for this activity was not created yet. By passing include_active, the latest active process will be returned (not the previous one) Honnestly, not sure if this falls into workaround or non documented normal use case for include_active=True.
-
Jérome Perrin authored
last_active_process.getStartDate() is in Zope timezone, we should not just pass a string representation to catalog but pass a DateTime instance instead, to let catalog convert the date to UTC (because catalog tables have UTC dates). Where it gets more complicated is that unlike all DATETIME columns in catalog that are UTC, indexation_timestamp is a TIMESTAMP column, which depend on MySQL timezone settings. This also depend assume that MySQL is configured with an UTC timezone.
-
Jérome Perrin authored
-
Jérome Perrin authored
no need to do this magic with user_id if we are using an organisation
-
Jérome Perrin authored
-
Jérome Perrin authored
to prevent a warning Also reindent long too long line
-
- 25 Sep, 2019 5 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Romain Courteaud authored
-
Romain Courteaud authored
-
Romain Courteaud authored
-