- 04 Sep, 2020 3 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
- 03 Sep, 2020 5 commits
-
-
Jérome Perrin authored
(and translate this to french as well)
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
Since 206a8e25 (erp5_officejs: new OfficeJS Slideshow Editor application, 2020-07-06) this test runs with erp5_run_my_doc installed, and the first export action for Web Page is no longer "Export as SlideShow" but "Export as Chapter". This is an action which is here since a long time in erp5_run_my_doc, but since erp5_run_my_doc was not installed in this test it was not impacting this test. Adjust the tests so that they don't assume that the first export action is "Export as SlideShow" but are more independent on which is the first action. Also, all actions have a new index, so places where we select the action by index no longer work. Instead of updating the indexes, select by label which should be more future proof.
-
Nicolas Wavrant authored
Mathematically, 1/(x^y) is the same as x^-y, and despite float caculation the results is usually precise enough : > Math.pow(10, -5) 0.00001 I tested this on few platforms : firefox 68.12, firefox 77.0, node v10.19.0 Unfortunately on (recent ?) chromes : > Math.pow(10, -5) 0.000009999999999999999 Which is a horrible value to use as step (and it prevents the form submission as most floats the user will enter won't match the init value * x * the step. For an unknown reason, I get a more consistent result using the formula "1 / Math.pow(10, 5)", which returns 0.00001 on all tested platforms. If we find more issues in the future, we maybe should try building the step using strings. Using strings for manipulating floats is in reality widespread, and many languages do so to round floats (ie: https://github.com/python/cpython/blob/4a97b1517a6b5ff22e2984b677a680b07ff0ce11/Objects/floatobject.c#L925) The precision of 5 is not random-picked, it is the minimum precision needed to manipulate prices for currencies with 2 digits, like euros.
-
- 02 Sep, 2020 15 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
When portal_contributions.PUT() is called, Document was not converted (and `base_data` was not set) by document_conversion_interaction_workflow as this was only done on _set{Data,File}() and OFS.Image.update_data() sets `data` property directly. This fixes failures on testWebDavSupport.test_GET_on_{contributionTool,document} with erp5_full_text_*_catalog bt5 installed: SQLCatalog_deferFullTextIndexActivity Activity failing with `NotConvertedError` when trying to convert to txt as `base_data` is not set.
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
ZODB Components: erp5_trade: Migrate TestOrder{Mixin} and all Unit Tests inheriting from these classes. Also, Split testInvoice to a Module Component in erp5_invoicing for Mixins used by several other tests and Test Component in erp5_simplified_invoicing (initially everything was migrated to erp5_invoicing but this does not work as Alarm_buildInvoice is different in simplified and advanced invoicing).
-
Arnaud Fontaine authored
efd71291 added on erp5_invoicing a test dependency on erp5_advanced_invoicing. However, testRule for example uses erp5_invoicing but not erp5_advanced_invoicing so this would not work. Moreover, erp5_{simplified,advanced}_invoicing enhance erp5_invoicing by providing a container for Invoice Line so to match real world use cases it is better to have two CodingStyle tests: one checking erp5_invoicing+erp5_simplified_invoicing and the other one erp5_invoicing+erp5_advanced_invoicing. Also, fix CodingStyle issues on erp5_advanced_invoicing.
-
Romain Courteaud authored
-
Jérome Perrin authored
This reverts commit bc67c2c4. This is seem to stall testFunctionalAdvancedECommerce with this error: Module script, line 5, in Workflow_ensureUserId - <PythonScript at /erp5_portal_7f1517681f85de9695ca475d69c4d66f/portal_workflow/login_interaction_workflow/scripts/Workflow_ensureUserId> - Line 5 user = state_change['object'].getParentValue() Module AccessControl.ZopeGuards, line 87, in guarded_getitem if getSecurityManager().validate(object, object, None, v): Unauthorized: You are not allowed to access '2' in this context let's revert for now, we'll re-do this with more tests.
-
Romain Courteaud authored
New dependencies were added in 206a8e25
-
- 01 Sep, 2020 9 commits
-
-
Ludovic Kiefer authored
-
Ludovic Kiefer authored
-
Ludovic Kiefer authored
-
Ludovic Kiefer authored
-
Ludovic Kiefer authored
-
Ludovic Kiefer authored
-
Ludovic Kiefer authored
-
Romain Courteaud authored
See nexedi/jio@24b938cb
-
Romain Courteaud authored
-
- 31 Aug, 2020 8 commits
-
-
Vincent Pelletier authored
Should fix most of the cases where reloading components cause breakage. There is still a race condition between a transaction's cache being actually flushed (which can only happen at transaction boundaries) and another transaction doing the actual class reload, which will immediately affect all the started transactions in the same process.
-
Jérome Perrin authored
Once a portal type class became available again, instances of this classes should no longer be broken and can be modified again
-
Jérome Perrin authored
Some other types (Gadget Type) are currently lacking the interaction workflow which resets the dynamic classes.
-
Jérome Perrin authored
-
Jérome Perrin authored
Persons created before the introduction of ERP5 Login and user_id will only have a user_id after migration if they were already user before migration, otherwise they will not have a user_id and creating assignments and ERP5 Login for this person creates a user which can not log in the system. To make it possible for these persons to login anyway, we ensure person has a user id when validating a login
-
Jérome Perrin authored
while setting an initial user id should be allowed for any user which can create a person, changing an already set user id can have security implications, so we protect it with a more strict permission
-
Jérome Perrin authored
user_id are technical things that should not be displayed to users. In the case of tokens, for now we show "something that's not user id / not the token secret". That's not ideal but as far as I know whe don't really have use cases of tokens to show a page where user caption would be displayed.
-
Jérome Perrin authored
Person.setUserId is heavy, it serializes person module to prevent concurrency, but in some cases we the risk of having duplicate user ids is under control, so we don't want to pay the performance price. See merge request nexedi/erp5!1242
-