I need to build a website for a collective of (~100+) associations/initiatives of a city. The main feature is a shared calendar which displays all events and a separate page for each association to show only their own events.
Every association should be able to create and edit their own events and edit their “profile” page.
I’m trying to figure out, how to scale this properly. Do I simply create a resource for every initiative and manage very repetetive access controls over a 100 instances including individual media sources?
For the events themselves, I was thinking to create a custom migxdb package, where all events are created and then displayed in the frontend with some form of calendar framework or potentially something custom. But I am not sure how I would manage to only show the associations own events. This should be dependant on the user login I’m assuming.
Has anyone maybe done something similar in the past? Is there an obvious better way to achieve this? Greatful for any ideas!
I think the Agenda Extra is worth a look. @jako support for custom solutions is also excellent: https://modmore.com/agenda
Thanks, I already had my eye on Agenda. In general I am less worried about the actual calendar part for now, but I would love to know any ideas on managing 100+ users and permissions. Is there a way to automate this?
Also let’s say the events are created through a migxdb TV that every user has access to. How would I be able to separate the migx entries by association, so only the users events are visible and editable by them, but still display them all together in the frontend?
Yes, this can all be automated with PHP, xPDO and the appropriate MODX classes (like e.g. MODX\Revolution\modUser for a user), so that you don’t have to manually create 100 users.
There exist also extras (like e.g. User Import) that may work for this use case.
Should the users be able to manage the events in the MODX manager or on the front-end?
It might be easier to write a front-end tool to manage the events and create a custom DB table with a REST endpoint to store them.
The custom event DB table then needs a column for usergroup-ID (or maybe the user-ID), so that you can filter the data by the associations (assuming that every usergroup corresponds to an association).
To manage the data in the manager with a MIGXdb CMP, you’d have to change the getlist processor, so that only the appropriate events for the currently logged in user get shown in the grid. And the update processor would have to be changed to fill in the column with the usergroup-ID.