WIP Implement Forums Object

[rootelement]

We need to allow CRUD of Challenge Objects including a forums object to associate the forum for the UI.

Example additional property to the challenge object.

{
  ...
  "discussions": [
    {
       "name": "Challenge Discussions",
       "type": "challenge",
       "provider": "vanilla",
       "url": "https://vanilla.topcoder-dev.com/forum/group/discussionid",
       "options": [{ "key": "foo", "value": "bar" }]
    }
  ]
}

Options should be a non-required, non-validated array of key-value pairs

How a User Creates a Forum:

(From the comment below)

1. User creates a challenge of status New, gets a UUID
2. On this challenge, if the user wants a discussion created, they will populate

"challenge.discussions": [
  {
    "name": "My Forum Name",
    "type": "challenge",
    "provider": "vanilla"
  }
]

3. The challenge forum processor will pick up the challenge create event, check in the array if there is a type: challenge and provider: vanilla without a populated url property, create the forum, then PATCH the challenge to add the url.

4. The forum processor listens for resource create/delete notifications and, if there's a type: challenge, provider: vanilla discussion, will add/remove that user using the v5 resources api.

Tasks

• Update Challenge Dynamo Model, API CRUD, and JOI to allow reading/writing of the discussions property

[rootelement]

From @ThomasKranitsas in slack :

1. Wouldn’t it be better to have a Discussions table and reference by ID instead of having it as part of the challenge object?
2. What if you want to reuse a “Discussion” on multiple challenges? (eg when you repost a challenge, you want to use the same forum to keep all already answered questions there on the reposted challenge)
3. Will there be some sort of hierarchy? eg Public Forum > Development discussions > General Development Discussion (talking about “discussions” in general and not just as part of challenges
4. How are discussions being created? We could modify the ChallengeType model to have flags like the isTask one and based on those create or not and assign discussions to a challenge. eg a Task may not need to have a discussion. We can avoid creating an empty one and save on performance and space/usage of the forums

My Response:

1. Yes, in the future i was thinking about moving this to a discussions api. I think v1 we’re just going to put it on the object. We can migrate it away if we want to, but i think that might be abstraction for no reason.
2. See below.
3. No, this is just linking the private challenge discussion forum to the challenge. There will be other forums, but this idea is a step in the right direction toward getting the forum generation out of challenge creation.

How Challenge Forums get created: There’s a forum-challenge-processor that listens to the challenge create/update and resource create/delete and manages the challenges. So on challenge create, the forum processor will create the forum and api-PUT/PATCH the challenge with the details. This forum processor is aware of tasks and we can either surface “create forum?” in challenge manager, and/or ignore forum creation for tasks.
The generic-ness of it allows you to create other types, including maybe a private slack domain/challenge invite URL (in the options key/value object), Teams, Discord, etc.
One thing i’m thinking about from what you said is making the type of the forum something identifiable for the current, active forum for the challenge. I’m thinking if you repost a challenge, you wouldn’t use the same forum, but we could link it as a type of past-challenge or something like that and put the name as something identifiable.

[rootelement]

From @jmgasper in slack:

What are the thoughts around the options array? I’m not a fan of unstructured placeholders for “future use” in stuff like this because it’s relatively undocumented, and not transparent in how it’s used.

Linking in a past forum for a repost shouldn’t be a problem, provided that we properly surface the fact that a new challenge is a repost of an existing challenge. Do we get that in the Kafka message?

My response:
options array for me would be up to the processor only. So if we have a processor for slack, it could add a registration url to the options array. Not up to the user, but only the processor.

We don’t get that any kind of re-post notification. gotta figure that out

[rootelement]

Scenario:

1. A challenge is posted, the forums processor creates a forum
2. Members register for the challenge
3. The challenge is deemed failed for whatever reason and is reposted.

Questions:

1. How do we prevent the forum processor from creating a forum? Because the newly created challenge should have the forums/discussions object populated, the forums processor should not create one?
2. How do we de-register members from that forum so they can't see it to "reset" it?

[rootelement]

Another Question:

1. How do we prevent the challenge-processor from creating a forum (like for a task?)

It's almost like when a challenge is created (by challenge manager, for example), the challenge manager should populate the discussions object (as listed above) but leave the URL blank. That way, it shows the challenge is expecting a destination to be inserted. Then that covers the previous scenario (the url will already be populated) and the task scenario (there would be no challenge discussion object in the discussions array)

That does not cover the repost-challenge, removing old members scenario.

[dmessing]

I'm probably way off, but wouldn't a task just not generate a "Create challenge event" Or is it that the forum creation is listening to a create challenge event?

[rootelement]

A task is a task is a challenge is a challenge. Everything is a challenge, and every challenge fires a create/update event. The logic to ignore would need to be on the processor side. So either we "always create a forum for a challenge and never create a forum for a task" (as it is now) or we have some sort of way to signify that a challenge is waiting for a forum to be created.

@cwdcwd thoughts?

[cwdcwd]

yeah I think you'll just want the processor that creates forums to ignore challenges tagged as tasks.
Alternatively, you could have your forum creation processor listen on a different topic and have the API publish to that topic when a forum is needed. In that way you'd push the decision into the API and keep the processor "dumb"

[rootelement]

Here's the flow as I understand it:

1. User creates a challenge of status New, gets a UUID
2. On this challenge, if the user wants a discussion created, they will populate

"challenge.discussions": [
  {
    "name": "My Forum Name",
    "type": "challenge",
    "provider": "vanilla"
  }
]

3. The challenge forum processor will pick up the challenge create event, check in the array if there is a type: challenge and provider: vanilla without a populated url property, create the forum, then PATCH the challenge to add the url.

This puts the onus to create or not create on the API side.

[ThomasKranitsas]

PR: #309

[rootelement]

This is implemented and deployed on the API side.