[#000272] Neu registrierte Mitglieder können sofort Beiträge schreiben [#000279] Profil eines Benutzers läßt sich in der Mitgliederliste nicht aufrufen

[16.10.2010] Archilles
Bericht erstellt
Zugewiesen an: Archilles

[19.10.2010] Gast
Kommentar 278 verfasst

[21.10.2010] Archilles
Gruppe: Konto - Registrierung » Sonstiges - Private Nachricht
Priorität: Sehr Niedrig » Normal
Reproduzierbarkeit: N/A » Immer
Schwere: N/A » Kleiner Fehler
Status: Neu » Bestätigt

[26.10.2010] Archilles
Kommentar 282 verfasst

[26.10.2010] Archilles
Fortschritt: 0% » 50%
Status: Bestätigt » In Arbeit

[14.11.2010] Archilles
Fortschritt: 50% » 100%
Status: In Arbeit » Behoben

[21.10.2011] Archilles
Status: Behoben » Geschlossen
 · PN's werden nicht als gelesen markiert
Eintrag-Nummer #000274
Für folgende Versionen bestätigt (andere unbetroffen/unbekannt)

[Sa, 16.10.2010 @ 12:20h UTC    #000274] Archilles
PM's are not marked as read, either. What I mean is, for at least me as the administrator, after I view a Private Message it is no longer automatically marked as being read (previously viewed).

[Di, 19.10.2010 @ 00:30h UTC    #000278] Gast
All right, I investigated the "PM marked read" issue further and found the source of the problem. The bug appears to not be an issue of whether someone is an admin or a non-admin user, but rather a case of case-sensitivity.

For example, if a user is named "Ned" and someone sends a Private Message (PN) to "Ned" (notice the uppercase letter), the PN will be sent to the right person and the message will be marked as read. If a user is named "Ned" and someone sends a PN to "ned" (notice the lowercase letter), the PN will be sent to the right person *but* the message will not be marked as read.

[Di, 26.10.2010 @ 13:02h UTC    #000282] Archilles
I see. In this case, it has a simple workaround. Just look at the "privmsg.php" around line 245. There you'll find the variable "pm_is_owner" and an if clause. Edit it:
if ( strtolower($sqlr__message['pmd_recipient']) == strtolower($USR['USERNAME']) )

This bug has implications on other code parts, too. The PN-Addressbook can be filled with "invalid" users. Or the ACL-Subsystem does not see "Archilles" and "archilles" as the same user. Some links contain "wrong" usernames once inserted. And so on.

It's caused by MySQL. If you ask it, get me all data of "archilles", it will return them although the name is "Archilles". Apparently the database is case-insensitive (unless BINARY is used for strings). But any (binary) comparison in source code fails. "Archilles" and "archilles" are not the same. It would be fair to say that MySQL's bevaviour is correct and I'm a bit careless. So, it has to be fixed :)

Zurück zur Liste