Allow Meetings to be Efficiently Edited as Groups #1313
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.


This PR is the purification of an earlier PR, and is intended to allow the ideas here to be considered independently.
The goal of the PR is to allow the maintainer of meeting data for regions where groups have multiple meetings per week to edit the meeting data efficiently, without having to repeat himself. This is in keeping with the core principle of BMLT, that meeting data should be stored in a single place, the redundancy inevitably leads to inconsistencies.
This PR is NOT about making BMLT group oriented as opposed to meeting oriented. If crouton or other clients wish to implement a group oriented meeting list, they can do so with or without this PR.
It does not impact regions that do not organize their meetings in this fashion. It allows both independent meetings and groups to co-exist within the same region.
The basic idea of the implementation is that meetings and groups have very similar data, in particular, both have formats and "meeting_data" (the stuff stored in the _data and _longdata tables). In this sense, groups are a type of meeting with the following differences:
So, the meeting table gets an extra field, allowing participating meetings to point to their group, and another field that marks the entries in the table that represent groups, so that we may easily filter them out from meeting searches.
So, only thing to be done in the backend is to construct the meeting data out of both its own data, and the data associated with its group. Laravel's ORM makes this relatively easy.