- 13 Aug, 2020 3 commits
-
-
Jérome Perrin authored
TODO: update message. old message below (scope and implementation changed since we cover original Products.*.Document and don't do newTempX ) --- make Products.ERP5Type.Document a dynamic module Historically all document classes from Products/*/Document/*.py and from $INSTANCE_HOME/Document/*.py were dynamically loaded in Products.ERP5Type.Document namespace and objects in ZODB were instances of Products.ERP5Type.Document.*.* classes. This allowed moving the python code from one product to another without having to wory about persistent references in ZODB. This was done in Products.ERP5Type.Utils.importLocalDocument which was used for Products/*/Document/*py and $INSTANCE_HOME/Document/*.py but that was never the case for document components - they are loaded on demand. When "portal types as classes" have been introduced, we used a new indirect erp5.portal_type namespace, for similar reasons as the Products.ERP5Type.Document namespace. The approach to migrate existing documents was to hook the loading from ZODB ( Base.__setstate__ , monkey patched from Products/ERP5Type/dynamic/persistent_migration.py ) to replace the class from the old Products.ERP5Type.Document.* by its corresponding erp5.portal_type.* class. This was working fine to migrate documents whose classes were defined in Products/*/Document/*.py, but now that these classes have been moved to document components, this does not work anymore, because unlike when loading a document class from Products/*/Document/X.py we don't create the corresponding Products.ERP5Type.Document.X module when loading from X component. As a result, existing documents of class Products.ERP5Type.Document.X.X which did not get a chance to be migrated before X was moved to component were now broken. In the observed case, there was several Address, Telephone or Email created ~10 years ago. These changes address this issue by making Products.ERP5Type.Document a dynamic module, ie. changing the previous beaviour of copying all document classes to Products.ERP5Type.Document by introducing a module that will dynamically lookup the document classes on demand, first from erp5.component.document modules, then falling back to the legacy document classes registry (populated at startup from Products/*/Document/*.py and $INSTANCE_HOME/Document/*.py) A side effect of this is that newTempX constructors are now created from document components as well (but they are still deprecated because their behavior is really strange: when you call newTempX - X is the name of a document class, which has a portal_type attribute and newTempX create an instance of the portal type defined on that class, but the portal type might be referencing anothing class)
-
Jérome Perrin authored
Test importing a business templates with classes from Products.ERP5Type.Document
-
Jérome Perrin authored
because TestZodbDocumentComponent contains test specific to Document Component, tests for other component should not inherit from it, because tests that apply for Document Component only does not apply for other components. The correct base class containing tests that apply to any type of component is _TestZodbComponent TestZodbDocumentComponentReload was another case, this test tests some special cases of document edition/reload, it does not need to extend TestZodbDocumentComponent, otherwise it will run again all tests from TestZodbDocumentComponent.
-
- 12 Aug, 2020 7 commits
-
-
Roque authored
See merge request nexedi/erp5!1239
-
Roque authored
-
Jérome Perrin authored
Configuration generated by Standard Configurator was not really good. For most divergences, there was no solvers configured, so users could not configure divergences. Now solvers (for packing lists) are configured so that every divergence is automatically accepted, we only expect user to take a decision when quantity or resource is different. This change was implemented in the rules from `erp5_configurator_trade_template`, but because several simulation tests were relying on the fact that "changing anything would cause a divergence" the previous rules configuration are kept in a new `simulation_test_trade_template`. Also, security configuration was incomplete, since the introduction of "new simulation", some Unauthorized errors occurred when non-manager users where trying to solve divergence. This is now solved and exercised in the integration tests we run on auto-configurated instance. The configuration was obsolete, nowadays we use different business processes for each use case, this configuration was still using only one business process for both sale and purchase, now we use two and improve the accounting configuration, to use accounts defined in supply line. Some others small improvements were made, for example now we can configure the delivery solver to use for a split solver once and for all in the solver and user does not have to choose each time. What not updated this time: - divergences on Invoice Lines: this is probably same as on Packing List before these changes - rules are still configured with ad-hoc scripts and not based on trade phase categories. See merge request nexedi/erp5!1221
-
Jérome Perrin authored
See merge request nexedi/erp5!1236
-
Jérome Perrin authored
Since 248f59e5 (Business Template: Likewise ERP5Site.addERP5Tool(), do not re-create Tool if it already exists., 2020-06-22) we no longer update tools, because of the problem that business template does not currently handle updating objects with lots of sub-objects. But we realized that we really need to update tools when they contain configuration as object attributes, like mimetypes_registry, where the problem was observed. Instead of unconditionnally skipping any tool during update, we only skip the ones that were initially managed by ERP5Generator and are moved to business templates.
-
Jérome Perrin authored
to match the button on the front page
-
Jérome Perrin authored
With virtualhosting, there can be an empty path element at the beginning of the path.
-
- 11 Aug, 2020 2 commits
-
-
Jérome Perrin authored
Try to find a full message translation before falling back to generic translation using ${portal_type} Most of jump methods were already doing this correctly, these were some exceptions.
-
Jérome Perrin authored
The "New ${portal_type} created." is impossible to translate in languages using genders for nouns, for example in french, New is translated as "Nouveau" for masculine portal types and "Nouvelle" for feminine portal types. Instead, translate the full "New Support Request created." sentence.
-
- 10 Aug, 2020 2 commits
-
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1233
-
Xiaowu Zhang authored
organisation logo is not accessible for anonymous
-
- 07 Aug, 2020 10 commits
-
-
Gabriel Monnerat authored
upload document and run all activities around this upload takes time, so we use a larger timeout
-
Gabriel Monnerat authored
erp5_officejs_support_request_ui_test: Add test to make sure we have all expected actions to access support request web site * Check if each portal_type has the expected view action * add test to cover all possible attachments in a Support Request
-
Gabriel Monnerat authored
erp5_officejs_support_request_ui: Simplify code to render the expected action to preview any attachement document
-
Gabriel Monnerat authored
-
Gabriel Monnerat authored
Hard coding to select action_object_view we will never use web site configuration. If we always get links from action_object_view, Support Request will always break if we change View Action Category on web site.
-
Gabriel Monnerat authored
Having a big "Generate RSS" button on the front page is strange, because the front page button are for common use cases that users are supposed to execute a lot. For example, makes sense to have a "Submit new Support Request" button, because users are using this app to submit support requests, but generating RSS is very exceptional action, so we wanted to remove it from the front page. Also, we changed: - change the generate_rss_link action in Support Request Module, to directly call SupportRequestModule_generateRSSLinkUrl.py instead of the form. - change SupportRequestModule_generateRSSLinkUrl to display the form at the end. - Use Base_renderForm like for erp5_crm - Put the RSS url in the REQUEST - change the gadget field configuration to use the value from the REQUEST (if not found, put None) - change the gadget implementation to display the URL in an html5 string field + a button
-
Roque authored
See merge request nexedi/erp5!1227
-
Romain Courteaud authored
Without it, it is not possible to upgrade instances since: nexedi/erp5@48c45fbd [test/upgradeOldDataFS] use UI callables Ensure the admin will able to trigger the upgrader
-
Xiaowu Zhang authored
erp5_corporate_identity_test: test pdfs are only used to store data then check converted image, so one pdf is enough
-
Xiaowu Zhang authored
-
- 06 Aug, 2020 8 commits
-
-
Roque authored
- test updated
-
Roque authored
-
Roque authored
-
Romain Courteaud authored
-
Romain Courteaud authored
Do not limit by default
-
Romain Courteaud authored
Querying the catalog does not limit the result by default.. See nexedi/erp5@241a87a1
-
Romain Courteaud authored
-
Romain Courteaud authored
-
- 05 Aug, 2020 4 commits
-
-
Jérome Perrin authored
what's wrong with this anyway
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
- 04 Aug, 2020 4 commits
-
-
Rafael Monnerat authored
See merge request nexedi/erp5!1226
-
Jérome Perrin authored
When a request got retried after a conflict error, a: TypeError: getPublisherDeadlineValue() takes exactly 1 argument (0 given) was raised. Instead of adding a new test to cover this, run all tests from ZPublisher module (except a few which had suspicious errors). This actual error happened when running ZPublisher.tests.testPublish.testPublisher before the fix.
-
Jérome Perrin authored
See merge request nexedi/erp5!1220
-
Jérome Perrin authored
Install more business templates such as erp5_web or erp5_dms, to confirm that we can also update these business templates. Run the tests with "full indexing", to be more realistic and to be sure that we don't hide problem that would happen when reindexing action definitions or property sheets. See merge request nexedi/erp5!1228
-