Event planner

[Webatron11]

My feature request is about

• A new feature

Describe the solution you'd like
I would like the ability to convert times in one timezone to another timezone. For instance, you could run a command with the parameters of 10am GMT-5 to CET, and it would return 10am GMT-5 in CET time.

What needs to be done
see #54 (comment)

[s0lst1ce]

Good idea. Will be implemented for v2

[s0lst1ce]

I've been thinking of two options. First we add some custom emojis for each "main" timezones. This could also be flag emojis... maybe. Flag emojis would get in the way of #43 though so I'd prefer not too. Anyways emoji reactions which would trigger a message with the converted timezone.
Or we could have a command that lets you write the time in your timezone and the bot returns an embed with a set of preselected timezones (which could be configured by an admin).
Which would you prefer ? Why ?

[morcup]

I don't really know too much of how an embed works, could it be some sort of a dropdown menu thing? I like that idea.

[s0lst1ce]

This is an embed

It's what the bot produces when you use the embed command. You can try it on discord if you want.

[s0lst1ce]

So I've been thinking at it again today. Although the idea did seem nice at first, developing the idea revealed its clear flaws. It would require a lot of clunky setups and lots of constraints for the user. I have thus thought of the use cases of a timezone converter. I've come to reach the conclusion that most cases requiring a timezone converter would be for planned events. Do you agree with this ?
If you do: I think that we could instead implement an "event" feature which would allow everyone (or select persons) to make events. This event would have description and all, probably formatted in an embed... Moreover it would have a functionality similar to the new reminder one (#61 ). It would give notifications to all users having applied to it an hour, a minutes, etc... before the event. This would be much more feasible and practical. Would it suit your needs ? If not do you have alternatives ?

[morcup]

That sounds pretty good to me. What you're describing seems much simpler, yet still accomplishes the same things.

[s0lst1ce]

Considering the change of plan for this feature here's the new tasklist:

• Event constructor & display
• Ability to "join" an event
• Reminder for all participating members
• Custom role for each event (see A command to self-asign some allowed roles #19 )

Then we could also add some miscellaneous such as editing events. Bringing it up with another command. Binding a command to the event (ie: send a message in #news, send an invite) for when its countdown ends. Do you think any of those is interesting? Any other feature you'd like?

[s0lst1ce]

The way I see it is that there will be a new event group which will contain the following commands:

• new enter the event creator context
• send [name] sends the latest (or name) event built by the author in the current channel
• start <name> force starts the specified event
• rm <name> deletes the specified event

We will have to determine whether removal of an event should alert the subscribed members or not.
When creating an event a number of fields will have to be specified:

• start date when the event should begin
• reminder how much in advance should the subscribed members should be reminded (default: 1h)
• name the name of the event
• description all information relate to the event
• attributed channel this is optional and will create a new channel restricted to the subscribed members with the specified name
• role whether to create a role for this event and how it should be called

If I have not mentioned the possibility to link some fields to existing resources it is because the event creation process should take place in a DM, not in a guild. Thus mentions are not possible and requiring the user to hand-feed IDs not viable. If this is noted as too big of a flaw I could revise the planned method.

[s0lst1ce]

Based on this here are the additional tasks needing to be added:

• Implement new command
• Implement send command
• Implement close command to close admissions
• Implement rm command
• Implement list command to track all events
• Implement edit command to edit a non-declared event
• Implement preview command to see the full embed without sending it nor entering edition context

[s0lst1ce]

this is the associated python structure that is planned to be used:

{
    "time": int,
    "name": str,
    "reminder": int,
    "description": str,
    "channel": int,
    "guild": int,
    "role": Union[bool, int]
}

[s0lst1ce]

Maybe all events shouldn't be free. By this I mean that only select members should be allowed to join? Although per-member selection hardly seems doable we could limit to select roles? This would mean that associated role wouldn't be free anymore. However this may be over complicating things since the issuer of the event already choose in which channel to send the event.

[s0lst1ce]

To prevent abuse I'm adding another clearance level: planner.