Feature Request: Explicit Database Selection for Specific Items in Clock Templates
Title: Prevent Ambiguity by Allowing Explicit Database Selection for Specific Items
Background:
Many professional and semi-professional stations use multiple databases within mAirList to keep content types cleanly separated. One common pattern is to isolate command items (e.g. remote triggers, dummies, non-audio control instructions) into a dedicated “system” or “command” database. These items have no editorial or musical value, and should not be visible to DJs during content planning or searching.
Current Limitation:
The Clock Template’s “Specific Item” block does not allow the user to specify from which database the item should be loaded. When multiple databases are connected and an item with the same ID or title exists in both (e.g. music in the main database and command instructions in the system database), mAirList cannot reliably pick the correct source.
Even worse, DJs may unintentionally see and schedule command items if they show up in search results or templates without clear database context.
Consequences:
- Scheduling ambiguity: wrong version of an item may be loaded (e.g. a dummy command instead of a jingle).
- Editorial confusion: command items appear in search functions where only editorial content should be visible.
- Workflow breakdown: DJs may trigger automation instructions or markers not intended for them.
Feature Proposal:
Add an option to explicitly select the source database in the Clock Template when using “Specific Item” blocks. This could include:
- A dropdown of connected databases or internal IDs.
- Folder scoping per database (e.g. “Load item X from folder Y in database Z”).
- Detection and warnings for duplicate IDs across databases.
Use Case Example:
“We store automation and system-level markers in a dedicated database that DJs should never access or see. These include remote commands, technical instructions, and dummy triggers. However, when creating a playlist template, mAirList sometimes loads command items from that database — even though we intend to use a music item from the active editorial database.”
Workarounds have proven fragile , relying on naming tricks, database ordering, and manual content separation — all of which undermine reliability and increase the risk of mis-scheduled items.
Benefit of Feature:
- Preserves clean editorial workflows.
- Eliminates ambiguity in multi-database environments.
- Supports growing use of modular database architecture in mAirList setups.