Skip to content

Conversation

@malakada
Copy link

@malakada malakada commented Jan 7, 2015

I'm wondering if it makes sense to continue sending potentially undefined variables here (reason and actor), or it we should consider something like this:

Kick/ban:

presence: {
  type: "kick|ban",
  actor: (Candy.Core.Contact),
  reason: (String)
};

Leave:

presence: {
  type: "leave"
}

@malakada malakada changed the title [WIP] candy:core.presence.leave [WIP] candy:core.presence.leave triggerHandler Jan 7, 2015
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tricky thing here is that the moderator does not necessarily need to be in the room at the time that she kicks another user who is.

@bklang How much do we care to deal with this edge case?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah, there's also a bug here, it should read: Candy.Core.getRoster().get(actor);. :)

Could be as simple as checking to see if the actor exists? I generally feel like fixing edge case bugs helps prevent strange/tricky bugs in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it doesn't exist in our roster, we'd have to do similarly to elsewhere and allocate a temporary object. We should extract this somewhere common.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is new Candy.Core.Contact not common enough? Where would you stick something like this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants