-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[QA] All activity mails lost their date, not only expiry mails #1131
Comments
https://github.com/owncloud/core/blob/master/apps/files_sharing/lib/Activity.php has the various constants for what type of activity happened. It would be possible to only remove the time for the activities that are about share expiry: What is the requirement? |
My question would be: Why was the timestamp removed in the first place? (the related issue is hidden in proprietary repo, so I do not know) The only situation where it would not lead to any further information would be the aforementioned expiry event, which happens by the end of the day. But for any other event it seems to be valuable information, especially since some customers only subscribe to the the digest mail. |
Support could elucidate the original issue a bit more to us and this is how the situation seems to be:
Consequently I assume there can be consensus on "timestamps should be brought back for non-expiry events". |
Proposed possible approach at #1181 |
@Deaddy exactly right. There is a lot of potential confusion with expiry timestamps. The exact time of the day, when something technically expires is pretty unreliable due to random timezone misunderstandings and/or cron jobs running late. |
Still not fixed? I'm not happy about that. Stop weird discussions about different timezones. Timestamp including relating (maybe the server's) timezone and the users are getting all, what is needed. Just my 2 cents. (Or let Nextcloud fix it for you. scnr) |
Seen while testing 2.7.1-rc.1 with core 10.11.0-rc.1
Due to #1118 all mails lost their date info.
E.g. "XXX shared YYY with ZZZ" maybe should still expose the time? should it?
Probably a harmless loss, as the mail itself has a timestamp in the header.
The text was updated successfully, but these errors were encountered: