2016-11-09 19:03:35 +03:00
|
|
|
/*
|
|
|
|
Copyright 2016 OpenMarket Ltd
|
2020-07-07 20:30:57 +03:00
|
|
|
Copyright 2019, 2020 The Matrix.org Foundation C.I.C.
|
2019-06-23 23:41:28 +03:00
|
|
|
Copyright 2019 Michael Telatynski <7t3chguy@gmail.com>
|
2016-11-09 19:03:35 +03:00
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
limitations under the License.
|
|
|
|
*/
|
2019-05-20 17:16:12 +03:00
|
|
|
|
2016-11-10 17:08:11 +03:00
|
|
|
import React from 'react';
|
2017-12-26 04:03:18 +03:00
|
|
|
import PropTypes from 'prop-types';
|
2019-09-06 20:35:52 +03:00
|
|
|
import createReactClass from 'create-react-class';
|
2017-05-25 13:39:08 +03:00
|
|
|
import { _t } from '../../../languageHandler';
|
2019-05-20 17:16:12 +03:00
|
|
|
import { formatCommaSeparatedList } from '../../../utils/FormattingUtils';
|
2019-12-20 04:19:56 +03:00
|
|
|
import * as sdk from "../../../index";
|
2019-09-13 12:32:13 +03:00
|
|
|
import {MatrixEvent} from "matrix-js-sdk";
|
2020-07-07 20:30:57 +03:00
|
|
|
import {isValid3pidInvite} from "../../../RoomInvite";
|
2016-11-09 19:03:35 +03:00
|
|
|
|
2019-12-20 03:45:24 +03:00
|
|
|
export default createReactClass({
|
2016-11-09 19:03:35 +03:00
|
|
|
displayName: 'MemberEventListSummary',
|
|
|
|
|
|
|
|
propTypes: {
|
|
|
|
// An array of member events to summarise
|
2019-09-13 12:32:13 +03:00
|
|
|
events: PropTypes.arrayOf(PropTypes.instanceOf(MatrixEvent)).isRequired,
|
2016-11-10 17:12:45 +03:00
|
|
|
// An array of EventTiles to render when expanded
|
2017-12-26 04:03:18 +03:00
|
|
|
children: PropTypes.array.isRequired,
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
// The maximum number of names to show in either each summary e.g. 2 would result "A, B and 234 others left"
|
2017-12-26 04:03:18 +03:00
|
|
|
summaryLength: PropTypes.number,
|
2016-11-09 19:03:35 +03:00
|
|
|
// The maximum number of avatars to display in the summary
|
2017-12-26 04:03:18 +03:00
|
|
|
avatarsMaxLength: PropTypes.number,
|
2016-11-09 19:03:35 +03:00
|
|
|
// The minimum number of events needed to trigger summarisation
|
2017-12-26 04:03:18 +03:00
|
|
|
threshold: PropTypes.number,
|
2017-02-20 13:59:11 +03:00
|
|
|
// Called when the MELS expansion is toggled
|
2017-12-26 04:03:18 +03:00
|
|
|
onToggle: PropTypes.func,
|
2017-09-14 19:53:47 +03:00
|
|
|
// Whether or not to begin with state.expanded=true
|
2017-12-26 04:03:18 +03:00
|
|
|
startExpanded: PropTypes.bool,
|
2016-11-09 19:03:35 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
getDefaultProps: function() {
|
|
|
|
return {
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
summaryLength: 1,
|
2016-11-09 19:03:35 +03:00
|
|
|
threshold: 3,
|
2016-12-14 18:31:35 +03:00
|
|
|
avatarsMaxLength: 5,
|
2016-11-09 19:03:35 +03:00
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2019-09-12 12:54:52 +03:00
|
|
|
shouldComponentUpdate: function(nextProps) {
|
2017-01-16 17:12:00 +03:00
|
|
|
// Update if
|
|
|
|
// - The number of summarised events has changed
|
|
|
|
// - or if the summary is about to toggle to become collapsed
|
|
|
|
// - or if there are fewEvents, meaning the child eventTiles are shown as-is
|
|
|
|
return (
|
|
|
|
nextProps.events.length !== this.props.events.length ||
|
|
|
|
nextProps.events.length < this.props.threshold
|
|
|
|
);
|
|
|
|
},
|
|
|
|
|
2017-01-18 12:26:25 +03:00
|
|
|
/**
|
2019-09-12 12:54:52 +03:00
|
|
|
* Generate the text for users aggregated by their transition sequences (`eventAggregates`) where
|
2017-01-18 12:26:25 +03:00
|
|
|
* the sequences are ordered by `orderedTransitionSequences`.
|
|
|
|
* @param {object[]} eventAggregates a map of transition sequence to array of user display names
|
|
|
|
* or user IDs.
|
|
|
|
* @param {string[]} orderedTransitionSequences an array which is some ordering of
|
|
|
|
* `Object.keys(eventAggregates)`.
|
2019-09-12 12:54:52 +03:00
|
|
|
* @returns {string} the textual summary of the aggregated events that occurred.
|
2017-01-18 12:26:25 +03:00
|
|
|
*/
|
2019-09-12 12:54:52 +03:00
|
|
|
_generateSummary: function(eventAggregates, orderedTransitionSequences) {
|
2017-01-25 14:05:45 +03:00
|
|
|
const summaries = orderedTransitionSequences.map((transitions) => {
|
|
|
|
const userNames = eventAggregates[transitions];
|
|
|
|
const nameList = this._renderNameList(userNames);
|
|
|
|
|
|
|
|
const splitTransitions = transitions.split(',');
|
|
|
|
|
|
|
|
// Some neighbouring transitions are common, so canonicalise some into "pair"
|
|
|
|
// transitions
|
|
|
|
const canonicalTransitions = this._getCanonicalTransitions(splitTransitions);
|
|
|
|
// Transform into consecutive repetitions of the same transition (like 5
|
|
|
|
// consecutive 'joined_and_left's)
|
|
|
|
const coalescedTransitions = this._coalesceRepeatedTransitions(
|
2017-10-11 19:56:17 +03:00
|
|
|
canonicalTransitions,
|
2017-01-25 14:05:45 +03:00
|
|
|
);
|
2016-11-10 17:33:41 +03:00
|
|
|
|
2017-01-25 14:05:45 +03:00
|
|
|
const descs = coalescedTransitions.map((t) => {
|
|
|
|
return this._getDescriptionForTransition(
|
2017-10-18 00:46:23 +03:00
|
|
|
t.transitionType, userNames.length, t.repeats,
|
2017-01-25 14:05:45 +03:00
|
|
|
);
|
2017-01-17 21:07:45 +03:00
|
|
|
});
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
|
2019-05-20 17:16:12 +03:00
|
|
|
const desc = formatCommaSeparatedList(descs);
|
2017-01-17 21:07:45 +03:00
|
|
|
|
2017-10-23 20:55:40 +03:00
|
|
|
return _t('%(nameList)s %(transitionList)s', { nameList: nameList, transitionList: desc });
|
2017-01-17 21:07:45 +03:00
|
|
|
});
|
|
|
|
|
|
|
|
if (!summaries) {
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
return null;
|
2016-11-09 19:03:35 +03:00
|
|
|
}
|
|
|
|
|
2019-09-12 12:54:52 +03:00
|
|
|
return summaries.join(", ");
|
2017-01-17 21:07:45 +03:00
|
|
|
},
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
|
2017-01-18 12:26:25 +03:00
|
|
|
/**
|
|
|
|
* @param {string[]} users an array of user display names or user IDs.
|
|
|
|
* @returns {string} a comma-separated list that ends with "and [n] others" if there are
|
|
|
|
* more items in `users` than `this.props.summaryLength`, which is the number of names
|
|
|
|
* included before "and [n] others".
|
|
|
|
*/
|
2017-01-17 21:07:45 +03:00
|
|
|
_renderNameList: function(users) {
|
2019-05-20 17:16:12 +03:00
|
|
|
return formatCommaSeparatedList(users, this.props.summaryLength);
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
},
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
|
2017-01-18 12:26:25 +03:00
|
|
|
/**
|
2017-01-25 12:18:47 +03:00
|
|
|
* Canonicalise an array of transitions such that some pairs of transitions become
|
|
|
|
* single transitions. For example an input ['joined','left'] would result in an output
|
|
|
|
* ['joined_and_left'].
|
|
|
|
* @param {string[]} transitions an array of transitions.
|
|
|
|
* @returns {string[]} an array of transitions.
|
2017-01-18 12:26:25 +03:00
|
|
|
*/
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
_getCanonicalTransitions: function(transitions) {
|
2017-01-25 14:05:45 +03:00
|
|
|
const modMap = {
|
|
|
|
'joined': {
|
|
|
|
'after': 'left',
|
|
|
|
'newTransition': 'joined_and_left',
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
},
|
2017-01-25 14:05:45 +03:00
|
|
|
'left': {
|
|
|
|
'after': 'joined',
|
|
|
|
'newTransition': 'left_and_joined',
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
},
|
|
|
|
// $currentTransition : {
|
|
|
|
// 'after' : $nextTransition,
|
|
|
|
// 'newTransition' : 'new_transition_type',
|
|
|
|
// },
|
|
|
|
};
|
|
|
|
const res = [];
|
|
|
|
|
|
|
|
for (let i = 0; i < transitions.length; i++) {
|
2017-01-25 14:05:45 +03:00
|
|
|
const t = transitions[i];
|
|
|
|
const t2 = transitions[i + 1];
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
|
|
|
|
let transition = t;
|
|
|
|
|
|
|
|
if (i < transitions.length - 1 && modMap[t] && modMap[t].after === t2) {
|
|
|
|
transition = modMap[t].newTransition;
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
|
|
|
res.push(transition);
|
|
|
|
}
|
|
|
|
return res;
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
},
|
|
|
|
|
2017-01-18 12:26:25 +03:00
|
|
|
/**
|
|
|
|
* Transform an array of transitions into an array of transitions and how many times
|
|
|
|
* they are repeated consecutively.
|
|
|
|
*
|
|
|
|
* An array of 123 "joined_and_left" transitions, would result in:
|
|
|
|
* ```
|
|
|
|
* [{
|
|
|
|
* transitionType: "joined_and_left"
|
|
|
|
* repeats: 123
|
2017-01-25 12:28:26 +03:00
|
|
|
* }]
|
2017-01-18 12:26:25 +03:00
|
|
|
* ```
|
|
|
|
* @param {string[]} transitions the array of transitions to transform.
|
2017-01-25 12:28:26 +03:00
|
|
|
* @returns {object[]} an array of coalesced transitions.
|
2017-01-18 12:26:25 +03:00
|
|
|
*/
|
2017-01-25 12:28:26 +03:00
|
|
|
_coalesceRepeatedTransitions: function(transitions) {
|
2017-01-25 14:05:45 +03:00
|
|
|
const res = [];
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
for (let i = 0; i < transitions.length; i++) {
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
if (res.length > 0 && res[res.length - 1].transitionType === transitions[i]) {
|
|
|
|
res[res.length - 1].repeats += 1;
|
|
|
|
} else {
|
|
|
|
res.push({
|
|
|
|
transitionType: transitions[i],
|
|
|
|
repeats: 1,
|
|
|
|
});
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
}
|
2016-11-09 19:03:35 +03:00
|
|
|
}
|
Canonicalise certain transition pairs, handle arbitrary consecutive transitions
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 ...
2017-01-16 16:49:07 +03:00
|
|
|
return res;
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
},
|
2016-11-10 17:33:41 +03:00
|
|
|
|
2017-01-17 21:07:45 +03:00
|
|
|
/**
|
|
|
|
* For a certain transition, t, describe what happened to the users that
|
|
|
|
* underwent the transition.
|
2017-01-18 12:26:25 +03:00
|
|
|
* @param {string} t the transition type.
|
2019-09-12 12:54:52 +03:00
|
|
|
* @param {number} userCount number of usernames
|
2017-01-18 12:26:25 +03:00
|
|
|
* @param {number} repeats the number of times the transition was repeated in a row.
|
2017-05-23 17:16:31 +03:00
|
|
|
* @returns {string} the written Human Readable equivalent of the transition.
|
2017-01-17 21:07:45 +03:00
|
|
|
*/
|
2017-10-18 00:46:23 +03:00
|
|
|
_getDescriptionForTransition(t, userCount, repeats) {
|
2017-05-23 17:16:31 +03:00
|
|
|
// The empty interpolations 'severalUsers' and 'oneUser'
|
|
|
|
// are there only to show translators to non-English languages
|
|
|
|
// that the verb is conjugated to plural or singular Subject.
|
2017-01-17 21:07:45 +03:00
|
|
|
let res = null;
|
2017-11-16 16:19:36 +03:00
|
|
|
switch (t) {
|
2017-05-23 17:16:31 +03:00
|
|
|
case "joined":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)sjoined %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)sjoined %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "left":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)sleft %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)sleft %(count)s times", { oneUser: "", count: repeats });
|
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "joined_and_left":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)sjoined and left %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)sjoined and left %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "left_and_joined":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)sleft and rejoined %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)sleft and rejoined %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "invite_reject":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)srejected their invitations %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)srejected their invitation %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "invite_withdrawal":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)shad their invitations withdrawn %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)shad their invitation withdrawn %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "invited":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("were invited %(count)s times", { count: repeats })
|
|
|
|
: _t("was invited %(count)s times", { count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "banned":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("were banned %(count)s times", { count: repeats })
|
|
|
|
: _t("was banned %(count)s times", { count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "unbanned":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("were unbanned %(count)s times", { count: repeats })
|
|
|
|
: _t("was unbanned %(count)s times", { count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "kicked":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("were kicked %(count)s times", { count: repeats })
|
|
|
|
: _t("was kicked %(count)s times", { count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "changed_name":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)schanged their name %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)schanged their name %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2017-05-23 17:16:31 +03:00
|
|
|
case "changed_avatar":
|
2017-10-18 00:46:23 +03:00
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)schanged their avatar %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)schanged their avatar %(count)s times", { oneUser: "", count: repeats });
|
2017-06-10 00:19:14 +03:00
|
|
|
break;
|
2019-06-23 23:41:28 +03:00
|
|
|
case "no_change":
|
|
|
|
res = (userCount > 1)
|
|
|
|
? _t("%(severalUsers)smade no changes %(count)s times", { severalUsers: "", count: repeats })
|
|
|
|
: _t("%(oneUser)smade no changes %(count)s times", { oneUser: "", count: repeats });
|
|
|
|
break;
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
}
|
|
|
|
|
2017-01-17 21:07:45 +03:00
|
|
|
return res;
|
|
|
|
},
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
|
2017-01-17 21:07:45 +03:00
|
|
|
_getTransitionSequence: function(events) {
|
|
|
|
return events.map(this._getTransition);
|
2016-12-14 18:31:35 +03:00
|
|
|
},
|
2016-11-09 19:03:35 +03:00
|
|
|
|
2017-01-18 12:26:25 +03:00
|
|
|
/**
|
2017-01-25 12:32:28 +03:00
|
|
|
* Label a given membership event, `e`, where `getContent().membership` has
|
2017-01-18 12:26:25 +03:00
|
|
|
* changed for each transition allowed by the Matrix protocol. This attempts to
|
2017-01-25 12:32:28 +03:00
|
|
|
* label the membership changes that occur in `../../../TextForEvent.js`.
|
|
|
|
* @param {MatrixEvent} e the membership change event to label.
|
2017-01-18 12:26:25 +03:00
|
|
|
* @returns {string?} the transition type given to this event. This defaults to `null`
|
|
|
|
* if a transition is not recognised.
|
|
|
|
*/
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
_getTransition: function(e) {
|
2019-07-03 10:58:34 +03:00
|
|
|
if (e.mxEvent.getType() === 'm.room.third_party_invite') {
|
|
|
|
// Handle 3pid invites the same as invites so they get bundled together
|
2020-07-07 20:30:57 +03:00
|
|
|
if (!isValid3pidInvite(e.mxEvent)) {
|
|
|
|
return 'invite_withdrawal';
|
|
|
|
}
|
2019-07-03 10:58:34 +03:00
|
|
|
return 'invited';
|
|
|
|
}
|
|
|
|
|
2017-01-16 20:46:17 +03:00
|
|
|
switch (e.mxEvent.getContent().membership) {
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
case 'invite': return 'invited';
|
|
|
|
case 'ban': return 'banned';
|
2017-04-23 06:05:50 +03:00
|
|
|
case 'join':
|
|
|
|
if (e.mxEvent.getPrevContent().membership === 'join') {
|
|
|
|
if (e.mxEvent.getContent().displayname !==
|
2017-10-11 19:56:17 +03:00
|
|
|
e.mxEvent.getPrevContent().displayname) {
|
2017-04-23 06:05:50 +03:00
|
|
|
return 'changed_name';
|
2017-10-11 19:56:17 +03:00
|
|
|
} else if (e.mxEvent.getContent().avatar_url !==
|
|
|
|
e.mxEvent.getPrevContent().avatar_url) {
|
2017-04-23 06:05:50 +03:00
|
|
|
return 'changed_avatar';
|
|
|
|
}
|
2017-04-25 02:17:46 +03:00
|
|
|
// console.log("MELS ignoring duplicate membership join event");
|
2019-06-23 23:41:28 +03:00
|
|
|
return 'no_change';
|
2017-10-11 19:56:17 +03:00
|
|
|
} else {
|
2017-04-23 06:05:50 +03:00
|
|
|
return 'joined';
|
|
|
|
}
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
case 'leave':
|
2017-01-16 20:46:17 +03:00
|
|
|
if (e.mxEvent.getSender() === e.mxEvent.getStateKey()) {
|
|
|
|
switch (e.mxEvent.getPrevContent().membership) {
|
2017-01-25 14:05:45 +03:00
|
|
|
case 'invite': return 'invite_reject';
|
|
|
|
default: return 'left';
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
}
|
|
|
|
}
|
2017-01-16 20:46:17 +03:00
|
|
|
switch (e.mxEvent.getPrevContent().membership) {
|
2017-01-25 14:05:45 +03:00
|
|
|
case 'invite': return 'invite_withdrawal';
|
|
|
|
case 'ban': return 'unbanned';
|
2019-07-10 10:57:00 +03:00
|
|
|
// sender is not target and made the target leave, if not from invite/ban then this is a kick
|
|
|
|
default: return 'kicked';
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
}
|
|
|
|
default: return null;
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2017-01-18 12:59:19 +03:00
|
|
|
_getAggregate: function(userEvents) {
|
|
|
|
// A map of aggregate type to arrays of display names. Each aggregate type
|
|
|
|
// is a comma-delimited string of transitions, e.g. "joined,left,kicked".
|
|
|
|
// The array of display names is the array of users who went through that
|
|
|
|
// sequence during eventsToRender.
|
2017-01-25 14:05:45 +03:00
|
|
|
const aggregate = {
|
2017-01-18 12:59:19 +03:00
|
|
|
// $aggregateType : []:string
|
|
|
|
};
|
|
|
|
// A map of aggregate types to the indices that order them (the index of
|
|
|
|
// the first event for a given transition sequence)
|
2017-01-25 14:05:45 +03:00
|
|
|
const aggregateIndices = {
|
2017-01-18 12:59:19 +03:00
|
|
|
// $aggregateType : int
|
|
|
|
};
|
|
|
|
|
2017-01-25 14:05:45 +03:00
|
|
|
const users = Object.keys(userEvents);
|
2017-01-18 12:59:19 +03:00
|
|
|
users.forEach(
|
|
|
|
(userId) => {
|
2017-01-25 14:05:45 +03:00
|
|
|
const firstEvent = userEvents[userId][0];
|
|
|
|
const displayName = firstEvent.displayName;
|
2017-01-18 12:59:19 +03:00
|
|
|
|
2017-01-25 14:05:45 +03:00
|
|
|
const seq = this._getTransitionSequence(userEvents[userId]);
|
2017-01-18 12:59:19 +03:00
|
|
|
if (!aggregate[seq]) {
|
|
|
|
aggregate[seq] = [];
|
|
|
|
aggregateIndices[seq] = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
aggregate[seq].push(displayName);
|
|
|
|
|
2017-01-25 14:05:45 +03:00
|
|
|
if (aggregateIndices[seq] === -1 ||
|
|
|
|
firstEvent.index < aggregateIndices[seq]) {
|
|
|
|
aggregateIndices[seq] = firstEvent.index;
|
2017-01-18 12:59:19 +03:00
|
|
|
}
|
2017-10-11 19:56:17 +03:00
|
|
|
},
|
2017-01-18 12:59:19 +03:00
|
|
|
);
|
|
|
|
|
|
|
|
return {
|
|
|
|
names: aggregate,
|
|
|
|
indices: aggregateIndices,
|
|
|
|
};
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
},
|
|
|
|
|
2016-12-14 18:31:35 +03:00
|
|
|
render: function() {
|
2017-01-25 14:05:45 +03:00
|
|
|
const eventsToRender = this.props.events;
|
2016-12-14 18:31:35 +03:00
|
|
|
|
2017-01-18 12:26:25 +03:00
|
|
|
// Map user IDs to an array of objects:
|
2017-01-25 14:05:45 +03:00
|
|
|
const userEvents = {
|
2017-01-18 12:26:25 +03:00
|
|
|
// $userId : [{
|
|
|
|
// // The original event
|
|
|
|
// mxEvent: e,
|
|
|
|
// // The display name of the user (if not, then user ID)
|
|
|
|
// displayName: e.target.name || userId,
|
|
|
|
// // The original index of the event in this.props.events
|
|
|
|
// index: index,
|
|
|
|
// }]
|
2016-12-14 18:31:35 +03:00
|
|
|
};
|
|
|
|
|
2017-01-25 14:05:45 +03:00
|
|
|
const avatarMembers = [];
|
2017-01-16 20:46:17 +03:00
|
|
|
eventsToRender.forEach((e, index) => {
|
2017-01-11 20:03:14 +03:00
|
|
|
const userId = e.getStateKey();
|
2016-12-14 18:31:35 +03:00
|
|
|
// Initialise a user's events
|
|
|
|
if (!userEvents[userId]) {
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
userEvents[userId] = [];
|
2017-02-17 19:35:18 +03:00
|
|
|
if (e.target) avatarMembers.push(e.target);
|
2016-12-14 18:31:35 +03:00
|
|
|
}
|
2019-07-03 10:58:34 +03:00
|
|
|
|
|
|
|
let displayName = userId;
|
|
|
|
if (e.getType() === 'm.room.third_party_invite') {
|
|
|
|
displayName = e.getContent().display_name;
|
|
|
|
} else if (e.target) {
|
|
|
|
displayName = e.target.name;
|
|
|
|
}
|
|
|
|
|
2017-01-16 20:46:17 +03:00
|
|
|
userEvents[userId].push({
|
|
|
|
mxEvent: e,
|
2019-07-03 10:58:34 +03:00
|
|
|
displayName,
|
2017-01-16 20:46:17 +03:00
|
|
|
index: index,
|
|
|
|
});
|
2016-12-14 18:31:35 +03:00
|
|
|
});
|
2016-11-09 19:03:35 +03:00
|
|
|
|
2017-01-25 14:05:45 +03:00
|
|
|
const aggregate = this._getAggregate(userEvents);
|
Overhaul MELS to deal with causality, kicks, etc.
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.
2017-01-12 21:55:53 +03:00
|
|
|
|
2017-01-16 20:46:17 +03:00
|
|
|
// Sort types by order of lowest event index within sequence
|
2017-01-25 14:05:45 +03:00
|
|
|
const orderedTransitionSequences = Object.keys(aggregate.names).sort(
|
2017-10-11 19:56:17 +03:00
|
|
|
(seq1, seq2) => aggregate.indices[seq1] > aggregate.indices[seq2],
|
2017-01-25 14:05:45 +03:00
|
|
|
);
|
2016-11-09 19:03:35 +03:00
|
|
|
|
2019-09-12 12:54:52 +03:00
|
|
|
const EventListSummary = sdk.getComponent("views.elements.EventListSummary");
|
|
|
|
return <EventListSummary
|
|
|
|
events={this.props.events}
|
|
|
|
threshold={this.props.threshold}
|
|
|
|
onToggle={this.props.onToggle}
|
|
|
|
startExpanded={this.props.startExpanded}
|
|
|
|
children={this.props.children}
|
|
|
|
summaryMembers={avatarMembers}
|
|
|
|
summaryText={this._generateSummary(aggregate.names, orderedTransitionSequences)} />;
|
2016-11-09 19:03:35 +03:00
|
|
|
},
|
|
|
|
});
|