Implement /past

[pma-ableton]

/past shows event information of past events.

• /past helps to bridge development time spend on bigger features to give the bot a purpose as long as no upcoming event is scheduled inside the database.
• An MVP version could simply reply all event information inside the database, since the individual event content would already be nicely separated by their artworks.
• Idea: In this case the implementation might work similar to /next, but instead of max(eventID) all eventIDs need to be requested inside db_objects.py.

[obitech]

I like the idea of displaying all previous events.

We should probably choose a different format than the one in templates/next_event.html as a) we don't need information like time or admission and b) if there have been a lot of events in the past, the message to the user will become quite large. We should consider an abbreviated form to improve readability. Maybe it's enough to display the name and the description but the name is actually a hyperlink that fetches the event, when clicked? (See #31)

Some pseudo code how I think this could work:

# __init__.py
@bot.message_handler(commands=['past'])
def past(message):
    events = Event.all_events()
    if not events:
        # Send 404 template

  for event in events:
    # send event via send_tempalte

# db_objects.py
class Event:
    # ...

    @classmethod
    def all_events():
        with sqlite3.connect(DB_NAME) as conn:
            curs = conn.cursor()

            # Get all events from DB.
            curs.execute("""select * from Events""")
            result = curs.fetchall()
            if not result:
                return None
            
            events = []
            # Unpack DB result into list of Events

            return events

[pma-ableton]

Totally! I just think that this feature needs to go live asap to give @wuestbot a meaning. Therefore a first solution that simply replies all event-db-entries is still a valuable solution imo that is easier to implement. I'd like to tackle this first, also to get some code insights that are easier do digest for a newbie like me. ;) Let me know if you have any concerns.

[obitech]

a first solution that simply replies all event-db-entries is still a valuable solution imo that is easier to implement.

Absolutely. The logic behind both solutions will be the same as the display of events will be controlled by the template. You can just go ahead with a "naive" template implementation that displays all events and then have a 2nd PR that adjusts the template.

[obitech]

We agreed on the following layout for the first PR:

WUEST | Stadtbad | Pierre Grasse | 2019-12-07 | Iku Sakan : Asako Fujimoto : …
Event 2 | Location 2 | Date | Artist1 : Artist 2 : …

In the 2nd PR we want to include links to events and artists.