Now it's just a means of choosing users and all the actual inviting
functionality is moved out to Invite.js. This will allow us to
reuse it for inviting to groups.
Adds the ability to restrict what types of addresses may be chosen,
although this isn;t used yet, it will be necessary for groups
because groups don't support 3pid invites.
instead of using the converted matrix.to href. This is undesirable and a better solution would be to fix routing in Riot in general and then change user pills to do something like `/room/../member/@userId`.
the RightPanel will be mounted once we're done doing the first sync, so wait until then and then dispatch a view_user. This is not very nice but it's what we do for view_room.
Adding `override: true` will remove the feature from the labs section, and force Riot to always use the default value (i.e. ignoring localStorage). This is useful removing features entirely when they might be deliberately not working but we still want to do a release.
With the fallback of existing behaviour, which is UserView (no middle panel and no avatar, display name).
To improve, MemberInfo should probably track the current roomId and userId and then update the view asynchronously by re-fetching the member object when either roomId or userId change.
Also, it should be hitting the profile API to get the user's avatar if a room hasn't been specified.
because using `body` gives inconsistent results - sometimes it will contain markdown and sometimes not, and this may not correspond with the `formatted_body`.
TODO: Do quoting proper - using `in_response_to`.
This is mostly with the intent of making the login tests more reliable, but it
seems generally worthwhile:
* keep screenAfterLogin in the object props rather than `state` so that we can
clear it without triggering a rerender
* also move our record of the window width to the object props, and call
`handleResize` from componentWillMount rather than componentDidMount so that
we don't trigger a rerender by updating `state.width`
* Remove update of unused `loading` state
Previously, we were special-casing outgoing messages such that they were shown
as encrypted even when encryption had failed for some reason.
There's no need for this: outgoing messages have a working isEncrypted() method
which we can use to show whether the event has been encrypted yet. Arguably we
could do better than an open padlock for events in the 'encrypting' send state,
but I'm not really sure what.
Michael Telatynski