Whitelabeling Epic

[maxammann]

In order to maintain compatability with the already deployed ehrenatmskarte app for bayern the following task has highest priority: #520

• Prepare whitelabeling process #520

This epic requires multiple user stories to be resolved:

• Backend Whitelabeling #502
• Administration Whitelabeling #503
• Frontend Whitelabeling #504

Stories should be done in the order as listed above.

[maxammann]

Several techinical tasks should be created.

[maxammann]

Components which require changes:

• backend
• administration frontend
• frontend app

I would propose to keep the UI of the administration frontend generic. One solution would be to give each instance of the administration frontend a unique ID: bayern.ehrenamtskarte.karten.tuerantuer.org or nuernberg.sozialpass.karten.tuerantuer.org. This can be chosen in a hierarchical way. This can also be used for app/bundle ids, as well as server names if we have the requirements to split infrastructure in the future.

Every API request from the administration and frontend contains this ID. The android app for example can just use the application id which it was compiled with. The administration frontend could just send the current domain name.
Its not a requirement ofc. Propably we want to run the administratin frontend on a simpler domain. But maybe nuernberg.berechtigungskarten.app would be nice, wouldn't it?

The plan requires a change/an extension of the current API definition of the backend. Changes in the administration frontend are minimal. Changes to the frontend app are also quite minimal. The major work in the frontend app is to change the visual appearance.

I would say we use a single build config which is saved as yaml/toml/json. We can then use this build config in the administration frontend and the frontend app. Maybe we could actually let the administration frontend live without a build config. But sooner or later cities probably want their logo in the backend....

The next difficult problem is the fact that cards in nuernberg should not work in bayern and vice-versa. If we send this ID like bayern.ehrenamtskarte.karten.tuerantuer.org with every request, then this should be solveable in the backend.

[steffenkleinle]

I would propose to keep the UI of the administration frontend generic. One solution would be to give each instance of the administration frontend a unique ID: bayern.ehrenamtskarte.karten.tuerantuer.org or nuernberg.sozialpass.karten.tuerantuer.org. This can be chosen in a hierarchical way. This can also be used for app/bundle ids, as well as server names if we have the requirements to split infrastructure in the future.

I think the .karten could be omitted. Also the application id at least for the ehrenamtskarte bayern is already fixed. So I guess we definitely need at least two "ids". I'd even split it and make the application id/domain independent of the unique identifier used to get the correct results from the api, there is no harm in adding another field to the build config (which may be a duplicate of domain/application id thoguh) and we are more flexible that way.

Every API request from the administration and frontend contains this ID. The android app for example can just use the application id which it was compiled with. The administration frontend could just send the current domain name. Its not a requirement ofc. Propably we want to run the administratin frontend on a simpler domain. But maybe nuernberg.berechtigungskarten.app would be nice, wouldn't it?

See above, at least two ids are needed. +1 for a simpler domain (I think nuernberg.sozialpass.app makes more sense than nuernberg.berechtigungskarte[n].app though.

The plan requires a change/an extension of the current API definition of the backend. Changes in the administration frontend are minimal. Changes to the frontend app are also quite minimal. The major work in the frontend app is to change the visual appearance.

I don't know anything about the administration frontend. Things to be done in the frontend:

• Texts (sooner or later translated?)
• Visuals/UI
• Disabling/Enabling of specific features/routes
• Different build flavors/application id/icons
• API adjustments

I would say we use a single build config which is saved as yaml/toml/json. We can then use this build config in the administration frontend and the frontend app. Maybe we could actually let the administration frontend live without a build config. But sooner or later cities probably want their logo in the backend....

+1 for single build config. We also need the build config in the backend (e.g. to choose the data source and to adjust the store import pipeline (mapping, filtering, geocoding), see #463). We should also think about what to do with texts/icons/assets beforehand.

The next difficult problem is the fact that cards in nuernberg should not work in bayern and vice-versa. If we send this ID like bayern.ehrenamtskarte.karten.tuerantuer.org with every request, then this should be solveable in the backend.

That should not really be a problem, right?

[maxammann]

All tasks are done, closing.

[steffenkleinle]

Wuhuuu congrats 🎉 🚀

[maxammann]

Thanks :) parts are still missing e.g. cards, but 🤫