This changes the default behaviour of displaying the room directory to instead displaying the default homepage. If specified, the config "welcomePageUrl" can be used to override the default '/home.html'.
This allows for a truely flux-y way of storing the currently viewed room, making some callbacks (like onRoomIdResolved) redundant and making sure that the currently viewed room (ID) is only stored in one place as opposed to the previous many places.
This was required for the `join_room` action which can be dispatched to join the currently viewed room.
Another change was to introduce `LifeCycleStore` which is a start at encorporating state related to the lifecycle of the app into a flux store. Currently it only contains an action which will be dispatched when the sync state has become PREPARED. This was necessary to do a deferred dispatch of `join_room` following the registration of a PWLU (PassWord-Less User).
The following actions are introduced:
- RoomViewStore:
- `view_room`: dispatch to change the currently viewed room ID
- `join_room`: dispatch to join the currently viewed room
- LifecycleStore:
- `do_after_sync_prepared`: dispatch to store an action which will be dispatched when `sync_state` is dispatched with `state = 'PREPARED'`
- MatrixChat:
- `sync_state`: dispatched when the sync state changes. Ideally there'd be a SyncStateStore that emitted an `update` upon receiving this, but for now the `LifecycleStore` will listen for `sync_state` directly.
This will shift focus to the welcome user DM.
We probably don't want to do this for teams, but I shall leave that for another PR that fixes teams WRT to new-guest-access.
This will shift focus to the welcome user DM.
We probably don't want to do this for teams, but I shall leave that for another PR that fixes teams WRT to new-guest-access.
This wraps session-related state into a basic flux store. The localStorage item 'mx_pass' is the only thing managed by this store for now but it could easily be extended to track other items (like the teamToken which is passed around through props a lot)
- Replaces SetDisplayNameDialog with SetMxIdDialog. This new dialog will use InteractiveAuth to authenticate a user with their chosen mxid.
De-scoped:
- style tweaks for the InteractiveAuth in the dialog (capcha) and error message.
- checking for mxid availability
This was an issue because guests do not log in with a teamToken, it is implicitly set by MatrixChat when it mounts. The fix is to view_home_page when a login occurs and MatrixChat has this._teamToken set.
- Create a promise that will serve as a lock to be blocked on by things that need to wait for the first sync before accessing state.
- Use this promise to block `view_room` calls until a sync has occured instead of just dropping them silently if the sync hasn't happened yet.
- Store the current room ID in a localStorage item `mx_last_room_id` when `view_room` fires. This persists the last viewed room ID so that it can be restored on refresh, browser quit. This replaces the previous logic which set the room following a sync based on the most recent unread room.
MatrixChat was trying to display an error if the session failed to
restore, but it was never actually being shown because it was just
set as a member variable and therefore never actually caused
a re-render for the error to be displayed. Almost all errors are
caught by _restoreFromLocalStorage which displays the fancy dialog
if your session can't be restored, so I'm not convinced this ever
even tried to do anything anyway. Remove it.
Specifically:
```
JS 2.1.1 (Linux 0.0.0) joining a room over federation should not get stuck at a spinner FAILED
Did not find exactly one match (found: 0) for componentType:function (props, context, updater) {
```
actually meant that the room directory wasn't displayed - probably because the dispatch `view_room_directory` ended up on another tick of the event loop, meaning that the directory wasn't displayedi. The fix attempted in ths commit is to use `this._setPage` instead to view the directory. This uses `setState` to set the screen to the directory, so I'm not entirely convinced this will solve the problem (as `setState` may also end up doing things on another tick.
and
```
JS 2.1.1 (Linux 0.0.0) loading: MatrixClient rehydrated from stored credentials: shows a room view if we followed a room link FAILED
MatrixChat still not ready after 5 tries
awaitRoomView@/home/travis/build/vector-im/riot-web/test/all-tests.js:201363:90
```
was happening probably because in the handler for the `sync` event in `MatrixChat` (around line 840), there was one case in which the `ready` state may not be true (causing all 5 attempts to fail), and this case relied on `starting_room_alias_payload`. This `starting_room_alias_payload` is now redundant because of `initialScreenAfterLogin`, which was added recently.
To prevent the login screen from flashing when refreshing the app, use some state to indicate that a login is in progress, and OR that with the existing `loading` boolean to show the `<Spinner>` instead of the default `<Login>`.
This might be too invasive, and a default spinner may be better.
_onLoadCompleted happens straight away because Lifecycle finishes loading the session instantly when registration parameters (client_secret etc.) are set.
This follows from a small amount of refactoring done when RTS was introduced. Instead of setting the screen after sync, do it only after login.
This requires as-yet-to-be-PRd riot-web changes.
This includes:
- initialScreenAfterLogin, which can be used to set the screen after login, and represents the screen that would be viewed if the window.location at the time of initialising Riot were routed.
- guestCreds are now part of state, because otherwise they don't cause the login/registration views to update when set.
- instead of worrying about races and using this._setPage, use a dispatch.
Use the on_logged_in dispatch instead. Call setPage in one place, _onLoggedIn, when deciding which page to view on login. Change some require to import, var to const. Remove onTeamMemberRegistered and just use a nullable argument to onRegistered
For example, if someone ends up on /home somehow, just redirect to the directory instead of displaying a very awkward "File not found" plain text in the home page iFrame.
Use the first path segment to key off config.teamTokenMap, which contains a mapping to teamTokens. The client then behaves as before, keeping the path in the address bar constant with no redirects required.
Now that the RTS contains config for teams, use GET /teams to get that information so that users will see be able to register as a team (but not yet auto-join rooms, be sent to welcome page or be tracked as a referral).
* 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.
* Render attachments inside iframes.
* Fix up the image and video views
* Fix m.audio
* Comments, and only use the cross domain renderer if the attachment is encrypted
* Fix whitespace
* Don't decrypt file attachments immediately
* Use https://usercontent.riot.im/v1.html by default
* typos
* Put the config in the React context.
Use it in MFileBody to configure the cross origin renderer URL.
* Call it appConfig in the context
* Return the promises so they don't get dropped
The idea here is to make a layer which sits around for as long as we have a
valid MatrixClient. Also it makes a plausible split for the render of
MatrixChat, even if they are much too tightly bound for now.
Don't use replaceState in MatrixClient: there's lots of stuff in
MatrixClient's state now (including the app version) so replacing
the entire state doesn't really make sense (and also blows away
all of the nice defaults we set in getInitialState). Instead,
setState of the things we actually care about wherever we used
replaceState.
Also add a couple of state variables to getInitialState that were
missing.
Fixes https://github.com/vector-im/vector-web/issues/2322
Get rid of MatrixClientPeg.replaceUsingUrls, and instead create local,
temporary MatrixClients for the unauthed steps; we therefore only use
MatrixClientPeg for logged-in clients.
move the logic for handling login tokens into Lifecycle.loadSession
This means it needs access to the (real) query parmeters, so it depends on
corresponding changes in vector-web.
Make sure that we use the homeserver from localstorage for guest regsistration,
in preference to the default.
Also rename the parameters for loadSession
Take some of the magic out of MatrixChat.componentDidMount() into a new
component.
Also delete the MatrixChat test. It wasn't really doing much, is broken by the
change, and I am replacing it with (better) app-level tests in the vector
project.
when login completes, we replace the whole state, which means we unset
collapse_lhs, which then leads to complaints from the RoomList.
I think the 'default view' for MatrixChat ought to be factored out to another
component, which could manage collapse_lhs properly; but for now, hack around
it.
Also try to refactor some of the login/logout code out of MatrixChat and into a separate Lifecycle.js. This still isn't great, but it at least gets some code out of MatrixClient.
Plus a number of other tidyups:
* Fix /join to dispatch a view_room for the room alias
with the additional auto_join parameter
* Make RoomView automatically join the room if the auto_join
parameter is true and the user isn't already in it
* Tidy up RoomView's peeking code, also fixing
https://github.com/vector-im/vector-web/issues/1220
in react-sdk (although it still requires a synapse change
to actually fix, but react-sdk does 'the right thing').
* Remove duplication of usage text from /join command
* Amalgamate MatrixChat::_viewRoom's many, many parameters
into an object and sort out case consistency a little.
Add a callback to RoomView that it can give the room ID to once it's resolved it, since this lookup is now the responsibility of the roomview and only the roomview. The view_room action now has either an alias or an ID, not both. Also fix RoomView to load the room properly and not try to peek when it shouldn't.
Sorts out more of the room joining mess. currentRoom which held the room ID is now more appropriately called currentRoomId. RoomView will now take a roomID or alias as before but will now look up the room ID as required if given the alias. Also, now look up the alias every time you click on it so it's never stale, rather than looking in your current rooms for a room that thinks it has that ID.
This hopefully fixes an issue where joining a federated room via the directory
would get stuck at a spinner of doom, due to us not recognising the room in
question when it came down the /sync. We now catch the room id in the response
from the /join, and use it to match up the room in onRoom.
props.roomAlias, props.roomId, and state.room.roomId were somewhat confusing,
so I've tried to rationalise them:
* props.roomAlias (named thus to stop you assuming it's a room id) is the
thing that the parent component uses to identify the room of interest, and
can be either an ID or an alias (ie, it replaces props.roomId and
props.roomAlias)
* Everything that needs a room ID now has to get it from state.room.roomId.
The MatrixClient never gets unmounted in the real app, but I've been working on
some tests which would rather like to be able to create and destroy MatrixChats
and not have the clients hang around forever.
Update react-sdk to use `pendingEventOrdering`==`detached` instead of
`end`. Look for pending events in the pendingEvent list, and use
MatrixClient.cancelPendingEvent to, uh, cancel pending events.
Pass the invited email through to RoomPreviewBar, display it in a temporary way currently.
Remove a condition from RoomView render that appears to be functionally identical to the previous.
