- 01 Apr, 2022 1 commit
-
-
Arnaud Fontaine authored
-
- 31 Mar, 2022 3 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
- 30 Mar, 2022 1 commit
-
-
Arnaud Fontaine authored
-
- 28 Mar, 2022 2 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
- 25 Mar, 2022 1 commit
-
-
Jérome Perrin authored
-
- 24 Mar, 2022 2 commits
-
-
Julien Muchembled authored
When rendering a proxy field, 3 different fields can come in play: 1. the field to be rendered 3. the template field (i.e. not a proxy field) that knows how to render 2. possibly an intermediate proxy field that contains the value to render What's difficult when rendering a proxy field is to take the above 3 fields into account and this commit does it by creating a temporary field: 1. 'field' variable in TALES 2. the value 3. the code Before this commit, 1 could be wrong.
-
Jérome Perrin authored
This was deprectated because we don't have get*ById for other modules and tools, we just use OFS API. This should also be slightly faster because one less method call (and one less call to warning)
-
- 23 Mar, 2022 5 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
exiting the context manager restores the original DateTime behavior
-
Jérome Perrin authored
This tests the test framework, because this code is tricky.
-
Jérome Perrin authored
-
Jérome Perrin authored
I'm not sure if this is used, but not being valid python code cause problems with code analysis tools
-
- 22 Mar, 2022 4 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
mock has several advantages, the main one here is that it errors when patching does not replace an existing attribute, which happens when we are not patching the right place. These attributes are not the same place in DateTime 2 and 3, this code when using DateTime 2 was replacing the attributes, but in DateTime 3 it was just creating new attributes that were never used. Update the code to patch the DateTime 3 location
-
Jérome Perrin authored
-
Jérome Perrin authored
Maybe this made sense long time ago, but nowadays we are using equivalence testers which tolerate date differences with more flexibility. createDateTimeFromMillis was also problematic as it uses internal private attributes of DateTime which is a pylint error with more recent DateTime
-
- 21 Mar, 2022 5 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
Error `Using import with a level specification isn't supported by AccessControl: AccessControl`: eggs/Zope-4.5.3+slapospatched002-py3.7.egg/Products/PageTemplates/Expressions.py(188)_eval() -> ob = self._subexprs[-1](econtext) eggs/zope.tales-5.1-py3.7.egg/zope/tales/expressions.py(153)_eval() -> ob = self._traverser(ob, element, econtext) eggs/Zope-4.5.3+slapospatched002-py3.7.egg/Products/PageTemplates/Expressions.py(84)boboAwareZopeTraverse() -> request=request) eggs/zope.traversing-4.4.1-py3.7.egg/zope/traversing/adapters.py(156)traversePathElement() -> return traversable.traverse(nm, further_path) eggs/zope.traversing-4.4.1-py3.7.egg/zope/traversing/adapters.py(58)traverse() -> return subject[name] eggs/Zope-4.5.3+slapospatched002-py3.7.egg/Products/PageTemplates/ZRPythonExpr.py(56)__getitem__() -> mod = safe_builtins['__import__'](module) parts/erp5/product/ERP5Type/patches/Restricted.py(451)guarded_import() -> return orig_guarded_import(mname, globals, locals, fromlist, level) eggs/AccessControl-4.2-py3.7-linux-x86_64.egg/AccessControl/ZopeGuards.py(410)guarded_import() -> "supported by AccessControl: %s" % mname)
-
Romain Courteaud authored
Permissions are managed by the document_publication_worflow
-
Xiaowu Zhang authored
-
- 19 Mar, 2022 6 commits
-
-
Arnaud Fontaine authored
File "product/TimerService/timerserver/TimerServer.py", line 71, in run s.send('GET / HTTP/1.1\r\n\r\n') TypeError: a bytes-like object is required, not 'str'
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
- 18 Mar, 2022 3 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
Most service worker precache scripts reference a favicon.ico, but this is using the default favicon.ico from Zope and even though it was included in all ERP5JS and OfficeJS web sites, this was mostly not used, only web_renderjs_ui web pages reference favicon.ico. There's a favicon.ico in erp5_xhtml_style skin folder, but the skin folder is not in ERP5JS skin selection. On Zope2, this caused ERP5JS and OfficeJS application use the default Zope favicon. On Zope4, the service worker can not fill its cache because of 404 errors, because since Zope commit 4f0770941 (Retired icons from the `Zope Management Interface` and various smaller cleanups of ZMI screens., 2011-07-02) there's no default favicon.ico anymore. To solve this, provide a favicon.ico in ERP5JS skin selection, by copying the one from erp5_xhtml_style. We also reference it explicitly in web site layout properties so that it remain in the cache. OfficeJS applications do not use favicon.ico explicitly. They use icons in their web application manifest, but this does not seem to be use as favicon unless the PWA is installed. This part is not addressed by this commit.
-
Arnaud Fontaine authored
-
- 16 Mar, 2022 1 commit
-
-
Arnaud Fontaine authored
-
- 14 Mar, 2022 5 commits
-
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
-
Arnaud Fontaine authored
${SR_DIRECTORY}/bin/python -c 'from zope.fixers.main import main; main("--write --nobackups parts/erp5/".split())'
-
Arnaud Fontaine authored
-
- 11 Mar, 2022 1 commit
-
-
Jérome Perrin authored
-