You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal:
Make the document date required. Existing documents without a document date will have the document date set to their creation dates in an upgrade step. When creating documents (or drag'n'drop-uploading), the document will be set to "now".
Issue / reason:
We can only sort a list of documents by document date when all of the items have a date. The catalog enforces this behavior by just removing (!) all documents from the list when they do not have a date. This behavior is correct because the catalog does not know the meaning of dates in general and thus cannot decide whether to sort those items at the top or at the bottom.
Another reason is that every document has a date. If it does not, it is used wrongfully, for example the document date field is abused for another purpose.
Not having a document date is no longer a supported use case. If there are issues when migrating and projects / customer have a problem with this decision, a requirements engineering session must be initiated and may for example result in a new date field which describes the customers use case more precisely.
History:
The ftw.tabbedview used to "fix" the catalog "bug" by not sorting with the catalog but by sorting manually in python. However, the results were always wrong because there is no correct sorting behavior when values are missing.
I absolutely agree to make the DocumentDate required and set the creation date as documentDate if there's none.
IMHO this was the intention from the beginning, but was implemented the wrong way because of a lack of knowledge or a mistake. I consider this a bug, which needs to be fixed.
Goal:
Make the document date required. Existing documents without a document date will have the document date set to their creation dates in an upgrade step. When creating documents (or drag'n'drop-uploading), the document will be set to "now".
Issue / reason:
We can only sort a list of documents by document date when all of the items have a date. The catalog enforces this behavior by just removing (!) all documents from the list when they do not have a date. This behavior is correct because the catalog does not know the meaning of dates in general and thus cannot decide whether to sort those items at the top or at the bottom.
Another reason is that every document has a date. If it does not, it is used wrongfully, for example the document date field is abused for another purpose.
Not having a document date is no longer a supported use case. If there are issues when migrating and projects / customer have a problem with this decision, a requirements engineering session must be initiated and may for example result in a new date field which describes the customers use case more precisely.
History:
The
ftw.tabbedview
used to "fix" the catalog "bug" by not sorting with the catalog but by sorting manually in python. However, the results were always wrong because there is no correct sorting behavior when values are missing.Discussed with @maethu and @elioschmutz
/cc @4teamwork/dev-plone FYI
The text was updated successfully, but these errors were encountered: