EGreg
commented
10 years ago After this:
Implement Streams/engage action POST
It would take many publishers and stream names Alrernatively it could take same parameters as Streams/related and return related streams Like Streams/related it would return only the ones published by local publishers
The client should POST elsewhere for streams published by users elsewhere
It would do the following: 1) Return streams in "streams" slot 2) Return relations in "relations" slot (if applicable) 3) For streams that it doesnt have enough readLevel to get messages in, or enough writeLevel to join, it would make requests and return resulting invites in "requested" slot 4) If it couldn't even make the request, then for those streams it would return null in "requested" slot
We can re-use the Invites mechanism.
Simply add "requested" state and make sure the code handles it Allow "invitingUserId" to be empty in that state
Add a new "request" writeLevel = 5 Anyone can request an invite to a stream if they have this write level
Implement Streams/request POST action and tool
POST can specify the levels requested On success, will POST a "Streams/requested" message to that stream
Implement Streams/requested tool Participants who have at least adminLevel = invite and at least the levels requested can see all the Streams/requested messages posted to that stream
They can then click a button to invite that user This will POST to Streams/invite with token=$token, which will check that the invite exists and its state is currently "requested" The invite's state will be changed to "pending" And the usual actions of Streams/invite will take place, including posting to Streams/invited.
(Later, we will have the ability to make rules that eg check streams_invited table and see if we requested this invite, and if so, notify us and otherwise not, etc.)