View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003304 | Composr | core_notifications | public | 2017-06-03 18:29 | 2017-06-05 10:42 |
| Reporter | Patrick Schmalstig | Assigned To | Chris Graham | ||
| Severity | Minor-bug | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0003304: notifications.php mark read returns 500 error in specific conditions | ||||
| Description | data/notifications.php will return 500 internal server error when trying to mark periodic review notifications of items that were deleted as read. This bug was specifically confirmed for periodic reviews of members. If I have a period review notification for one of my members, but I had deleted that member, attempting to mark the notification as read will cause AJAX to return a 500 error... the notification never gets marked read. | ||||
| Tags | No tags attached. | ||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
I don't follow. If you have deleted a member, how is that member marking a notification read? I don't believe we have a feature to mark a specific notification read either, only all notifications. And that code is extremely simple, just two lines. I'd also want to see the error message from the error log, or extracted from the browser network log. |
|
|
Unfortunately, 500 internal errors are very vague and often do not contain helpful information, such as this case. This is all I have in logs: 2017-06-05 03:13:08 Error (my IP) 500 GET /data/notifications.php?type=poller&type=mark_all_read&max=5&time_barrier=null&forced_update=1&keep_session=3034d8a00bde2 HTTP/1.1 https://www.lovinity.org/start.htm Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Dragon/57.0.2987.93 Chrome/57.0.2987.88 Safari/537.36 108 K nginx SSL/TLS access Composr has no error logs in this... and the web browser console simply spits out that this request returned a 500 error. Basically what happens is the following: say if I have a user. This user has periodic reviews enabled on the account. I receive a web notification about reviewing this account, but I do not yet mark it as read. Instead, I delete the member account because it was inactive. Now that the member account that the periodic review notification points to is deleted, trying to mark that periodic review notification as read using "mark all read" fails with the 500 error. It is permanently in my notifications as unread. |
|
|
Perhaps maybe periodic review notifications were not meant to get marked as read and are automatically read when taken care of in the content edit screen? If so, I still find it a bit odd that it throws a 500 instead of simply not doing anything. |
|
|
It's a real bug, but most of the report isn't related. "time_barrier=null" was the clue. I'm not sure the exact trigger but I think my 18eabed5b commit is a fix. I think maybe a JS error happened before the notification init finished, leading to time_barrier being null rather than the current timestamp, causing an error when Composr init read that parameter during the mark unread operation. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-06-03 18:29 | Patrick Schmalstig | New Issue | |
| 2017-06-04 20:03 | Chris Graham | Note Added: 0005117 | |
| 2017-06-04 20:03 | Chris Graham | Status | non-assigned => closed |
| 2017-06-04 20:03 | Chris Graham | Assigned To | => Chris Graham |
| 2017-06-04 20:03 | Chris Graham | Resolution | open => suspended |
| 2017-06-05 07:17 | Patrick Schmalstig | Note Added: 0005124 | |
| 2017-06-05 07:17 | Patrick Schmalstig | Note Edited: 0005124 | View Revisions |
| 2017-06-05 07:24 | Patrick Schmalstig | Note Added: 0005126 | |
| 2017-06-05 10:42 | Chris Graham | Note Added: 0005127 | |
| 2017-06-05 10:42 | Chris Graham | Status | closed => resolved |
| 2017-06-05 10:42 | Chris Graham | Resolution | suspended => fixed |
