Also: This fixes registration with a team: only the email localpart was being used to register.
When a registration is successful, the user will be joined to rooms specified in the config.json teamsConfig:
"teamsConfig" : {
"supportEmail": "support@riot.im",
"teams": [
{
"name" : "matrix",
"emailSuffix" : "matrix.org",
"rooms" : [
{
"id" : "#irc_matrix:matrix.org",
"autoJoin" : true
}
]
}
]
}
autoJoin can of course be set to false if the room should only be displayed on the (forthcoming) welcome page for each team, and not auto-joined.
* Pressing enter now always adds whatever was in the input box
to the invite list, if it's a valid address (previously it
added it to the list of it was a search result but submitted
the form straight away if there were no results).
* Remove isValidAddress as it was only used in the context of
testing whether its return value was true or null (where null
meant "unsure") so just use getAddressType instead.
* Use binds rather than onFoo functions which aren't actually
handler functions themselves but return them
* Rename onKeyUp to moveSelectionDown etc,, reserving onKeyUp
for "a key has been released" rather than, "the up arrow key
has been pressed"
* Implement simple team-based registration
Config required goes in the `teams` top-level property in config.json. This consists of an array of team objects:
```json
{
"name": "University of Bath",
"emailSuffix": "bath.ac.uk"
}
```
These can be selected on registration and require a user to have a certain email address in order to register as part of a team. This is for vector-im/riot-web#2940. The next step would be sending users with emails matching the emailSuffix of a team to the correct welcome page as in vector-im/riot-web#2430.
We still need to parse "plaintext" messages through the markdown
renderer so that escappes are rendered properly.
Fixesvector-im/riot-web#2870.
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
Add Modal.createDialogAsync, which can be used to display asynchronously-loaded
React components. Also make EncryptedEventDialog use it as a handy
demonstration.
Transition pairs joined,left and left,joined are now transformed into single meta-transitions "joined_and_left" and "left_and_joined" respectively. These are described as "joined and left", "left and rejoined".
Treat consecutive sequences of transitions as repetitions, and handle any arbitrary repetitions of transitions:
...,joined,left,joined,left,joined,left,...
is canonicalised into
...,joined_and_left, joined_and_left, joined_and_left,...
which is truncated and described as
... , joined and left 3 times, ...
This also works if there are multiple consecutive sequences separated by other transitions:
..., banned, banned, banned, joined, unbanned, unbanned, unbanned,...
becomes
... was banned 3 times, joined, was unbanned 3 times ...
The MELS can now deal with arbitrary sequences of transitions per user, where a transition is a change in membership. A transition can be joined, left, invite_reject, invite_withdrawal, invited, banned, unbanned or kicked.
Repeated segments (modulo 1 and 2), such as joined,left,joined,left,joined will be handled and will be rendered as " ... and 10 others joined and left 2 times and then joined". The repeated segments are assumed to be at the beginning of the sequence. This could be improved to handle arbitrary repeated sequences.
This will happen anyway when they follow email verification links.
make captchas poll for success so if they are completed elsewhere, electron moves on
This was causing rendering of MemberEventListSummary to be quite slow. Instead of creating two date objects, just check to see if they represent timestamps that happened on different days.
- The MessagePanel now uses the same key for the MELS instances rendered so that entirely new instances are not created, they are simply passed new props (namely when new events arrive).
- MELS itself now uses `shouldComponentUpdate` so that it only updates if it is given a different number of events to previous or if it is toggled to expand.
