This is an example of a fix for the panicServer API call and panic rake tasks when Multitenancy is enabled. Previously, the list of meetings used in these would be empty, leaving all meetings on the panicked server running and not cleared from the list of meetings.
Enable MT, create meeting, panic the server via rake task. Observe that the meeting will be ended and cleared, unlike without the fix.
The API call panicServer is UNTESTED, because I didn't get it to work immediately with API mate and do not have the time to to deal with it right now.
Notes
Actually, I'd propose to change the behavior of Meeting.all() such that it lists all meetings of all tenants, if tenant id is not passed, instead of only meetings without tenant association. In calls where only a certain tenant is concerned, the tenant id argument is naturally to be passed anyway, leading to the desired behavior.
Description
This is an example of a fix for the panicServer API call and panic rake tasks when Multitenancy is enabled. Previously, the list of meetings used in these would be empty, leaving all meetings on the panicked server running and not cleared from the list of meetings.
Fixes https://github.com/blindsidenetworks/scalelite/issues/1010
Testing Steps
Enable MT, create meeting, panic the server via rake task. Observe that the meeting will be ended and cleared, unlike without the fix.
The API call panicServer is UNTESTED, because I didn't get it to work immediately with API mate and do not have the time to to deal with it right now.
Notes
Actually, I'd propose to change the behavior of Meeting.all() such that it lists all meetings of all tenants, if tenant id is not passed, instead of only meetings without tenant association. In calls where only a certain tenant is concerned, the tenant id argument is naturally to be passed anyway, leading to the desired behavior.
See https://github.com/blindsidenetworks/scalelite/pull/1012