-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Join and kick from all broadcast at the same time #13531
Conversation
I think I would prefer it the other way :-/ with the relay module listening to a study kick event. Like here: lila/modules/relay/src/main/Env.scala Lines 70 to 72 in c82f04c
It would probably be a lot simpler and would not require a new lila-ws message |
Ok 👍 Will do this week when I've time |
111d761
to
a118ab7
Compare
done, now join and kick study events are monitored by relay, and if a matching broadcast (relaytour) is found, added to all rounds |
modules/relay/src/main/Env.scala
Outdated
.foreach(_.foreach: tourId => | ||
api | ||
.roundIdsById(tourId) | ||
.foreach(_.foreach(studyId => studyApi.adminInvite(studyId, by)))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using foreach
, I can't use .parallel
anymore but I assume the futures will be parallelised
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same thing as for kick
, adminInvite
is called twice for the original studyId
when part of a broadcast, which eventually boils down to
def admin(by: UserId)(study: Study): Funit =
studyRepo.coll:
_.update
.one(
$id(study.id),
$set(s"members.${by}" -> $doc("role" -> "w", "admin" -> true)) ++
$addToSet("uids" -> by)
)
.void
which is to be idempotent (sequence is a set
). Maybe we want to add additional check though.
applyWho: w => | ||
api.kick(studyId, username.id, w.u) | ||
Bus.publish(actorApi.Kick(studyId, username.id, w.u), "kickStudy") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mean api.kick
is called twice for studyId
when it's in a broadcast, but should be fine since api.kick
check if the user is present.
* master: rename actors update pnpm-lock to fix CI remove debug comment study chapter auto-orientation choices simplify test assertions move looksLikePrize to modules/gathering select one post per blog then only shuffle remove unneeded pipe New Crowdin updates (lichess-org#13599) skip to branching points via keyboard nav add critical decision hopping to keyboard navigation maybe they wont notice yellow ones Update board menu to have consistent board flip Show activities for unlimited correspondence Fix prizeban for tournaments created with the tournament manager more tests for `String.looksLikePrize` shuffle before group minor frontpage blog tweak
it is eventually discarded in this specific case, I still like it better that way
close #12857 tested
Another option that probably would have reduced the code change would have been to check every time a join or kick was done If the study was belonging to a broadcast, but it seems nastier solution.