![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Question about the inbox
Jun. 21st, 2013 08:52 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stormeriderI'm working on Azz's bug 4995 today and got it partway squared away on my hack. However, something that I'm not sure about how to do is to auto-collapse the entry even if it's unread.
The main problem I'm seeing is that the InboxFolder widget can take multiple event types, and different event types don't necessarily have a "other_u" field. UserMessageRecvd does, but I'm not sure if it makes sense to add code specific to that to the Inbox folder widget. Unlike a lot of the other pieces of this, the read status is based on the notification, not the message, so it doesn't get passed down to UserMessageRecvd for parsing (which makes sense) like as_html* stuff does.
Thoughts? I'm sure I can kludge something into place, but I'm not looking to be kludgy :) And I don't want to skip the collapsing part, either, because if messages come in from a suspended user (which I'm guessing in the original case was simply a worker delay), or if someone looks at their inbox after the user has been suspended, then it's a Good Thing to not show the message by default (in cases of spam or other abuse).
EDIT: Nevermind, Denise updated the bug with a clarification that the entire message goes poof for legal reasons, so this goes back to being easy :)
The main problem I'm seeing is that the InboxFolder widget can take multiple event types, and different event types don't necessarily have a "other_u" field. UserMessageRecvd does, but I'm not sure if it makes sense to add code specific to that to the Inbox folder widget. Unlike a lot of the other pieces of this, the read status is based on the notification, not the message, so it doesn't get passed down to UserMessageRecvd for parsing (which makes sense) like as_html* stuff does.
Thoughts? I'm sure I can kludge something into place, but I'm not looking to be kludgy :) And I don't want to skip the collapsing part, either, because if messages come in from a suspended user (which I'm guessing in the original case was simply a worker delay), or if someone looks at their inbox after the user has been suspended, then it's a Good Thing to not show the message by default (in cases of spam or other abuse).
EDIT: Nevermind, Denise updated the bug with a clarification that the entire message goes poof for legal reasons, so this goes back to being easy :)
