Item Template JSON — Admin Reference

Three separate settings, easy to conflate: the container dropped onto a page (containerType: Stack, Carousel, Grid, or ButtonGroup) picks the layout shell. Each item inside that container has its own itemType, set directly on the item (not inside the Template JSON) — this is what kind of slot the item is (a button, a hero card, a contact row, or a template-driven List — see §2). Only when an item is meant to fetch real data does it also carry a Template JSON string, whose contentType says what to fetch and renderType says how each fetched row should look. This doc covers all three, organized item-first since that's the order an admin actually picks them in.

ButtonGroup containers only keep Button items — any other itemType placed inside a ButtonGroup container is silently filtered out client-side.

RosterItem is what makes an item a multi-committee roster. The committee list lives in the Template's rosterCodes parameter, and the item resolves like any other templated item, so hidden, visibleMecs, hiddenMecs and hiddenUserTypes apply to it and isFavoritable is honored. The app picks the roster by this content type, not by the item's itemType. An item-level rosterCodes field (with no Template) is not read: such an item shows nobody.

If unsure, leave renderType blank and let the contentType's adapter pick its default (LecLink → CardSmall, PilotCard → PilotCard, Committee → CardSmall, MecHotelDirectory → MecHotelRow). DocumentItem, ContactItem, and PodcastEpisode require renderType to be set explicitly — the item is silently dropped if it's left blank on those three.

When the four fields above (hidden, visibleMecs, hiddenMecs, hiddenUserTypes) hide every item in a container from a member, the whole container disappears for that member: no heading, no "View All" link, and for a carousel no "Off the Radar!" card. Home's "My MEC" carousel works this way for a GGN pilot and for Staff and Guest accounts. A hidden item is always hidden, but it never takes the rest of its container with it: a container with any item the fields did not hide always shows. That includes a document list that found nothing (a carousel shows its "Off the Radar!" card, a grid or stack its heading with nothing under it) and one that failed to load (it shows as loading and retries).

In practice, set viewAllLink on the container itself, not inside an item's Template. The Template-level viewAllLink key is real and does get lifted onto the container when present, but no item in any real site's content actually uses it — every site instead sets the container's own top-level viewAllLink field directly. Real values observed there, by shape:

In real content, a Committee template is typically attached directly to a CardSmall item (not an itemType: "List" placeholder) — either convention works, since the app never reads the placeholder item's own itemType once a factory resolves it.

filterType: "LecReps" and "MecReps" rows show the favorite heart when the rep record carries the person's id (memberId, the same id a committee volunteer carries), and favorite as that person, so an officer, the same person's rep record and their committee rows are one favorite and, in Search, one card. A rep record without that id has no heart.

Row order is automatic. Every ContactItem roster (both filterTypes), every RosterItem roster, the LEC roster page and Search list officers first, by one shared title list in the app (a volunteer's title, a representative's office or office code): any Chair title (any subject chair, such as Safety Chair, included) and the National President and Vice President offices, then Vice Chair, then Secretary or Secretary-Treasurer, then Treasurer, then Executive Administrator, then Captain Representative, then First Officer Representative (a plural such as Captain Representatives ranks the same), then everyone else. Titles match whatever their capitals, and a space, a hyphen or any other dash (an en or em dash pasted from a document), a slash or a backslash (including their full-width, division and fraction forms), or an invisible character pasted with the text (a zero-width space, a soft hyphen, a byte-order mark) between or around words is the same, so Vice-Chair ranks as Vice Chair and Secretary/Treasurer as Secretary-Treasurer. Beyond that list, a title whose last word is Chair (or Chairman, Chairwoman or Chairperson) ranks as Chair, or as Vice Chair with Vice before that word, a note in brackets at the end such as (Interim) ignored; a Past, Former or Emeritus chair and Chair-Elect are not ranked. The same reading decides when two titles from one committee are the same line on a person's card. Within the same rank, a person's sortorder (from the roster data, not the Template) comes first, then legal last name, then legal first name, for committee members, reps and MEC officers alike (a nickname never moves a person). There is no Template field for ordering; a title that should rank but doesn't needs adding to that list in the app.

One card per person, on the roster, in Search and in Favorites (AB#2840). The people a ContactItem or RosterItem section lists are what members find in the app's Search and see in Favorites, so how a section is set up shows there too:

• On the roster. Each section is its own roster, so someone on two committees appears once in each, with that committee's title. If one committee lists the same person twice (two titles), the roster shows one card for them, at their highest title, with each title on its own line under their name.
• In Search. A person is one card however many sections list them. Each role they hold is one line naming the section it comes from: the committee's name, or for a LecReps section the council's own committee (e.g. "Delta Council 66"). Someone with one role keeps the roster's card, with the committee named on a line above it. Any of their titles, committees or names finds the same card.
• Visibility is per section. A section's hidden, visibleMecs, hiddenMecs and hiddenUserTypes hide only the roles that section lists: a member who can't see the section doesn't see those lines, and can't find the person by them, but still sees the person through any section they can see.
• Favorites. A hearted person shows the same card as Search, built fresh from the sections each time, so a title changed in the roster data shows there without re-hearting. Someone no section lists any more shows every committee they serve on. isFavoritable: false on a section removes the heart from that section's rows; in Search the person keeps a heart only if another section the member can see them through allows it.
• Typography. A person listed by several sections is drawn with the roster tokens of the section behind their highest role.

What they list (AB#2840). A ContactItem section with filterType: "MecReps" lists the signed-in pilot's MEC officers, straight from the officer data (getmecreps); filterType: "LecReps" lists their own council's LEC reps (getlecreps). Both need renderType: "ContactCard", like every ContactItem, and honor isFavoritable and the visibility fields.

• Only the pilot's own council. An LecReps section lists the reps of the pilot's own council only; the app drops every other council's reps before anything is stored on the device.
• The role line. A rep's card reads "Chair | Captain Rep": the office, then the seat they represent, on one line. "Representative" is shortened to "Rep" there, and a screen reader reads "Chair, Captain Rep". The seat is left off when there is none, when it only repeats the office, or when the data says "N/A" or "None". People are ordered by their office alone. A rep whose office is "No Office Held" shows their seat as their role ("First Officer Rep") and is ordered as that seat. A seniority block rep (FedEx, ALA) shows their block number from the rep data: "Seniority Block 3 Rep".
• An MEC officer's seat. The officer data carries no seat, so the app takes an officer's seat from the same person's record in the pilot's own council's rep list, matched by the person's id: an officer who is also a rep reads e.g. "Chair | Captain Rep" on the officer line. In a single-council MEC (e.g. CKS) that list always holds every officer, so every officer with a seat shows it; in other MECs an officer from another council isn't in it, and their line shows the office alone. Nothing needs authoring for this: the page doesn't need an LecReps section, and the older reps screen shows the same seat under the officer's office.
• In Search and Favorites. Officer and rep sections are sources like any roster: an officer line names the MEC (e.g. "UAL MEC"), a rep line the council, and a person's officer line comes first, then their rep line, then their committee lines. The seat is searchable in full or shortened ("Captain Representative", "Captain Rep").

Moving an officer or rep section onto MecReps / LecReps. Today these people are mostly authored as committee rosters (e.g. UAL's "MEC Officers", UALMADM00003, and the council "REPRESENTATIVES" sections), which rank as committee lines. To move one:

1. Wait for the app. Don't re-author until the first app release that knows MecReps is widely installed: an older build doesn't know the filter and shows the section empty.
2. Replace, don't add. Change the existing roster section's filterType (and drop its filterValue) rather than adding a second section beside it. Two sections listing the same people show them twice on the page.
3. Keep its place and settings. Leave the section where it is, with its visibility, isFavoritable and roster typography tokens: the rows keep the section's look, and its place on the page decides where its people sit in Search.
4. Check the page and Search with a member of that MEC: every officer once, in office order, and a search for an officer's name finds one card with their officer line first.

What it produces, and how it behaves. The Template resolves into one flat, ordered list — a search field, then for each airport (alphabetical by airport code; airports with no hotels are skipped) a header ("CODE · Airport Name") followed by that airport's hotel rows. Grouping is the item order, so the list must be rendered as-is.

• Search. The field filters live on airport code, airport name, or hotel name (case-insensitive). An airport match keeps that whole airport; a hotel-name match keeps just those hotels, each under its own airport header. An exact match on an airport code, airport name or hotel name moves that airport to the top of the list (the rest keep their alphabetical order). A clear (X) button restores the list and its original order, and a line under the field says when nothing matches.
• Put it in a Stack container. The search field is lifted out of the Stack into the screen's fixed area so it stays pinned while the list scrolls, and search reaches rows only inside a Stack. In other container shapes (Carousel, Grid, List) the list still renders but the field is not pinned and search will not filter the rows.
• Placeholder rows. Rows that are not a bookable hotel (a lounge note, "No ALPA approved hotels", a "14 hour exception city" marker) show their text as a status pill and have no favorite heart. Real hotels can be favorited.
• Empty or failed load. The Template resolves to nothing (never an error), so the container's emptyBehavior applies — set it to Message or Suppress deliberately rather than leaving an empty section.
• Tapping a row opens the hotel detail page (/mec-hotel-detail) — the destination is set by the app, not by the Template.

Put it in a Stack container. In a Stack each committee's heading sits directly above that committee's members, as one list. In a Carousel or Grid the roster still resolves, but each heading and each member becomes its own slide or tile, so the sections no longer read as sections.