Bug 34264

Summary:	Allow definition of "None" audio alert
Product:	Koha	Reporter:	Andrew Fuerste-Henry <andrew>
Component:	Staff interface	Assignee:	Bugs List <koha-bugs>
Status:	NEW ---	QA Contact:	Testopia <testopia>
Severity:	enhancement
Priority:	P5 - low	CC:	gmcharlt
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

Description Andrew Fuerste-Henry 2023-07-12 20:47:59 UTC

We recently had staff ask us to disable the audio alert for just one of the many things in Koha that trigger off of the .audio-alert-warning selector while keeping that sound in place for all other instances of .audio-alert-warning. 

I was able to accomplish this by adding a new alert tied to a more specific selector with its precedence set to be enforced before the more general warning alert. I was able to enter the literal word "nothing" for the sound, which appears to allow the trigger to activate without making any sound at all. 

This works, but it would be a lot clearer if the preset sounds dropdown included a "None" option or something else explicit.

Comment 1 Katrin Fischer 2023-07-12 21:03:36 UTC

I usually delete the ones I don't need - did you want to keep it just in case?

Comment 2 Katrin Fischer 2023-07-12 21:04:23 UTC

As we might not want the jQuery to still be run, maybe instead of a none option we could have an Activate/deactivate.

Comment 3 Andrew Fuerste-Henry 2023-07-13 14:19:24 UTC

(In reply to Katrin Fischer from comment #1)
> I usually delete the ones I don't need - did you want to keep it just in
> case?

So, getting into the specifics: Like the default sandbox setup, we have the critical.ogg sound play on the .audio-alert-warning selector. That means Koha makes a cranky noise in *many* situations. Staff asked if we could keep that noise in all of those situations except 1. They didn't want the noise anymore when checking in an item from a patron with a restriction. 

Theoretically I could have figured out a way to use CSS or jQuery to specify ".audio-alert-warning NOT .ret_foreverdebarred." Or I could have deleted the .audio-alert-warning trigger and replaced it with distinct triggers for all of the other instances that used to rely on the warning trigger. But what I ended up doing, and would like to make more official, is essentially defining an audio alert exception.

So, actually, maybe that's the enhancement: allow definition of exceptions within an audio alert.