milux / ctldap

LDAP Wrapper for ChurchTools
GNU General Public License v3.0
12 stars 8 forks source link

Status as group #14

Closed karl007 closed 4 months ago

karl007 commented 5 years ago

Hi.

It would be nice to share objects with all people with the same status, so it is possible to share a folder with all Members, Guests, etc.

What about to add virtual groups for every status, like 'STATUS_Mitglieder', 'STATUS_Gast', etc?

Any ideas? Is this possible with the CTS API?

a-schild commented 5 years ago

Would also second this, so we could assign more rights to the "Leiter" and/or "Co-Leiter" members

milux commented 4 years ago

Interesting idea, but until a have a lot of time to look into this (this is going to be very low priority for me), you will need to create additional groups in CT.

bwl21 commented 3 years ago

To be honest Virtual Groups should be provided by CT and not by ctldap. If CT had it, it would be available for ctldap but also to have a better organization in CT.

milux commented 3 years ago

To be honest Virtual Groups should be provided by CT and not by ctldap. If CT had it, it would be available for ctldap but also to have a better organization in CT.

I don't think so, because the roles do already exist, so it doesn't really make sense for CT itself. However, it is a valid question whether this role/subgroup model of CT has ever been a good idea at all...

bwl21 commented 3 years ago

I don't think so, because the roles do already exist, so it doesn't really make sense for CT itself.

Virtual Groups ( Groups which are populated by a query ) cannot be replaced by the roles. The roles rathe can be used to support Virtual groups.

However, it is a valid question whether this role/subgroup model of CT has ever been a good idea at all...

One might question this (and I question it as well !), but it cannot be changed.

We are currently working on mapping our church to CT-Groups. We think of separationg the concerns of a group such as OrganizationGroup, ServiceGroup, AccessrightGroup, ProgramGroup, DistributionGroup.

If we do this, we should have more flexibility in populating the groups. So virtual Groups might help.

milux commented 3 years ago

Virtual Groups ( Groups which are populated by a query ) cannot be replaced by the roles. The roles rathe can be used to support Virtual groups.

True. I meant now they have this structure, virtual groups would only make things even more complicated for most users, so if I was in the core dev team I would not vote for implementing it.

One might question this (and I question it as well !), but it cannot be changed.

We are currently working on mapping our church to CT-Groups. We think of separationg the concerns of a group such as OrganizationGroup, ServiceGroup, AccessrightGroup, ProgramGroup, DistributionGroup.

I am happy that they accepted my contribution some years ago for a feature that disables CT's anti-feature for assigning people rights directly, without groups. There is a flag for the config file since then to switch that off on the UI level, except for calendar shares.

bwl21 commented 3 years ago

Virtual Groups ( Groups which are populated by a query ) cannot be replaced by the roles. The roles rathe can be used to support Virtual groups.

True. I meant now they have this structure, virtual groups would only make things even more complicated for most users, so if I was in the core dev team I would not vote for implementing it.

I do not really understand. You agree to my statement (that roles cannot act as virtual groups) but you would vote against it.

I agree, that virtual groups require more understanding. And also the discussion might be obsolete, as we are using CT now.

My major statement was, that it makes no sense to add virtual Groups to ctldap. CTLDAP simply should reflect the groups as they are in CT.

One might question this (and I question it as well !), but it cannot be changed. We are currently working on mapping our church to CT-Groups. We think of separationg the concerns of a group such as OrganizationGroup, ServiceGroup, AccessrightGroup, ProgramGroup, DistributionGroup.

I don't know enough about LDAP. But in CT ist is possible that the group structure is not only a tree due to the fact that a group can have multiple supergroups. Will this be reflected in LDAP as well?

milux commented 1 year ago

Hi.

It would be nice to share objects with all people with the same status, so it is possible to share a folder with all Members, Guests, etc.

What about to add virtual groups for every status, like 'STATUS_Mitglieder', 'STATUS_Gast', etc?

Any ideas? Is this possible with the CTS API?

@karl007 Is this still relevant for you? You were talking about the "normal" statuses, where there are only like a handful in a typical CT installation, right?

I'm asking because what @a-schild was talking about were not statuses, but (group) roles, and that's much more difficult when it has to be done right, because one would need to filter out the actually used roles and focus on these, otherwise the LDAP tree (and any attached system like NextCloud) will be cluttered with dozens of additional groups.

obstschale commented 7 months ago

FYI: Since Q1/2024 ChurchTools has dynamic groups (Automatische Mitgliedschaf). A feature, where you can automatically add members to groups in ChurchTools. With that feature, I think you can solve all these use cases.

milux commented 4 months ago

FYI: Since Q1/2024 ChurchTools has dynamic groups (Automatische Mitgliedschaf). A feature, where you can automatically add members to groups in ChurchTools. With that feature, I think you can solve all these use cases.

I'm not sure whether this feature actually solves all sensible use-cases that were suggested here, but lacking a common understanding of how and where exactly such a thing should be implemented in ctldap (if it should be there at all), I will close that issue as obsolete.