- 30 Jan, 2023 1 commit
-
-
Jérome Perrin authored
-
- 29 Jan, 2023 1 commit
-
-
Aurel authored
-
- 28 Jan, 2023 1 commit
-
-
Arnaud Fontaine authored
-
- 26 Jan, 2023 1 commit
-
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1732
-
- 25 Jan, 2023 4 commits
-
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1731
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
cause by nexedi/erp5!1726
-
Jérome Perrin authored
On the way to Zope 4, the biggest change was DateTime >= 3, which has these main differences: - `DateTime` instances are new style classes - `DateTime.__eq__` now take into the timezone into account - `DateTime` supports timezone naive ( https://docs.python.org/3/library/datetime.html#aware-and-naive-objects ) - actually this is since DateTime 2.12 , but since we fully patched the method where the parsing happens, ERP5's patched DateTime never used timezone naive dates. - pickles are also different. These are changes to prepare ERP5 code base to support DateTime >= 3, while keeping compatibility with the previous behavior, this means that we keep patching to keep the same behavior as DateTime 2, so that `DateTime.__eq__` ignores timezone difference and `DateTime` does not support timezone naive dates - these two different behavior seemed to introduce too much breakages, especially in project code, with no immediate benefit for our usages. For now, while ERP5 is still based on Zope 2 / DateTime 2 the fact that DateTime are new style classes has no impact, this will only impact once we switch to Zope 4. This also change the code to adjust the part where we were depending on implementation details of DateTime and where the details changed on DateTime 3, sometimes exposing higher level API, like the new `timeZoneContext` to use in tests. See merge request nexedi/erp5!1593
-
- 24 Jan, 2023 3 commits
-
-
Roque authored
See merge request nexedi/erp5!1725
-
Roque authored
-
Roque authored
-
- 23 Jan, 2023 10 commits
-
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1726
-
Jérome Perrin authored
use calendar module and public DateTime API instead.
-
Jérome Perrin authored
This ensures that we don't break more.
-
Jérome Perrin authored
We have code depending on these attributes, they were used in pattern like this: ```py try: DateTime(user_input) except DateTime.DateError: error("invalid date") ``` so it's safer to keep the attributes for now, since we are already patching a lot
-
Jérome Perrin authored
We have too much code depending on this behavior, so we keep this patch for now.
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
By using iso format we create dates in UTC timezone
-
Jérome Perrin authored
This is a context manager which temporary allow to change the time zone. It is not thread safe and intended to be used in tests only, to replace setTimeZoneToUTC and setTimezone methods by something unified which makes the transition to DateTime 4 easier, because changing timezone was done by patching private attributes and the DateTime 4 use different attributes.
-
- 20 Jan, 2023 1 commit
-
-
Xiaowu Zhang authored
-
- 18 Jan, 2023 5 commits
-
-
Jérome Perrin authored
Use calendar module instead. These API depends on current locale, but we don't set the locale in ERP5, so these remain in English
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
This is just hiding problem and does not seem needed.
-
Jérome Perrin authored
-
- 17 Jan, 2023 2 commits
-
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
- 16 Jan, 2023 1 commit
-
-
Xiaowu Zhang authored
-
- 13 Jan, 2023 4 commits
-
-
Xiaowu Zhang authored
See merge request nexedi/erp5!1723
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
Xiaowu Zhang authored
-
- 12 Jan, 2023 4 commits
-
-
Jérome Perrin authored
The changes from ae15e7e1 (accounting: show the context when showing invalid bank accounts, 2022-12-21) were a regression because with the previous behaviour, by just looking at the transactions, users could see with the ??? that something was wrong with the bank account. After these changes they had to open the select element. This restore somehow the previous behaviour by displaying the label with ??? marker, but since we have the label, we display the label (bank account reference) instead of the value (the relative URL)
-
Jérome Perrin authored
This was working only with Organisations
-
Jérome Perrin authored
Fix small problems displaying bank accounts on accounting transactions and be more strict during validation: - bank account must be validated - bank account must belong to the section The latter was a problem for scenarios like this: - create transaction for supplier 1 with supplier 1 bank account - clone transaction - change to supplier 2 the bank account remains as supplier 1 bank account, although it became an invoice from supplier 2. The transaction could be validated as long as the bank account is not invalidated See merge request nexedi/erp5!1713
-
-
- 11 Jan, 2023 2 commits
-
-
Jérome Perrin authored
The only check with accounting transactions regarding bank account was that the bank account is not invalidated. This makes the constraint more strict by checking that the bank account belongs to the corresponding entity and also that the bank account is validated. A few tests needed to be updated to validate the bank accounts. Also a legacy sequence test has been removed because it is now covered by normal tests.
-
Jérome Perrin authored
-