Verschieben von Beiträgen erzeugt fehlerhafte Benachrichtigungen

Der Grund für dieses Verhalten liegt in der internen Funktionsweise:

• Die Benachrichtigung für eine neue Antwort basiert auf dem Beitrag und nicht dem Thema selbst
• Der Hash für die Zuordnung wird mit der ID des Themas gebildet und zur Lebenszeit der Benachrichtigung nicht mehr verändert
• Das in der Benachrichtigung angezeigte Thema basiert auf den Informationen aus der Datenbank zum Beitrag, nach dem Verschieben ändert sich diese Information
• Beim erneuten Antworten auf Thema A (siehe Schritt 6) wird der für das Stacking relevante Hash gebildet, dieser stimmt mit der ursprünglichen Benachrichtigung aus Schritt 2 überein (siehe Punkt 2 meiner Auflistung)

Das Problem ist aber nur temporär, sobald die Benachrichtigung aus Schritt 2 als gelesen markiert wird ist der Spuk vorbei. Die Benachrichtigung wäre dann zwar immer noch zum Teil falsch, aber alle nachfolgenden Benachrichtigungen zu Thema A werden neu erzeugt.

Ich bin an dieser Stelle unschlüssig wie wir damit verfahren sollen, der Aufwand dies zuverlässig zu verhindern ist sehr hoch und rein aus dem Bauch heraus ist dieses Szenario nicht besonders wahrscheinlich.

Quote from A.Langer

Soll heißen, was halbes liefern und keinen Wert darauf legen was der User sich wünscht ? Oder lese ich das gerade falsch?

Es handelt sich dabei um einen Grenzfall der durch die interne Verarbeitung und Zuweisung der Benachrichtigungen zu bestimmten Objekten zu Stande kommt. Mein Kommentar ist eher eine Art Notiz, da es für dieses Problem schlichtweg keine einfache Lösung gibt.

Genau genommen gibt es dieses Problem bereits seit WCF 2.0 (bzw. seit dem Notification-System für @Hawkes für WCF 1.1 auf dem es initial basierte), nur waren dort die Auswirkungen weniger offensichtlich. Das gleiche Szenario würde in Burning Board 4.0 beispielsweise dazu führen, dass vom System keine Benachrichtigung für neue Beiträge in dem Thema erzeugt wird, vorausgesetzt die andere Benachrichtigung ist noch ungelesen. Es tritt auch in diesem Fall maximal beim Verschieben von Beiträgen auf und nicht bei allen anderen Fällen, ein Grund warum dieses Problem so lange unentdeckt blieb.