- 30 Jun, 2020 2 commits
-
-
Jérome Perrin authored
Firstly, rework a bit the action to create translation data, the action no longer allow choosing the translation data script to update, but uses the one referenced in the translation gadget html. In post upgrade, compare the actual content of the translation data script with the expected content, calculated from web site languages, data-i18n attributes from referenced pages and Localizer messages. This makes the requirement that web sites with different configurations for translations need to use different translation gadget stronger, when it's not met post upgrade will always report consistency issues. To address this, modify existing web sites so that they all use different translation gadgets - or at least don't use translation gadget explicitly. This was made by: - all web sites by default do not have a translation gadget - smart_assistant use a dedicated translation gadget, to confirm that using a different translation gadget is possible with an officejs web site, where the translation gadget is defined in the "app" web section. - officejs_support_request_ui uses a dedicated translation gadget, because we need this for a customer project and for ourselves. - other web sites do not support translation by default, but enabling would be easy: - set the allowed languages on web site - create an empty web script ( `{website}_translation_data.js` ) - create a translation gadget web page ( `{website}_translation.html` ) using same content as `gadget_translation.html`, except that the translation data script should be the one created above ( `{website}_translation_data.js` ) - configure the web site to use translation gadget in layout properties. In the case of an OfficeJS web site, this should not be set on the web site but on the main web section - use "Update Translation Data" action on web site or run post-upgrade step of upgrader. This revealed problems (page does not load with javascript error) when using different translation gadgets, that were addressed by not pre-loading the default translation gadget. See merge request nexedi/erp5!1151
-
Jérome Perrin authored
![login](/uploads/d270b602f784466dcc8d0806ec0ab9e1/image.png) ![recover](/uploads/da5bca427e6053a4724a4f7171db71db/image.png) ![reset password](/uploads/27e3519dfaf96cd66ce3adf9d6184ba8/image.png) See merge request !1165
-
- 29 Jun, 2020 9 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Jérome Perrin authored
This was not enabled, but it's should be OK already See merge request nexedi/erp5!1170
-
Arnaud Fontaine authored
product/ERP5SyncML/{Transport,Engine}/*.py were not considered.
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Jérome Perrin authored
-
Jérome Perrin authored
this is supposed to work
-
- 26 Jun, 2020 2 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
pylint: Fix false positive error `No name 'ElementMaker' in module 'lxml.builder' (no-name-in-module)`.
-
- 25 Jun, 2020 2 commits
-
-
Arnaud Fontaine authored
W: Dangerous default value _MARKER (__builtin__.list) as argument (dangerous-default-value)
-
Nicolas Wavrant authored
Since BusinessProcess.py was moved to portal_components, the cache in mixin/composition.py, which was kept at the level of the zope process, was causing issue when portal_components was reset : the classes kept in __class_cache would not get resetted, and later calls to asComposedDocument would reuse them. In consequence, these classes would kept pointers to objects in the old class BusinessProcess, causing bugs as these objects would have been cleaned by the reset. The first intuition was to remove this cache, unfortunately the reason of this introduction (fixing a memory leak) is still valid nowadays, so I've decided to move this cache within BusinessProcess, as it has the advantage of emptying it whenever portal_components is resetted. For more information of the bug mentionned above, and the trials about removing the cache can be found in the discussion of this MR : nexedi/erp5!1032
-
- 24 Jun, 2020 10 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
ZODB Components: Migration dialog: Make sure that paths given in Working Copy (Preference) are valid.
-
Jérome Perrin authored
For consistency with other ERP5JS dialogs
-
Jérome Perrin authored
For consistency with xhtml style and other ERP5JS dialogs
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
This way, the padding between fields will be applied and the visual result would be similar as on all other ERP5JS dialogs
-
Jérome Perrin authored
-
Jérome Perrin authored
This way we don't need to define absolute_url multiple times
-
- 23 Jun, 2020 15 commits
-
-
Arnaud Fontaine authored
Besides migrating Tools .py, this also moves the Tools themselves (portal_*): * Some of them were created before erp5_core being installed and this would not work anymore as their .py is now in erp5_core. * Some others were created after (via setupLastTool()) and this would not work neither as sub-objects may be installed by erp5_core. Add them to template_keep_path_list to prevent them from being re-created like ERP5Site.addERP5Tool() used to do (depend on 3180424b, 91393be2). Not migrated: * AlarmTool: Needed for upgrader. * CategoryTool, IdTool: Bootstrap. * TemplateTool, TrashTool: Business Template installation. * SolverTool: TypeProvider. * ContributionTool: Imported by Products.ERP5.Document.Document used in many places, will be done later. * NotificationTool: Imported by ERP5.Document.EmailDocument, will be done later.
-
Arnaud Fontaine authored
On re-create, all the sub-objects will be copied back and this should not happen for Tools (example: portal_simulation currently created by addERP5Tool() but later going to be migrated to ZODB Components and moved to bt5).
-
Arnaud Fontaine authored
When force is selected, it should be updated regardless of user choice (for example when `force_install` is set). But usually when installing a bt5, user selects what should be updated (`object_to_update dict` later filtered to `update_dict` (to not contain unselected objects)).
-
Arnaud Fontaine authored
pylint: Fix false positive error `No name 'OOBTree' in module 'BTrees.OOBTree' (no-name-in-module)`.
-
Arnaud Fontaine authored
-
Romain Courteaud authored
-
Jérome Perrin authored
These web sites are not using configuration_manifest_url to refer to an application cache, so remove the reference so that upgrader does not check if application cache manifest is up to date
-
Jérome Perrin authored
-
Jérome Perrin authored
When websites are using another translation gadget we end up with two translation gadgets loaded (which causes issues)
-
Jérome Perrin authored
Otherwise "conflicts" happen when a web site is configured to use anotehr translation gadget
-
Jérome Perrin authored
We can not use the default gadget as ERP5JS for translations, because web sites with different messages needs to be using a different translation gadget. As a first step we stop referencing the default gadget translation on web site, so that upgrader does not try to update the default translation data script. Next step will be to use different translation gadgets on each web site which uses translation.
-
Jérome Perrin authored
This website has different translations from renderjs_runner web site, so they can not share the same translation gadget
-
Jérome Perrin authored
Automate the process of running "Update Translation Data" in post-upgarde step when the translation data has changed. This means that translation scripts (such as gadget_translation_data.js for default ERP5JS gadget) will be updated automatically after each update and it becomes wrong to have multiple sites using the same translation gadget for different translations. If that happens, the upgrader tries to detect a loop and raise an easy-to-understand error in that case
-
Jérome Perrin authored
With officejs web sites, the translation gadget is not referenced directly on the web site, but in the "app" web section. Teach this script to look on the web section to know which translation data script to use
-
Jérome Perrin authored
- user no longer have to choose the translation data script, it's selected automatically from the translation gadget configured on the web site - add some notes in workflow history for traceability - rename from "Create Translation Data" to *Update* Translation Data, as this script can be called multiple times to update - rename the dialog and script to comply with naming conventions - add a header to generated translation data script to explain that this is generated and that it should not be edited manually - generate code passing jslint and typescript
-