(2024-02-09, 07:42 AM)Laird Wrote: [ -> ]As I commented to you a while back in the DVZ Mentions thread, DVZ Mentions requires MyAlerts 2.0.*. This is over-conservative: it could/should simply require version 2.*.*.
Untested, but I think this can be fixed by changing line 123 of inc/plugins/dvz_mentions/alerts.php from:
if ($version[0] == '2' && $version[1] == '0') {
to
if ($version[0] == '2') {
If that works, we can "mention" it to dvz. 
I forgot I had asked before! Sorry about that.
This fix does work so I will reply to the authors thread for that plugin and link your post. Thank you!
(2024-02-22, 04:54 PM)Taylor M Wrote: [ -> ]I forgot I had asked before! Sorry about that.
This fix does work so I will reply to the authors thread for that plugin and link your post. Thank you!
No worries, and thanks for the feedback.
One thing I've noticed is that the 'MyAlerts Cleanup' task is no longer doing anything. It still says in the Admin CP Task Log that "Read alerts over a week old were deleted successfully!"; however, when I check my read alerts, they're still intact.
Might this be something to do with the fact that I'm running PHP 8.2.15?
It appears that that language string needs to be updated. In fact, the task is deleting:
- Read alerts of 90+ days old.
- Unread alerts of 120+ days old.
It also seems that that language string (and the one for task error messages) needs to be replicated in the user (as opposed to admin) language file, because unless the task is run manually, it runs in a user rather than admin context.
(2024-04-07, 09:42 AM)Laird Wrote: [ -> ]It appears that that language string needs to be updated. In fact, the task is deleting:- Read alerts of 90+ days old.
- Unread alerts of 120+ days old.
It also seems that that language string (and the one for task error messages) needs to be replicated in the user (as opposed to admin) language file, because unless the task is run manually, it runs in a user rather than admin context.
Thanks for the reply
.
Unfortunately, it seems it's not even doing this: my oldest alert was from 21st August 2023, and running the task didn't delete this (or any of my other alerts).
Pressing 'Delete all alerts' on the pop-up did delete all of my alerts; however, I can't expect every member to do this
.
(2024-04-16, 09:32 AM)Kyng Wrote: [ -> ]Thanks for the reply .
No worries. Thanks for the feedback.
(2024-04-16, 09:32 AM)Kyng Wrote: [ -> ]Unfortunately, it seems it's not even doing this: my oldest alert was from 21st August 2023, and running the task didn't delete this (or any of my other alerts).
Ah, I can reproduce this. It seems that the problem is that the
dateline column of the
mybb_alerts table is defined as a
datetime type for MySQL/MariaDB, and - apparently with the same effect - as a
timestamp type for PostgreSQL, but the task code is treating it as the same unsigned int representing a UNIX seconds-since-the-epoch value that MyBB core code uses for dates.
The TL;DR:
In
inc/tasks/myalerts.php, replace :
if ($db->delete_query('alerts', '(dateline<='.(TIME_NOW-$unread_time).' AND unread = 1) OR (dateline<='.(TIME_NOW-$read_time).' AND unread = 0)')) {
with:
if ($db->delete_query('alerts', '(dateline <= \''.date('Y-m-d H:i:s', TIME_NOW-$unread_time).'\' AND unread = 1) OR (dateline <= \''.date('Y-m-d H:i:s', TIME_NOW-$read_time).'\' AND unread = 0)')) {
Tested only on MariaDB; hopefully this works on MySQL and PostgreSQL too though.
Let me know if that works, and if it does, I'll file a PR with the fix.
(2024-04-16, 10:21 AM)Laird Wrote: [ -> ] (2024-04-16, 09:32 AM)Kyng Wrote: [ -> ]Thanks for the reply .
No worries. Thanks for the feedback.
(2024-04-16, 09:32 AM)Kyng Wrote: [ -> ]Unfortunately, it seems it's not even doing this: my oldest alert was from 21st August 2023, and running the task didn't delete this (or any of my other alerts).
Ah, I can reproduce this. It seems that the problem is that the dateline column of the mybb_alerts table is defined as a datetime type for MySQL/MariaDB, and - apparently with the same effect - as a timestamp type for PostgreSQL, but the task code is treating it as the same unsigned int representing a UNIX seconds-since-the-epoch value that MyBB core code uses for dates.
The TL;DR:
In inc/tasks/myalerts.php, replace :
if ($db->delete_query('alerts', '(dateline<='.(TIME_NOW-$unread_time).' AND unread = 1) OR (dateline<='.(TIME_NOW-$read_time).' AND unread = 0)')) {
with:
if ($db->delete_query('alerts', '(dateline <= \''.date('Y-m-d H:i:s', TIME_NOW-$unread_time).'\' AND unread = 1) OR (dateline <= \''.date('Y-m-d H:i:s', TIME_NOW-$read_time).'\' AND unread = 0)')) {
Tested only on MariaDB; hopefully this works on MySQL and PostgreSQL too though.
Let me know if that works, and if it does, I'll file a PR with the fix.
Thanks a lot: that worked perfectly
!
Hello! Using MyAlerts 2.0.2. It looks like there is two errors:
- No alert when somebody votes in a public poll
- No alert when somebody adds you to their buddy list
Is this a known issue or just on my side of things?
(2024-04-23, 11:58 PM)StarredSkies Wrote: [ -> ]Hello! Using MyAlerts 2.0.2.
That's a very old version. The latest version - a beta - is
2.1.0-beta
(2024-04-23, 11:58 PM)StarredSkies Wrote: [ -> ]It looks like there is two errors:
- No alert when somebody votes in a public poll
- No alert when somebody adds you to their buddy list
Is this a known issue or just on my side of things?
I don't know about version 2.0.2, but I've just tested on 2.1.0-beta, and those alerts still seem to be working.