feat(TeamParticipants): Add support for disqualified/withdrawn/replacement

[hjpalpha]

Summary

As per discussion on discord add support for disqualified/withdrawn/replacement.
The Figma showed it with colors and an icon, but so does it for Invited/Qualifier.
This PR implements the new badges the same way as the Invited/Qualifier ones.

Open questions

• should it be stored?
  • currently the pr adds storage as .extradata.status
  • if yes should we add a value if it is neither replacement/withdrawn nor disqualified?
• should TeamParticipants that withdrew or got disqualified be stored at all?
• do we want an additional strikethrough for withdrawn/disqualified participants?
  • https://liquipedia.net/commons/index.php?title=Module%3AWidget%2FParticipants%2FTeam%2FHeader%2Fdev%2Fhjp&diff=989356&oldid=989351
  • personally i like it better without and figma also doesn't have it
  • decission: no strike-through

How did you test this change?

dev
https://liquipedia.net/leagueoflegends/User:Hjpalpha

[PiddyNydra]

do we want an additional strikethrough for withdrawn/disqualified participants?

I prefer it without as well. Plus, aren't disqualified teams usually in their own subsection? If yes, then you don't need strikethrough even more

[mbergen]

Plus, aren't disqualified teams usually in their own subsection?

Probably depends on the wiki. Not all wikis use sections in team participants to begin with.

[mbergen]

if yes should we add a value if it is neither replacement/withdrawn nor disqualified?

Perhaps we just store the value of the tag? So we'll get invited, qualified, withdrawn, disqualified?

should TeamParticipants that withdrew or got disqualified be stored at all?

Since these can still mean that the team played at least some matches, IMO it should be stored.

[Rathoz]

According to Figma, it's a qualification method, not a different status

[mbergen]

Feels like that wouldn't make sense.
The original qualification method is probably not affected by this

[Rathoz]

Which is why it hasn't been implemented, the specs aren't clear. And hence it's a new feature that doesn't exist in the TC, it hasn't been a prio.

[hjpalpha]

@PiddyNydra what should the specs be?

[PiddyNydra]

OK, thinking out loud here, because I'm not sure of the technical spcificities of the implementation:

• Labels like Invited, Qualified are the TLDR of how a team got INTO the tournament.

• These should be in relationship with the qualificaiton method, as it explains the label further (qualified by being 1st here, invited because 2nd in these rankings, etc.

• Disqualified, withdrawn, replaced, etc. are the TLDR of how a team got OUT of the tournament

• These shouldn't be in relationship with the qualification method. There isn't really a "withdrawing method/path", is there?

• There isn't a Figma design for what is shown here when a team is DQ'd/withdrawn/replaced, which from what I understand needs to be spec'd

---

To me, the user story/journey when they look into a DQ'd team is:

1. User sees a team with "DISQUALIFIED"
2. They open the card to learn more
3. They see how the team first got here (1st place in Nydra Cup) -- Being out doesn't affect this. You still qualified on some merit. You've earned it. Withdrawing has nothing to do with how you got here.
4. They see the roster that qualified/invited/supposed to play in the tournament
5. They see a note why the team was DQ'd/withdrawn/who replaced them (that's the free text added by editors)

Tell me if this makes sense :D

[hjpalpha]

personally i would think replacement can be a qual method

but dq/withdrawn can not be

[PiddyNydra]

How about this:

• Instead of special Replacement status/label, we just use Invited
• Invited + Qualification method + Note can tell a replacing team's story well enough:
  • User checks Team Participants, and sees that...
  • [LABEL] Team Liquid were INVITED...
  • [METHOD] ...because they finished 1st in Nydra Cup...
  • [NOTE] ...and they replaced TSM

User goes "Oh, interesting, why were TSM replaced?"

• User explores Team Participants further, sees that...
• [LABEL] TSM were DISQUALIFIED...
• [METHOD] They originally qualified as 1st in Grifter Cup
• [NOTE] ...but they scammed a Ferrari and now are DQd

---

So what I'm saying is, maybe we just do DQ/Withdrawn as new labels/statuses, use invited for replacement

[hjpalpha]

fwiw i only added replacement because it was in the figma :P

[Rathoz]

Invited is a qualification method though @PiddyNydra (it's the method that just "there are here because TO decided they are") What you're describing is that Qualification as Qualification Method

[hjpalpha]

how about:

1. add status
   —> obviously open to other name suggestions, was just the first thing that came to mind
   —> 'disqualified' / 'withdrawn' / '' (or something that indicates the team is playing instead of the empty string...)
   —> status doesn't touch qual method
2. add replacement as qual method
   —> treat it similarly to invited qual method?
3. display
   —> if status is not default status then use status for the label display (just ucFirst status for the display)
   —> if status is default then display the qual method (qualifier/invited/replacement)
   —> the qualifier placement stuff display remains untouched by status (because a team could have qualified and withdrawn/got dqed later on, in which case the original qualification method would still be valid data)

because we are adding storage for status, should we add storage for qual method ('qualifier'/'invited'/'replacement') too?
(invited/qualifier can currently be derived from qualifier resp qualifierpage lpdb fields but replacement could not be derived)

alternatively we ignore replacement for now and only add dq/withdrawn

[hjpalpha]

if yes should we add a value if it is neither replacement/withdrawn nor disqualified?

Perhaps we just store the value of the tag? So we'll get invited, qualified, withdrawn, disqualified?

assuming we keep it as status ...
you could have 'invited'|'qualified'|'withdrawn'|'disqualified'|'replacement'?
(you might not have any invite/qual input as well as no dq/... input and hence would get nil/unset)
should we add a default value (possibly empty string) for that too? (so in queries you can condition on it)

should TeamParticipants that withdrew or got disqualified be stored at all?

Since these can still mean that the team played at least some matches, IMO it should be stored.

alright :)