feat: Unified backend

[jaspnas]

Merge conflicts is becoming an increasingly bad problem when things need to be updated across all sites

There doesn't seem to be any need for having different backends for the different websites as most things are similar enough that differences should be able to be controlled by simple environment variables.

Initial idea

• Move all sites frontend files to the main develop branch and control which one is used based on environment variable
• Add the ability to enable and disable modules using environment variables.
• Make any custom functionality be enabled by environment variables.
• MIgrate the different databases to use the same models

[andreedd]

Yes

[andreedd]

Se should create a mew Django app for both KK and Biocum. In those folders those all the association custom stuff should be located.

[jaspnas]

Se should create a mew Django app for both KK and Biocum. In those folders those all the association custom stuff should be located.

Is there actually anything major enough that it would need it's own apps. You can probably get away with just setting the disabled modules in .env to start with. Or setting some extra modules variable.

Then for minor stuff you can just check the env variable, but I think you can remove most of the differences on the backend side.

Templates/folders will probably be moved under root and then have folders for common, date, kk etc.

[andreedd]

I think there will be from time to time that the projects require custom solutions. I think it would be better to keep all of those custom solutions in the same place. For example the custom events templates could be moved there. I know KK has an lucia app as well, which also could be moved there. DaTe has the CTF app, do we want that one as DaTe only? And the list goes on..

But of course these things could also be where they are now and just be activated using env variables.

[jaspnas]

I feel like if we have all custom solutions for each project in only one module it will become a massive module that will just keep growing, especially for DaTe where we have most potential for custom features.

Doing more major backend code changes than we need to will also increase the scope of this project that is already massive for DaTe standards.

Also if more than one, but not all websites needs the custom functionality we would essentially have to duplicate the code if it's in the one custom module.

As for custom event templates we should probably figure out a better way to do it than just hard-coding or just having the option to specify a pre-hardcoded template in the model.

I think it would still make the most sense to just be able to enable and disable the modules, or have some kind of launch-configs file that specifies launch config based on what site we're hosting.

[jaspnas]

We should open up smaller issues for things that aren't totally all-encompassing. Otherwise this issue will become a total mess.

[andreedd]

Yeah true, the hardcoded template shouldn't really be needed if it is done right :D

Yeah might as well apply all the backend changes for all of the sites we control and then later on limit them with env variables. Rights to the modules can also be controlled via admin groups quite well.

But for the frontend changes I would still split into som kinds of modules somehow. But it could actually be enough to just make folders of all the static files with the different website names.

[jaspnas]

Yeah true, the hardcoded template shouldn't really be needed if it is done right :D

Yeah might as well apply all the backend changes for all of the sites we control and then later on limit them with env variables. Rights to the modules can also be controlled via admin groups quite well.

But for the frontend changes I would still split into som kinds of modules somehow. But it could actually be enough to just make folders of all the static files with the different website names.

Frontend structure will probably still be split into modules, but they would as of my current early plan be under a single templates folder e.g. templates/date/events/event.html

I will try to document as much as I can beforehand when I have time to write issues about it.

[jaspnas]

I have opened #331 and #332 for discussing frontend and backend architecture separately

[nDny]

Pasting this here also:

Django can quite easily target and use different setting files. One good way to do this is to have all shared settings in a base_settings.py which the individual settings files (date_settings.py kk_settings.py etc.) then would extend. There are several ways to target the individual settings files but one way is to set the env DJANGO_SETTINGS_MODULE in docker-compose which gets the correct one from corresponding .env file.

This way we can control MANY things such as which statics/templates django looks for and which apps are enabled etc. Making it a lot easier managing the one branch for all setup.

The same way we could also easily separate prod/dev settings if needed.