Open GatesheadBen opened 6 years ago
Workaround number 1 is much better than workaround number 2!
In fact there's a config setting that allows you to show a person's groups in the all-persons listing etc.
And groups also have a "show on add-family form" setting to allow you to put people into them when first added.
If we were to allow persons to be members of multiple congregations, congregations would become really just the same as groups. So unlikely to go that way.
Agreed, the main downside of workaround 1 is that we will not be using the congregation feature at all (unless... see issue 491) so there will be a number of things in the interface which are not intuitive to the administrators.
Congregations are treated differently to Groups in at least four ways:
service.congregationid
):
This extends to service components, which can be restricted to particular congregations (congregation_service_component.congregationid
):
roster_role.congregationid
)TBH this doesn't seem to affect much, other than visually grouping roles in the drop-down when defining a Roster View:
..whereas they can belong to many groups.
The attendance_record
table doesn't record which congregation a person attended (because we assume they can belong to only one):
MariaDB [jethro]> select * from attendance_record limit 1;
+------------+----------+---------+---------+-----------+
| date | personid | groupid | present | checkinid |
+------------+----------+---------+---------+-----------+
| 0000-00-00 | 4260 | 0 | 1 | NULL |
+------------+----------+---------+---------+-----------+
1 row in set (0.000 sec)
I can see it would be possible to fully unify Groups and Congregations, if Group functionality were extended:
Unifying these also reduce some duplicated databases (congregation_headcount
and person_group_headcount
, account_congregation_restriction
and account_group_restriction
).
OTOH, simply allowing multiple congregations wouldn't be that hard either:
person_congregations
join table between _person
and congregation
.attendance_record.congregationid
column.Anything I'm missing?
Pretty good summary.
The thing is: In certain contexts it's actually a valued feature for a person to be in exactly one congregation. For example it defines which pastor is responsible for them. So unifying groups and congregations would take that feature away.
See recent work in https://github.com/tbar0970/jethro-pmm/issues/834 which makes the "all persons in one congregation" approach more workable than it used to be.
The attendance_record table doesn't record which congregation a person attended (because we assume they can belong to only one):
Related: https://github.com/tbar0970/jethro-pmm/issues/490
Roster roles can be (don't have to be) per congregation (roster_role.congregationid). TBH this doesn't seem to affect much, other than visually grouping roles in the drop-down when defining a Roster View:
The subtle connection here is that when a roster view has "show on run sheet" enabled, it's the role-congregation link which determines which run sheets it's shown on. Roster views that include 9am roles are shown on the 9am run sheet, etc.
To allow rotas and attendance records across a whole church it would be useful to allow membership to multiple congregations
Workaround: 1) Don't use congregations but use groups 2) Have multiple records per person
(As always, apologies if this questions/issue has already been discussed or if we have mis-understood the feature(s))