daniel-lerch / korga Goto Github PK

Currently, Korga's services simply shows all members of a service group no matter whether they are active or not. A query parameter should be added to omit inactive group members by default and only show them if desired.

This requires a database schema change to synchronize groupMemberStatus from /api/groups/members which might be requested, active, or to_delete.

The subject of emails is missing in forward mode. They are forwarded without subject.

The current concept of Korga's development mode requires CORS for API calls and third-party cookies for OIDC sign-in. Third party cookies are not supported in Firefox and will be removed from Chrome and Edge, too. Therefore, a new solution must be implemented to enable developers to use a local or public backend with the frontend in development mode.

Korga synchronizes entities from ChurchTools and marks them as deleted once they are not found during a sync anymore. Instead of keeping deleted objects forever, they should be pruned regularly and unreferenced entities deleted.

Currently, all distribution lists of Korga are public in terms of anyone can send an email to its alias which will be forwarded by Korga. This should be changed to an approach where only emails from authorized senders should be allowed. Authorization could happen via person filters and email addresses from ChurchTools. Korga should also verify that DMARC rules were followed to make sure the sender address has not been faked.

With the next release, Korga will support OpenID Connect authentication. Applications should be migrated from LDAP to OpenID Connect accordingly. The LDAP password set feature will not be required anymore and should therefore be removed from Korga.

Currently, Korga consists of one large monolithic server based on ASP.NET 6 which also serves the compiled Vue.js static files for the frontend. This leads to unnecessary complexity in the backend component.

Korga should be split up into two Docker images (server and webapp). The new image should be built upon a basic NGINX image and include a custom entry point script which configures variables at runtime.

Contact Form 7 is a popular WordPress plugin for contact forms. It is useful to hide private email addresses but these must be updated manually. Korga could offer an integration for Contact Form 7 using its API to show contact forms in Korga and enable users to select a distribution list as target for this contact form.

That way managing contact forms would be easier than with Contact Form 7's horrible backend view and addresses would be updated automatically from ChurchTools.

API Endpoint: /wp-json/contact-form-7/v1/contact-forms with Basic Auth using application password (user settings).

Steps to reproduce:

1. Person in ChurchTools without email address
2. Add that person to a group
3. Create distribution list with a GroupFilter for that group
4. Send an email to that distribution list

Expected behavior:

• People without valid email do not receive the message

Actual behavior:

• Korga queues a message for an emtpy address which causes the entire pipeline to stall

Settings LDAP passwords via CLI is complicated. The Korga frontend should contain a utility page where users can enter their desired password and get printed out an SSHA hash which they can send to a server administrator.

See SSHA in Java for reference.

Restricted endpoints in Korga currently only require authentication. Especially for modifications, this is not sufficient. An authorization system must therefore be developed that allows granting permissions to person filters. Therefore, OIDC users must be mapped to persons in ChurchTools. That could be done via ID or, even better, with a custom claim.

Korga's ChurchTools API does not find all groups. Archived groups are not returned by /api/groups by default. However, /api/groups/members returns members of archived groups. This leads to foreign key constraint violations and causes the entire group member synchronization to fail.

To resolve this issue, Korga must explicitly query group statuses like /api/groups?group_status_ids[]=1&group_status_ids[]=2&group_status_ids[]=3&group_status_ids[]=4.

Minimal APIs is a new programming pattern introduced in .NET 6 which seams to be more up to date than a Startup with MVC controllers. A migration might not be easy for Korga and it might not even bring any benefits. Therefore, a migration path should be evaluated and discussed whether we can create a cleaner design by using it.

Using a group type filter with group role filter, it would be possible to contact all small group leaders by filtering for type small group and roles leader and co-leader.

If Korga's ChurchTools user has insufficient permissions, strange bugs can occur, the cause of which is difficult to find. Korga should therefore query the /api/permissions/global endpoint on startup and print a warning message for insufficient permissions.

Emails in forward mode do not include an author name in case the original sender did not send one. Instead, a sender name from ChurchTools should be used for known addresses or the original address if it is not known.

Korga uses the same entities for email task management and statistics. This is problematic for database cleanup with retention intervals. Instead of deleted certain columns of an entity there should be separate entities for task management and statistics so that task management entities can be deleted soon after completion of a task.

Korga's main focus should be synchronization between ChurchTools and other systems as well as email distribution lists. The event registration was developed during COVID-19 as has not really been used since then. It should therefore be removed from Korga.

If such an application should ever be required in the future, its code would still be available from the v2.1.2 tag and could be taken over in an individual application.