Sport Types & Profiles

Sport profiles are the rule contracts that make JoomLeague sport-independent. They describe what may participate, how a contest is structured, how its result is stored, how standings are calculated and which positions, event types and statistics are available. A sport type is the editable, installation-specific record created from one of those contracts.

Understand the layers

Layer	Purpose	Editable locally?
Sport profile	Versioned definition supplied by JoomLeague	No; review and synchronise only
Sport type	Local named instance, such as `Football` or `Youth football`	Yes
Catalog records	Positions, event types and statistics belonging to a sport type	Yes
Project	A competition in a season, pinned to a profile version	Yes
Project rules	Project-only overrides explicitly allowed by the profile	Yes
Custom Fields	Site-specific metadata unrelated to sport rules	Yes

Do not use Custom Fields to reproduce profile rules, scores, positions or statistics. See Custom Fields for the boundary between the universal competition model and site-specific metadata.

Bundled profiles

JoomLeague includes 15 profiles. They use profile schema 1.4.0, but their participant and result contracts differ.

Profile	Participants	Contest and result model
Basketball	Teams	Timed periods, numeric score
Bowling / nine-pin bowling	Teams or people	Throw totals, numeric score
Chess	Teams or people	Board games, numeric score
Darts	Teams, people or groups	Legs and sets, nested score
Esports	Teams	Maps, nested score
Floorball	Teams	Timed periods, numeric score
Football	Teams	Timed periods, numeric score
Futsal	Teams	Timed periods, numeric score
Ice hockey	Teams	Timed periods, numeric score
MMA / boxing	People	Combat rounds, decision result
Motorsport	People, teams or groups	Race session, time result
Rugby	Teams	Timed periods, numeric score
Running race	People, teams or groups	Race, time result
Tennis	People, teams or groups	Sets and games, nested score
Volleyball	Teams	Sets, nested score

This is not a hard-coded runtime list. It summarizes the JSON contracts bundled with the installed release. The engine reads their codes and rules instead of assuming every programme item is a football match between home and away teams.

Profile contract anatomy

Each JSON file has a stable profile code, a content version and a schema version. The content version identifies a revision of one sport; the schema version identifies the format understood by JoomLeague.

Section	What it controls
`code`, `version`, language keys	Stable identity and translated profile name
`project_types`	Project types permitted for this sport
`contest.type`	General contest family, such as head-to-head or race
`entry_model`	Allowed participant kinds and optional member types
`match_structure`	Periods, sets, rounds, sessions, breaks and default duration
`match.score`	Numeric, nested, time or decision result contract
`lineup`	Roster size, shirts, captain and substitution behavior
`standings`	Columns, scopes, metrics, awards and deterministic ordering
`positions`	Player, staff and official roles available to the sport
`event_types`	Timeline events and their scoring or statistical effects
`statistics`	Manual, imported, event-derived or calculated measurements
`project_rule_schema`	Profile values that a project may override
`template_defaults`	Profile-specific public presentation defaults
`migration`	Aliases used to map older JoomLeague terminology

The validator rejects malformed contracts before activation. It checks unique machine codes, participant kinds, score segments and their parent graph, score aggregation, result states, substitution limits, standings calculations and references from event-sourced statistics to event types.

Score contracts

Score storage is not limited to a pair of integers:

numeric_score covers goals, points, pins and similar totals;
nested_score represents structures such as sets, games, legs or maps;
time_result supports elapsed time and race classification;
decision_result supports judged or method-based outcomes.

Segments define their unit, value type, editor control, parent, repeatability and expected or maximum count. Aggregation declares whether the root result is entered independently, validated against child segments or derived from them. This lets tennis and running use the same database model without forcing either sport into football-specific fields.

Standings contracts

standings.calculation is executable configuration, not display metadata. It defines included result states, scopes, metrics, point and bonus awards, classification rules and ordering. Total, home, away and sport-specific scopes are calculated from the same pinned contract. Manual penalties belong to standing adjustments, not to profile edits or rewritten results.

Project rule schema

A profile exposes selected values as project overrides through project_rule_schema.fields. Each entry specifies a JSON pointer, value type and limits. Cross-field constraints can enforce relationships such as minimum lineup size not exceeding players on the field.

Only exposed values can be changed under Project Panel → Project Rules. Unchecked values inherit the profile default. This prevents arbitrary JSON from silently weakening the profile contract.

Synchronise profiles

Open Components → JoomLeague → Sport Profiles. This read-only screen shows the translated name, stable code, schema and profile versions, project-rule field count, source, checksum and active or superseded state.

Use Synchronise after installing or updating JoomLeague. Synchronisation reads and validates bundled JSON resources and stores their immutable versions. It does not create sport types, overwrite local catalogs or change the version already pinned to an existing project.

If no profiles are listed, synchronise them before creating a sport type. If a profile is rejected, treat that as a package or contract error. Do not insert a replacement payload or checksum directly into the database.

Create a sport type

Open Components → JoomLeague → Sport Types.
Select New.
Enter the local Name shown in projects and filters.
Optionally enter an alias.
Enter a unique machine-safe Code using lowercase letters, digits and underscores.
Select an active Profile version.
Choose which default catalogs to create.
Publish and save the sport type.

Only published profiles with an active version appear in the selector. Creation of the sport type and selected catalogs runs in one transaction. If a definition cannot be stored, the entire operation is rolled back instead of leaving a partially initialized sport.

Initialization switches

These switches appear only for a new sport type and default to Yes.

Switch	Yes	No
Create positions	Copies all profile positions	Position catalog starts empty
Create event types	Copies all profile events	Event type catalog starts empty
Create statistics	Copies all profile statistics	Statistics catalog starts empty

Choose Yes for a standard setup. Choose No when building a genuinely custom local catalog, not merely because one item will later be renamed. You can create local positions, event types and statistics with the normal Joomla toolbar after saving the sport type.

The switches are independent. For example, an installation may use standard events and statistics with its own smaller position catalog. Review dependencies before omitting events: an event-sourced statistic needs its event producer.

What initialization creates

Profile catalogs become ordinary rows linked to the sport type. Each copied row records its source profile version and checksum. Positions preserve person type, lineup group and capabilities. Events preserve timeline, score effect, secondary-person and suspension metadata. Statistics preserve scope, value type and calculation source.

Records created manually are marked as local. Editing a materialized record changes only the local sport type; it does not modify the bundled JSON file or another installation.

Build a custom configuration

For a sport whose general behavior matches a bundled profile but whose catalogs differ:

Select the closest profile for its participant, result and standings model.
Disable only the catalogs you want to build from scratch.
Save the sport type.
Create the required records under Positions, Event Types and Statistics.
Verify person types, event-to-statistic relationships and score effects.
Create a small test project and run Project Preflight.

Do not select a semantically wrong profile merely to obtain convenient names. Catalogs are editable, but result and standings behavior still comes from the profile contract. A new contest family, score hierarchy or standings engine requires a new validated profile. Custom Fields cannot implement those rules.

Relationship to projects

When a project is saved, JoomLeague verifies that its project type is supported by the selected sport type and stores the exact profile version on the project. Historical scores, standings and editors therefore continue using the contract under which that project was created.

A sport type can point to another active version only while no project uses it. A sport type referenced by a project cannot be deleted. Use separate sport types when rule sets must coexist rather than rewriting one used by history.

Templates and profiles

Profile templates define presentation defaults appropriate to a sport. Project templates can override them for one project. Templates never change score, standings or catalog semantics.

The effective order is:

component template schema defaults;
sport-profile template defaults;
saved profile-template configuration;
project-template overrides.

See Template Inheritance for resolution and reset behavior.

Migration

Migration aliases map legacy sport, position, event and statistic names to stable profile codes. They are compatibility metadata, not display labels and not a reason to preserve the legacy runtime schema.

Use migrate.joomleague.eu for old JoomLeague databases. Review detected mappings before producing the import package, especially where a legacy installation renamed sports or catalog records.

Safe operating practices

Synchronise profiles after every component update before creating new sport types.
Keep codes stable after data exists; change translated names instead.
Use initialization switches only for initial catalog creation.
Create local records through the administrator interface, not direct SQL.
Use Project Rules for validated competition-specific differences.
Use templates only for presentation behavior.
Use Custom Fields only for installation-specific metadata.
Test unfamiliar behavior with a small project and Project Preflight.
Never edit a stored profile payload or checksum directly.

Troubleshooting

The profile selector is empty

Confirm that profiles were synchronised and the intended profile and current version are published and active.

The sport type was not created

Initialization is transactional. Correct the reported validation or database problem and submit again; there should be no partial sport type to clean up.

Positions, events or statistics are empty

The corresponding initialization switch was probably set to No. Add records manually, or recreate an unused sport type with that switch enabled. Do not delete a sport type already referenced by projects.

A project type is rejected

The value is not listed in the pinned profile's project_types. Choose a supported type or another sport type. Bypassing this check would leave scheduling and presentation without a valid contract.

A profile update did not change an existing project

This is expected. Existing projects keep their immutable pinned version. Synchronisation makes an active version available for new work; it does not silently reinterpret historical data.

A local catalog no longer matches the profile

Review source and checksum information and decide whether the local change is intentional. Synchronisation does not overwrite materialized catalogs. For an unused test setup, recreating the sport type is usually clearer than several manual corrections.