Nextcloud 25.0.6 - Time not correct in activity mail sent by nextcloud

mathsyx-fr · May 24, 2023, 7:49am

Support intro

Sorry to hear you’re facing problems

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can

Nextcloud version (eg, 20.0.5): 25.0.6
Operating system and version (eg, Ubuntu 20.04): debian 11 Bulleye 5.10.179-1
Apache or nginx version (eg, Apache 2.4.25): apache 2.5.56
PHP version (eg, 7.4): 8.1.18

The issue you are facing:

Hello everyone,
I have a bug with the time of the activities sent by mail.
I already report this bug on the github but when I have open the issue my nextcloud isn’t up to date so my issue Has been close #36410 / #38442 .
Today I have update my nextcloud instance from 24.0.7 to 24.0.12 to 25.0.6 and the bug is still here.
I also upgrade my php-fpm and modules from 8.0 to 8.1 .
Since execution time of last cron isn’t displayed in interface like nextcloud 24.X, the bug now impact only the time in activities mails.
There is 2 hour (minus “-2”) difference with the real time in my country (France).
I have configured the time zone in the nextcloud settings… (Europe/Paris)
The time is correct in the activities section (see attached pic).

Is this the first time you’ve seen this error? (Y/N): N (I encourtered this « bug » in nextcloud v24.0.7 and v27.0.12)

Steps to replicate it:

Read activities mail sent by nextcloud (verify receive date and time indicated for the activity) compare it with the time indicate in actvity sections in nextcloud web client

The output of your Nextcloud log in Admin > Logging:

Logs too long

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "https:\/\/***REMOVED SENSITIVE VALUE***\/",
        "htaccess.RewriteBase": "\/",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***",
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "25.0.6.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "templatedirectory": "",
        "skeletondirectory": "",
        "trashbin_retention_obligation": "7, 8",
        "defaultapp": "files",
        "logtimezone": "Europe\/Paris",
        "default_language": "fr",
        "default_locale": "fr_FR",
        "default_phone_region": "FR",
        "activity_expire_days": "30",
        "allow_user_to_change_display_name": false,
        "lost_password_link": "disabled",
        "oidc_login_provider_url": "***REMOVED SENSITIVE VALUE***",
        "oidc_login_client_id": "***REMOVED SENSITIVE VALUE***",
        "oidc_login_client_secret": "***REMOVED SENSITIVE VALUE***",
        "oidc_login_auto_redirect": false,
        "oidc_login_logout_url": "https:\/\/***REMOVED SENSITIVE VALUE***\/",
        "oidc_login_end_session_redirect": false,
        "oidc_login_button_text": "Connexion avec M365 (***REMOVED SENSITIVE VALUE***)",
        "oidc_login_hide_password_form": true,
        "oidc_login_use_id_token": false,
        "oidc_login_attributes": {
            "name": "name",
            "mail": "email",
            "id": "email"
        },
        "oidc_login_default_group": "utilisateurs-openid",
        "oidc_login_use_external_storage": false,
        "oidc_login_scope": "openid profile",
        "oidc_login_proxy_ldap": false,
        "oidc_login_disable_registration": false,
        "oidc_login_redir_fallback": false,
        "oidc_login_tls_verify": true,
        "oidc_create_groups": false,
        "oidc_login_webdav_enabled": false,
        "oidc_login_password_authentication": false,
        "oidc_login_public_key_caching_time": 86400,
        "oidc_login_min_time_between_jwks_requests": 10,
        "oidc_login_well_known_caching_time": 86400,
        "oidc_login_update_avatar": false,
        "maintenance": false,
        "theme": "",
        "loglevel": 1,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "simpleSignUpLink.shown": false,
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

davtheultimate · July 27, 2023, 2:09pm

Bonjour mathsyx-fr,

I have exacly the same problem.
Time in table of database are good in oc_activity and oc_activity_mq.
But Minus -2 hours too, in mail notification

Have you find a solution ?

davtheultimate · July 27, 2023, 2:37pm

if i alter the file MailQueueHandler.php of the apps activity and i replace line 517 by :
$timestampplus2 = strtotime(‘+2 hours’,$activity[‘amq_timestamp’]);
$relativeDateTime = $this->dateFormatter->formatDateTimeRelativeDay(
(int) $timestampplus2,

it was good for me.
My os is ubuntu 22.04 with command timedatectl, output is like that :
timedatectl
Local time: jeu. 2023-07-27 16:32:04 CEST
Universal time: jeu. 2023-07-27 14:32:04 UTC
RTC time: jeu. 2023-07-27 14:32:04
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

I suppose the dateformatter use Universal time UTC.

mathsyx-fr · July 27, 2023, 9:02pm

Hello davtheutimate,

I was able to partially solve the bug on my side, you can have a look at the following github issue :
[Bug]: Time not correct in activity mail sent by nextcloud (25.0.6) #38422

davtheultimate · July 28, 2023, 9:59am

Hello,

Bon comme on est français je vais me permettre de te répondre en Français. J’utilise également un plugin openid en relais sur keycloak. C’est donc le fait de ne pas utiliser le formulaire de login standard qui fait que le champs timezone n’est pas ajouté. De ce que j’ai compris avec l’authentification standard, c’est à la connexion que le champs est ajouté. Comme nous sommes en autoredirect via l’apps oidc_login, le champs timezone n’est donc jamais ajouté.

Je vais retirer ma modification de code et faire une tâche récurrente pour tous mes utilisateurs qui n’aurait pas la valeur uid / core / timezone / ‘Europe/paris’

J’ai ajouté ce trigger sur la base mariadb. A chaque fois qu’un utilisateur est inséré dans la table oc_ldap_user_mapping alors le tir est déclenché et il ajoute la timezone dans la table oc_preferences pour ce dernier.

DELIMITER $$
CREATE TRIGGER addtimezone AFTER INSERT ON oc_ldap_user_mapping FOR EACH ROW
BEGIN
IF NOT EXISTS (SELECT 1 FROM oc_preferences WHERE userid = NEW.owncloud_name and configkey =‘timezone’) THEN
INSERT INTO oc_preferences VALUES (NEW.owncloud_name,‘core’,‘timezone’,‘Europe/Paris’);
END IF;
END $$
DELIMITER ;

On vide les deux tables de leurs utilisateurs pour provoquer le tir du trigger pour tous nos users :
Database changed
MariaDB [nextcloud]> delete from oc_accounts where uid not like ‘ncadmin’;
Query OK, 92 rows affected (0,004 sec)

MariaDB [nextcloud]> delete from oc_ldap_user_mapping;
Query OK, 91 rows affected (0,002 sec)
une petite synchro : sudo -u www-data php /var/www/html/nextcloud/occ user:list

et c’est tout bon, j’ai mes 91 comptes avec une valeur core / timezone / Europe/Paris

Bonne fin de journée et merci pour ta réponse.

mathsyx-fr · July 28, 2023, 2:09pm

Hello,

Tant mieux si ma solution temporaire à pu t’aider.
J’aurais bien aimer mettre en place la même remédiation que toi mais je ne connais pas le fonctionnement du plugin “oidc_login” que j’utilise.

J’ai ouvert un incident sur la page github (https://github.com/pulsejet/nextcloud-oidc-login/issues/229) du plugin mais le créateur ma demandé des informations mais sans m’aider à résoudre mon problème…

Tu aurais une idée pour mettre en place la même correction que toi via un déclencheur mariadb?

Bonne journée et merci pour le partage d’informations !

davtheultimate · July 28, 2023, 3:09pm

Ma remédiation n’est pas lié au plugin mais uniquement à la base de donnée de sorte que si je met à jour Nextcloud ou le plugin, la modification est conservé. C’est un TRIGGER sur la BDD, une sorte de déclencheur sur événement.

Normalement sur le serveur qui héberge ta base mariadb en mode root.

Tu te connectes sur la BDD et tu saisis ces quelques commandes :
mysql
use nextcloud
Tu es à présent connecté sur la BDD et tu peux faire du SQL dont l’ajout du TRIGGER / Déclencheur ci-dessous :
DELIMITER $$
CREATE TRIGGER addtimezone AFTER INSERT ON oc_ldap_user_mapping FOR EACH ROW
BEGIN
IF NOT EXISTS (SELECT 1 FROM oc_preferences WHERE userid = NEW.owncloud_name and configkey =‘timezone’) THEN
INSERT INTO oc_preferences VALUES (NEW.owncloud_name,‘core’,‘timezone’,‘Europe/Paris’);
END IF;
END $$
DELIMITER ;
C’est fonctionnel ensuite pour tous les nouveaux comptes qui seront ajoutés par la suite. pas pour les comptes existants. Il faut pour les comptes existants vider deux tables : oc_accounts en dehors du compte admin local (le mien est nommé ncadmin) et oc_ldap_user_mapping via ces deux requêtes :
delete from oc_accounts where uid not like ‘ncadmin’;
delete from oc_ldap_user_mapping;

Ensuite tu quittes mysql via la commande exit. et tu resynchronises tes users existants via la commande suivante qui dépend de l’endroit ou se trouve l’executable occ :
sudo -u www-data php /var/www/html/nextcloud/occ user:list

davtheultimate · July 28, 2023, 3:26pm

j’ai ajouté un commentaire également sur ton incident github en espérant une évolution.

mathsyx-fr · July 28, 2023, 11:06pm

Merci d’avoir pris le temps de répondre et de m’avoir apportée ton aide précieuse.
J’espère que le créateur du plugin mettra en place une correction.

Je vais tester le déclencheur mariadb sur mon environnement mais il y à des choses que je ne comprend pas et que j’aimerais éclaircir avant:

Le mécanisme de creation d’utilisateur avec la table oc_ldap_user_mapping est elle utilisée par le plugin que j’ai de mon coté ?
la variable NEW.owncloud_name est elle nommée ainsi car tu utilise owncloud ou parce que c’est un reste qui date du fork de nextcloud ?

Je suis désolé de t’embêter avec mon cas.
Bonne journée.

davtheultimate · August 2, 2023, 8:54am

Le mécanisme de création d’un utilisateur dans la table oc_ldap_user_mapping est uniquement lié au fait de la mise en oeuvre de la synchronisation de comptes utilisateurs avec un active directory. L’ajout ou le retrait d’un utilisateur dans une OU de ton serveur AD avec lequel tu synchronises les comptes mettra donc à jour cette table.

la variable owncloud_name vient de la table oc_ldap_user_mapping, c’est le champs primary de cette table. Pourquoi NEW devant ?, et bien parce que lors le TRIGGER se déclenche par l’ajout d’un nouvel enregistrement. Le TRIGGER qui est focus sur la surveillance de la table oc_ldap_user_mapping nomme alors ce champs NEW.owncloud_name qu’il comparera ensuite dans le requête SELECT qui suit pour tester si cette ID et une timezone associée existe déjà dans la table oc_preferences. Si c’est le cas, il ne fait rien et s’il n’existe pas alors il fait la requête INSERT pour l’ajouter.