- 21 Aug, 2017 17 commits
-
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Vincent Bechu authored
-
Boxiang Sun authored
-
Boxiang Sun authored
The keys in the `count_by_state` dict in SupportRequest_getSupportRequestStatisticsAsJson.py was hardcoded in previous version. This commit can add the keys to the dict dynamically according to the states of Support Request. Thus the code can still work if there has new state added to Support Request.
-
Boxiang Sun authored
Users may upload PDF files when they submit comment under a support request. This commit allow user to view the PDF file after they upload it.
-
Boxiang Sun authored
The 'form_view_discussable' allow user to visit the 'OfficeJS View' in classic ERP5 interface. This was copied from 'form_view' and the 'discussable' part is not implemented in this page template.
-
- 17 Aug, 2017 1 commit
-
-
Tristan Cavelier authored
-
- 16 Aug, 2017 5 commits
-
-
Cédric Le Ninivin authored
-
Cédric Le Ninivin authored
-
Nicolas Wavrant authored
In the case the CTP is for a refund
-
Cédric Le Ninivin authored
-
Cédric Le Ninivin authored
-
- 11 Aug, 2017 5 commits
-
-
Alain Takoudjou authored
First commit of monitoring renderjs application in erp5. Monitoring is a render js application which uses jio to sync slapos instance promises result and display on web browser. /reviewed-on nexedi/erp5!347
-
Sebastien Robin authored
-
Vincent Bechu authored
-
Sebastien Robin authored
only change ids of gadget (reference and content already changed)
-
Sebastien Robin authored
make all graph gadget names like gadget_field_graph_plotly.html/js . We should not have any more "officejs" or "erp5" in name, since theses gadgets could be used for any kind of application.
-
- 10 Aug, 2017 7 commits
-
-
Julien Muchembled authored
A Form is rendered by assuming the REQUEST is clean and first set 'here' as the context. Then there may be listboxes with rely on 'here' and set 'cell' temporarily. At last, for easier configuration of listbox fields, 'cell' has precedence over 'here' when rendering (in particular since commit 4fa84233). Based on this, the only sane solution is to - clean up the REQUEST (remove 'here' and 'cell') - render the FormBox in the new context (which sets 'here'): inside a ListBox, the context is the cell - restore 'here' and 'cell' as they were Which allows FormBox/ListBox inside FormBox/ListBox, recursively (but obviously no ListBox inside ListBox). The previous code didn't work in the following case: - a Order Line and Packing List Line having an identical tab - the left pane for Order Line information - the other for Packing List Line information (-> empty when there's no related PL) - a listbox (with subobjects of the PL line) Which is implemented as follows: - a Form for the left pane - a Form for the Packing List Line, with a FormBox (to display Order information) and a ListBox - the Form for the Order Line only has a FormBox, that uses 1 of the 2 other Forms depending on the presence of a PL (if there's one, it's rendered in the context of the PL) -> FormBox(FormBox, ListBox) As you can see, FormBox is used here to factorize forms. Without this patch: - the outter FormBox crashed on `del REQUEST.other['cell']` - the inner FormBox was rendered with a wrong 'cell' Another change is to pass the field & REQUEST to the context method.
-
Vincent Bechu authored
/reviewed-on !346
-
Vincent Bechu authored
-
Sebastien Robin authored
This way it would be even more easier to use graphs, and we avoid inventing additional API. Method updateConfiguration has been removed, it is possible to call render several times if needed.
-
Jérome Perrin authored
Following up !308 , these are a batch of changes to fix coding style in `erp5_accounting` as reported by pylint and `Products.ERP5Type.CodingStyle`. Also, calls to `portal_catalog.getObject` are replaced by simple `portal_catalog` calls. /reviewed-on nexedi/erp5!309
-
Jérome Perrin authored
In `sheet_per_report_section` mode if the report do not have any fields, we use to display an empty sheet. It was confusing and not useful.
-
Jérome Perrin authored
This export action produce a spreadsheet containing information needed to physically prepare sales packing lists, prepare a mailing to prepare address stickers or whatever specific processing "outside of ERP5" can be needed when sending sales packing lists. It is an action on sales packing lists module: ![Screenshot_2017-07-10_at_14.30.10](/uploads/554a0d7b656aaa88d250136dd39309f3/Screenshot_2017-07-10_at_14.30.10.png) Offering two level of details: * One line per sales packing list line * One line per delivery, with the resource / quantities "packed" in a column Both versions will display a list of sales packing lists, but only the one where resource is a product. The idea is to only care only about physically delivered goods. When requesting boths (which is the default), user will get a spreadsheet with two tabs, like this example: [Shipment_Report.xlsx](/uploads/c39906f36cbddd5c20cdd4ce39a90381/Shipment_Report.xlsx) (this is using data from `testTradeReports.TestTradeReports.testShipmentReport` added in this MR) The intended use case of this action is to select packing lists to prepare (usually with worklist), export this spreadsheet and change state of the selection. /reviewed-on nexedi/erp5!320
-
- 09 Aug, 2017 4 commits
-
-
Vincent Bechu authored
/reviewed-on nexedi/erp5!345
-
Vincent Bechu authored
/reviewed-on nexedi/erp5!343
-
Vincent Bechu authored
/reviewed-on !344
-
Xiaowu Zhang authored
/reviewed-on nexedi/erp5!340
-
- 08 Aug, 2017 1 commit
-
-
Vincent Bechu authored
/reviewed-on nexedi/erp5!341
-