Apply the same DB-Model for events, so that we have revisions, org-tags and custom-links also for events

[wellemut]

Problem

• Users are confused and frustrated, if things are differently between events and places (revisions, orgTags, customlinks https://github.com/kartevonmorgen/openfairdb/issues/350 ...)
• Whatever modifications we do in our ofDB it needs to be done twice for places and for events. That takes time and costs money.
• Different behaviours for Events and Places makes it complicated for users to understand how it works.
• Events do not have a history which might be helpful sometimes
• It is not possible to transform an event into an initiative or an initiative into an event, which would be nice often times, because a regular event is kind of an initiative or an initiative can become an Event, when they are meeting.
• The Token- and ownership-rules for events are really complicated. Events can not be edited any more, if one reserved tag is added. The way it is solved for places with the clearance Center is much better. https://github.com/kartevonmorgen/openfairdb/issues/397

Solution

We apply the same DB-Model to events as we have it for initiatives and companies

Places-Databases-extensions

• Add the type "event" additionally to "non-profit" and "Commercial"
• Extend the places DB for an optional Start- and End-Date, only mandatory if the entry type is "Event".
• Add the field "owned by" to the databases (and the entry mask). So every entry can have an owner-Organization, which means, this organisation is linked on the entry profile and the positive-impact rating is transfered to that entry (or event)

Import all Events into the PlacesDB

• All other field should match already, so you can just move all events from the events db in the places tb
• Rematch all old Events-API-Calls to the new Places-DB, so that other plattforms like mapa.falanster.by/ and lippevonmorgen.de/ continue to work without that they have to restructure their frontend-APIs

Get-Requests

Now the Events can have ratings too. (if we show them in the frontend is a different question. The frontend gets everything with one API call. Order of the searchresults

1. Best ranked entries first
2. next upcomming events for the next 90 day
3. unrated entries
4. all other events later than 90 days
5. all negativ rated entries
6. Search result outside current bbox
7. Past events (optional) - At the end of the search result list should be a button "show past events" and another one saying "show archived entries" -> frontend-issue https://github.com/kartevonmorgen/kartevonmorgen/issues/554

---

Similar:

• New Datamodel for ofDB #394

[wellemut]

Is there anything left to discuss before merging events to the placesDB? The need to be able to edit events on kvm which where created by wordpress with a token comes more and more...

[wellemut]

Documentation of API and Funktion for merging DB https://wechange.de/project/karte-von-morgen/document/merge-events-into-places-openfairdb/edit/

[wellemut]

Too complicated for the Hackathon because there are many old, messy fixes actually in the ofDB

---

Its not the question, if we need events or not, Its now the time to make the quick-fixes a solid system

A complete restructuring of Backend-Logic is needed

• everything, that has proven to be usefull and always needed should be implemented in a central system
• everything option, can be build around.

We think about an solid ofDB-core that is developed by slowtec and contains only central fuction which are always needed. Above that is a "Prototype-Layer" where every Community-Hacker can experiment and build ofDB-Module on top. (All the Apps should be in Rust too. )

---

How to decide, which fuctions comes into the ofDB-Basis? technically, Uwe, Magnus and Markus Helmut is needed to discuss the usecases

But we don't want to go to too high level discussions "what the world needs most". Just very concrete, from what the users are actually using.

---

[wellemut]

Still important for fairnetzt

Könntest du bitte den Token/Schutz vom Hashtag allgäu-fairnetzt aufheben? Die Gruppe ist total genervt, dass sie ihre Termine nicht bearbeiten kann.