- 03 Nov, 2017 10 commits
-
-
Nicolas Wavrant authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
In order to use setting in multiple application on same domain.
-
Vincent Bechu authored
/reviewed-on nexedi/erp5!474
-
Łukasz Nowak authored
-
Łukasz Nowak authored
createTestResult is called also without node_title, and it shall allow execution in such case.
-
Rafael Monnerat authored
-
Vincent Pelletier authored
Such parameter can produce undesired conditions (ex: FROM catalog as node, ... WHERE node.uid > 0 AND ...) causing poor performance. So avoid introducing this parameter when its value is empty.
-
- 02 Nov, 2017 14 commits
-
-
Łukasz Nowak authored
There is no need for any client to call tool directly.
-
Łukasz Nowak authored
This results with calling correct methods on the server.
-
Łukasz Nowak authored
This results with calling correct methods on the server.
-
Łukasz Nowak authored
The module is to access Distributor not the whole tool.
-
Łukasz Nowak authored
This results with calling correct methods on the server.
-
Łukasz Nowak authored
-
Łukasz Nowak authored
Since distributor is used, tests need adaptation: * created default Test Node and Test Suite, required by Distributor.createTestResult * adapted _createTestResult to reuse created documents * adapted some tests in order to reuse created documents
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
Łukasz Nowak authored
-
Cédric Le Ninivin authored
-
Romain Courteaud authored
-
Jérome Perrin authored
Several changes to `Item_getTrackingList`. My original goal was to fix a problem happening when users sort the listbox by `source_title` column. Because catalog understands it, it adds a join condition which would filter movements not "directly" having a source (ie. having a source by acquisition from parent). Then I realized this script was doing a lots of catalog queries that are done in a most efficient/safe way on the brain, so I switched to this. Also add a few missing tests. I did not add test for my original problem, because the real fix is that listbox should not declare `source_title` to be a sortable column, because this method does not support it. /reviewed-on nexedi/erp5!469
-
- 01 Nov, 2017 1 commit
-
-
Jérome Perrin authored
-
- 31 Oct, 2017 11 commits
-
-
Romain Courteaud authored
-
Sebastien Robin authored
-
Sebastien Robin authored
-
Romain Courteaud authored
-
Romain Courteaud authored
-
Romain Courteaud authored
-
Romain Courteaud authored
rJS gadget uses text content as value
-
Romain Courteaud authored
Keep compatibility.
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Nicolas Wavrant authored
Modules should have the business_application base category set in order to classify them. Normally, the code helper set this category on module creation (https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/bootstrap/erp5_core/SkinTemplateItem/portal_skins/erp5_core/ERP5Site_createModule.py#L15), but it is often forgotten to commit it (as it should be defined explicitely in template_portal_type_base_category_list's bt5 property. This commit tries to fix it globally in all bt5s, using a script : https://lab.nexedi.com/snippets/259. I have tried to respect file modes, file encoding, alphabetical ordering, and "\No newline at end of file" issue in order to not generate useless diffs when other people will commit on these files later. @jerome , @vpelletier , @kazuhiko , @seb : could you have a check to the file formats to tell me if anything is wrong ? /reviewed-on nexedi/erp5!465
-
- 30 Oct, 2017 4 commits
-
-
Nicolas Wavrant authored
All Tickets portal types don't use the same workflow variable (validation_state/simulation_state). By retrieving first the correct workflow variable, we can then deduce the correct getter to access to each object workflow's state /reviewed-on !418
-
Nicolas Wavrant authored
It is a common (CRM principally) use case to search for Organisations using official identifying unique codes, as the registration code or the VAT code. There is currently no way in ERP5 to look for entities using these unique codes, as they are not-generic enough to be indexed. For the same reason, creating a new table(s) to index Entities' identifiers may give something too blured to reach a consensus on. In my opinion fulltext search is a good solution for this case, and it shouldn't create compability issues for current projects. If it is thought necessary, I can also add the Social Security Code (for Organisations/Persons) in the searchable text properties, but it is a more complicated topic as it isn't a public information. @nexedi 's project managers, what are your thoughts on it ? /reviewed-on !463
-
Vincent Bechu authored
/reviewed-on nexedi/erp5!473
-
Tomáš Peterka authored
/reviewed-on nexedi/erp5!472
-