IRR all newcomer no record

[bembaol]

There are too many "IRR {IRR name} All newcomer No Record" on the summary of an event (see picture above).

We should collect all "IRR {IRR name} All newcomer No Record" in a toggle called "[IRR]-all-newcomers-no-record".

[VijayrajS]

Two questions regarding this issue:

• Would it be better to decide all possible tag groupings before working on this issue? I see IRR-all-oldcomer-no-record as a potential grouping as well.
• Such tag organization restructuring would be better implemented if grouping was done at the API endpoint itself (a rough example shown below). Is this something we would be willing to do, or is it imperative that we code up the grouping logic into the frontend?

{
  "groups": {
    "[IRR]-all-newcomers-no-record": [
      "Irr RADB All Newcomer No Record",
      "Irr ARIN All Newcomer No Record",
      "Irr RIPE All Newcomer No Record"
    ],
    "[RPKI]-unknown-roa": [
      "Rpki All Oldcomer Unknown Roa",
      "Rpki Some Oldcomer Unknown Roa"
    ]
  }
}

[IlianaXn]

As discussed in our call with @VijayrajS and to keep @bembaol updated,

• The groupings should be on irr-[IRR]-[common_suffix] families of tags, where:
  - IRR can be multiple different (not necessarily all of them) IRR names belonging to this list: [ARIN, RADB, BELL, BBOI, LACNIC, LEVEL3, NTTCOM, TC, WCGDB, AFRINIC, ALTDB, APNIC, ARIN, CANARIE, IDNIC, PANIX, REACH, RIPE, RIPE-NONAUTH, OPENFACE, JPIRR, NESTEGG].
  - common_suffix must be the same for all tags in the same family/group and can be one of the: [all-newcomer-exact-record, all-newcomer-more-specific-record, all-newcomer-no-record, some-newcomer-exact-record, some-newcomer-more-specific-record, some-newcomer-no-record, all-oldcomer-exact-record, all-oldcomer-more-specific-record, all-oldcomer-no-record, some-oldcomer-exact-record, some-oldcomer-more-specific-record, some-oldcomer-no-record] (see ref here and here).
• To follow frontend & API principles this processing should be done by th API, and it should return the groupings to the frontend. The frontend is responsible to present it as expandable/collapsable toggles. @VijayrajS suggested adding a parameter to the API endpoint (e.g., grouping=1) to indicate whether we want the API to do the grouping or not. It needs to be clear that regardless of the value of the parameter the returned data will always be complete; the only thing that changes is that with this parameter set, the API does some additional pre-processing of grouping them.