Latest User Action Notification

Ik ben zo vrij terug te komen op mijn topic .
Ik maakte hierover een melding op Github , maar dit werd gemeld als gefixt, ook na mijn recente heropening van 19/5/24 - zie de reactie van Brian Teeman. Ik ben helaas niet erg vertrouwd met Github. Niettemin is dit voor mijn sites nog niet opgelost.

Global configuration - logging: log almost everything = Yes en Log Priorities = All
Plugin System - User actions Log = ingeschakeld
Users Actions Log - options: events to log = Articles, Modules
Superuser: profile: email notifications = Yes en events to Email = Articles, Modules
Mail templates = HTML

Bij een aanpassing aan een artikel of module krijg ik dan volgende email:

PLG_SYSTEM_ACTIONLOGS_CONTENT_UPDATED           2023-11-15 20:05:50 UTC Articles (naam van de superuser)

Voor de upgrade naar v5 was dit:

User xxx has edited article xxxx        2023-11-15 20:05:50 UTC Articles (naam van de superuser)

Vermits ik meerdere sites beheer met meerdere Front-End publishers, is de melding "PLG_SYSTEM_ACTIONLOGS_CONTENT_UPDATED" niet erg handig en moet ik telkens de Back-End openen om een en ander op te volgen.Ik heb diverse instellingen getest en de core-bestanden al opnieuw geïnstalleerd maar zonder resultaat.Ik heb dan bij de instellingen als test "Users" toegevoegd:

Users Actions Log - options: events to log = Articles, Modules, Users
Superuser: profile: email notifications = Yes en events to Email = Articles, Modules, Users

en wat blijkt ? Bij een aanpassing van een user komt er nu wel de correcte email:

User (username van de superuser) updated the user (naam)   2024-05-19 20:47:42 UTC Users (naam van de superuser)

Ik wil vragen of iemand dit kan reproduceren, zodat ik zeker weet of het al dan niet enkel met mijn sites te maken heeft, of dat het issue inderdaad nog niet opgelost is bij Joomla.

Dank
Luk

Klopt. Ik heb maar even een nieuw issue aangemaakt.

Beste Astrid,

Dank om dit issue bij Github te (her)openen.
Nu maar hopen dat dit spoedig opgepikt wordt en in één van de volgende updates opgelost geraakt.

Dank
Luk

Dag Astrid,

Ik deed nog enkele tests op een testsite na upgraden van 5.1.0 naar 5.1.1

Events to email: artikelen, modules
Taal site én taal beheerder werden beide op en-GB gezet.
Back-End: bewerken van een artikel (of module) als super-gebruiker: OK, de correcte email werd afgeleverd.
Front-End: een artikel (of module) bewerken als publisher: OK, de correcte email werd afgeleverd.

Zodra één van beide talen (of allebei) op nl_NL gezet wordt, gaat het fout voor nl_NL en verschijnt er:

Laatste gebruikersacties
Dit is de laatste door een gebruiker uitgevoerde actie op de website.
{MESSAGE}    {DATE}    {EXTENSION}    {USERNAME}

Voor en_GB wordt WEL de correcte mail afgeleverd.

Op een andere testsite (nog met 5.1.0) met en_GB (taal administrator) en fr_FR (taal site) komt in de Back-End én in de Front-End deze foute email:

Latest User Actions
This is the latest action performed by a user on your website.
Action    Date    Extension    Name
PLG_SYSTEM_ACTIONLOGS_CONTENT_UPDATED    2024-06-10 08:48:46 UTC    Articles    Luk Thijs

Na upgraden naar 5.1.1. zijn beide emails echter WEL correct. Het issue lijkt dus wel opgepikt te zijn n.a.v. de upgrade naar 5.1.1 maar ik kan hierover geen aanknopingspunt vinden in de lijst met bugfixes en verbeteringen. Niettemin is er dus nog wel een probleem met nl_NL (en misschien ook nog andere talen, maar die heb ik niet getest).
Misschien is dit issue dus taal-gerelateerd en is nl_NL de dupe

Luk

Het ligt niet aan de taalbestanden in ieder geval. Ben er nog niet helemaal uit, maar wil je eens via phpmyadmin kijken in de tabel xxx_mail_templates? Daar moeten alleen constantes staan en geen vertaalde teksten. Als die er staan, dan moet je ze verwijderen.
Als je ze verwijderd hebt, niet aan de mailtemplate komen in de backend, maar wel een artikel wijzigen. Dan zou inhoud van de mail wel goed moeten zijn. Er gaat volgens mij iets niet goed als je de template opent en opslaat al dan niet met wijzigingen. Maar zou graag een bevestiging hebben voordat ik het op github meld.

 

Beste Astrid,

Dank voor al uw tijd om dit issue op te volgen.

Raar maar waar en ik weet niet hoe en wanneer, maar er kwam een correcte mail binnen dat een publisher bezig was artikelen te plaatsen en te bewerken.
Ik ben er zo lang mee bezig geweest en heb diverse instellingen aangepast, dat ik weet niet meer precies weet op welk punt het in orde is gekomen.

Ik voeg een screenshot bij (zie xxx_site1) van de gevraagde PhpMyadmin maar ik zie hier niks speciaals

Om het probleem alsnog te reproduceren en een aanwijzing te vinden wanneer het probleem opduikt, heb ik het hele traject nog eens overgedaan met een andere site.

Deze site was nog 5.1.0, de 2 talen verschillend voor administrator (en_GB) en voor de site (nl_NL) >> kreeg telkens de foute mail.
Dan de mail template geopend zonder bewaren >> nog steeds foute mail.
Dan geupgraded naar 5.1.1 >> correcte mail.
Mail template geopend, spatie ingebracht, terug verwijderd en bewaard >> foute mail.

Ik voeg een screenshot bij (zie www_site2) van de PhpMyadmin en zag hier de 2e lijn in dubbel verschijnen en nu met vertaalde teksten.
Ik heb die lijn verwijderd en een artikel gewijzigd zoals gevraagd en nu komt de correcte mail.

Nogmaals de mail template geopend, spatie ingebracht en terug verwijderd en bewaard >> opnieuw foute mail.

Er gaat dus vermoedelijk iets niet goed na openen en bewerken van de mail template zoals u reeds vermoedde.

Mogelijk kunt u een en ander ook reproduceren, want ik heb zoveel dingen gedaan dat op de duur het overzicht weg is.

Met dank
Luk

Blijft het bij site 1 wel werken als je de mail template opent en opslaat?
Volgens mij heb je daar meer records dan in je screenshot staan.

Zou fijn zijn als er nog een paar leden willen testen.
Ook even hier geplaatst. Graag reageren als je het probleem kunt reproduceren.

En graag in het vervolg beter leesbare screenshots plaatsen.

Beste Astrid,

Ook bij site 1 werkt het niet meer na openen en opslaan van de mailtemplate.

Ik heb op 2 sites exact dezelfde tests gedaan:

• Artikel bewerkt in de Front-End: email OK
• Mailtemplate geopend zonder opslaan: email OK
• Mailtemplate geopend, bewerkt en bewaard: foute email
• De lijn met de vertalingen in PhpMyAdmin verwijderd
• Artikel bewerkt in de Front-End: email terug OK

Er zijn inderdaad meerdere records in PhpMyAdmin, zie van beide sites de screenshots (pagina1 en pagina2).
Op de 2e pagina staat m.i. niets bijzonders.

Sorry voor de screenshots, ik hoop dat ze nu iets beter leesbaar zijn, ik werk momenteel niet op mijn gewone PC en de schermresolutie is niet al te hoog.

Dank om het issue te plaatsen op het forum van joomla.org

Luk

Reageer je zelf ook even op mijn topic op joomla.org s.v.p?
Gewoon aangeven dat je exact hetzelfde probleem hebt. Dan wordt er misschien iets gedaan. Dat issue op github blijft ergens onderaan hangen, ook als ik iets toevoeg, dus ben bang dat niemand daar meer naar kijkt.

Dag Astrid,

Blijkbaar werd dit issue in versie 5.1.2 niet opgepikt door de ontwikkelaars.
Ik heb achtereenvolgens volgende tests gedaan:

In de Backend (en-GB) een artikel aangepast: mail (en-GB) is OK. In de Frontend (nl-NL) aangemeld als publisher en een artikel aangepast: mail (nl-NL) is OK.

In de Backend de beide mail templates van "User Actions Log: Notification Mail (en-GB en nl-NL)" geopend, zonder te editen en zonder te bewaren. In de Backend (en-GB) een artikel aangepast: mail (en-GB) is OK. In de Frontend (nl-NL) een nieuw artikel geschreven: mail (nl-NL) is OK, maar er komt nu wel een bijkomende mail met alleen "COM_MESSAGES_NEW_MESSAGE_BODY" in de body. Ook in de Frontend (nl-NL) een artikel aangepast: mail (nl-NL) is OK. Nu geen bijkomende mail ontvangen met "COM_MESSAGES_NEW_MESSAGE_BODY". Check in PhPMyAdmin: geen bijkomende regels met vertalingen aanwezig.

In de Backend de beide mail templates van "User Actions Log: Notification Mail (en-GB en nl-NL)" geopend, een wijziging aangebracht in de HTML body-tekst en bewaard. Check in PhPMyAdmin: twee bijkomende regels (nl-NL en en-GB) met vertalingen aanwezig. Nu zijn dus alle mails fout en bij het schrijven van een nieuw artikel in de Frontend komt ook de bijkomende mail met "COM_MESSAGES_NEW_MESSAGE_BODY".

Dan heb ik de beide regels in PhpMyAdmin verwijderd en alle mails zijn terug OK. De wijzigingen in de HTML body-tekst van de mail templates zijn nu ook logischerwijze verdwenen.

Dit alles stemt dus overeen met uw bevindingen dat er iets fout is met de afhandeling van de mail templates.

De bijkomende mail met "COM_MESSAGES_NEW_MESSAGE_BODY" verschijnt blijkbaar bij het schrijven een nieuw artikel in de Frontend, en misschien ook nog bij andere handelingen...dat heb ik niet verder getest. Kan u dit reproduceren en weet u toevallig waar die mail vandaan komt, of is dit ook iets dat in hetzelfde issue kadert ?

Vermits ik de enige superuser ben, is dit alles voor mij geen groot probleem en enkel een kwestie van weten, nl. afblijven van de mailtemplates en indien nodig toch de regels in PhPMyAdmin verwijderen, maar niettemin is het een bug die voor andere gebruikers zou moeten opgelost geraken.

Meent u dat het zinvol is dat ik een extra comment plaats bij dit  topic en dan tevens de mail met "COM_MESSAGES_NEW_MESSAGE_BODY" vermeld ? Of liever verder afwachten ?

Luk

Ik herken dit probleem ook op een meertalig website.
Het lijkt erop dat het CMS zich alleen richt op de ingestelde taal die de super user in de back-end gebruikt.
Als er iets voor een andere taal wordt gepubliceerd of bewerkt, dan krijgt de SU een mail met de constante in plaats van de nette tekst.
Ook ik hoop dat de ontwikkelaars van Joomla er een oplossing voor vinden.
Ik zal dit ook in het github issue melden.

Beste Astrid en Wouter,

Ik volg dit topic al geruime tijd en zag ook jullie tussenkomsten op Github #42353 - #43503 - #39228
De enige reactie van de community van Joomla developers kwam van Brian Teeman: "issue is closed", alhoewel dit nog steeds niet is opgelost.

Joomla wordt natuurlijk gemaakt en onderhouden door vrijwilligers, maar helemaal geen reactie is eigenlijk not done.
Het minste dat men zou verwachten is een antwoord zodat men toch iets weet, zoals bijvoorbeeld:
- Issue wordt terug geopend
- Issue zal opgelost worden in de volgende of één van de volgende update(s)
- Issue is niet kritisch genoeg om op korte termijn op te lossen
- Issue zal helemaal niet opgelost worden
- Enz.

Het probleem is m.i. inderdaad niet kritisch en er is een mogelijkheid om te resetten in PhpAdmin, maar het is raar dat men dit niet oppikt. Vanuit jullie jarenlange ervaring: is zoiets gebruikelijk?

Luk