tested it and it works as expected. there is only a tiny dashboard-side inconsistency: for all fields in the episode editor, inputs are confirmed with dashboard's "saving" message, the only exception is the "title" field where no save-state message is displayed currently on an empty input or after deletion, the save-state message only appears when entering some text. this is not really a bug as it does not hinder the functionality. maybe @kmohrf can explain this.
update from latest status (see dashboard#247 (comment 16204)):
steering-permissions for items in the media source uploader will be implemented now, then I'll continue with testing before we finalize the dashboard side.
There are currently several use-cases I know that give a reason for color-coding in the calendar:
Let's review together what is the most needed, valuable and (from a UI perspective) senseful way to offer a color scheme in the calendar. I'd suggest a quick meeting to refine the task.
On the show info page, users have the ability to fill out global metadata info about their show. On some fields the UI does not allow to empty them completely (e.g. if someone mistakenly filled out the Genre field for a non-music show). Selecting an item and deleting it produces a "saved / wird gespeichert" dialog by Dashboard but then the item reappears the input field. This concerns the following fields:
For the cases of category / hosts / admins, those fields always have to be filled (those are obligatory program info and should not be empty), so the bug actually does not matter from the user-end side. But at least for the music genre field it would matter to clear it out, in case someone has mistakenly filled that field.
see screenshots.
Did you check with @kmohrf if it is steering-sided or dashboard-sided? ("invalid entry" sounds like dashboard would be requiring an entry?) I tested your workaround, but I find the solution with the "0" is not self-evident to a user because all other fields can be left just blank. It is not really high priority right now, but it would be good to properly fix this so it does not confuse users. I re-open the issue so we try to clarify what's going on here.
I can confirm this bug also from my latest round of dashboard testing (25.-26.3.2024), tested on both Firefox and Chrome with different user permission levels.
update after latest testing round (25.3.2024) using Firefox / Ubuntu:
When entering the All Shows List after Login, I still have one image that is not loading properly and only loads after activating the show, going to "general settings" and then back. The console give the usual "mixed content" warnings. This error is reproducable for all user groups. It seems to concern only this one image / show. See screenshot attached.
update after latest testing round (25.3.2024):
user maggietest
group host
:
~ ~ ~ ~
user maggie-host+
group host+
:
user maggie-proko
group programme manager
:
programme manager
group should either be automatically owner of all shows or should have editing rights without explicit ownership. I remarked this also in the corresponding dashboard ticket
we are almost done!!
update after latest round of testing (25.3.2024):
user maggie-proko
, group programme manager
:
for users in group host
and host+
:
as discussed in the last focus meeting with @eigenwijsje I collect the results of the latest round of testing the current implementation of the permission management, and note dashboard-related topics here:
testing with user maggietest
, group host
@eigenwijsje suggested you both have a chat this week to clear remaining questions on the implementation of the permission management.
updates from latest testing round (20.3.2024), using firefox with mentioned users&groups:
results for user maggietest
, group host
:
episode details:
~ ~ ~ ~
results for group host+
, user maggie-host+
:
show settings page:
episode details:
~ ~ ~ ~ ~
results for group programme manager
, user maggie-proko
:
show settings page:
episode details:
We are getting close!
yes please let's do that
update at 20.3.24 after second round of testing: now permissions for host and host+ group work for the show area as described in aura#156. but calendar area is still editable (expected: users should not have access to calendar for both groups)
testing permissions with user maggietest
/ group host+
shows the following behaviour:
On the show info page, users have the ability to fill out global metadata info about their show. On some fields the UI does not allow to empty them completely (e.g. if someone mistakenly filled out the Genre field for a non-music show). Selecting an item and deleting it produces a "saved / wird gespeichert" dialog by Dashboard but then the item reappears the input field. This concerns the following fields:
For the cases of category / hosts / admins, those fields always have to be filled (those are obligatory program info and should not be empty), so the bug actually does not matter from the user-end side. But at least for the music genre field it would matter to clear it out, in case someone has mistakenly filled that field.
see screenshots.
feedback after first round of testing, using user account maggietest
with host
group privileges (browser: firefox):
I observed one inconsistent behaviour: the above mentioned account is owner of two shows. for one show, I can view show notes but not edit them; for the other show I could not even view the show notes page. see screenshot attached.
one input on this topic from the recent FRO meeting with Matthias (FRO) on 11.3.24: he suggested if a radio has several studios, hosts should be only allowed to choose "live" and not select a detailed source, because this could lead to user errors (and program failures if someone books the wrong studio and does not realize it). He suggested available line sources could be limited in access by either permission management, or pre-set by an admin setting. Also it could be helpful if admins could change/set the name of available live sources in dashboard, he said. We can discuss how AURA deals with this usecase.
One common and important work scenario of a radio admin is playout error handling: playout errors can occur at any time of day and need to be addressed as quickly as possible. For that reason, radio admins need a basic email error notification that alerts them of playout errors, so they can quickly check and address them even from a remote place.
The notification system can be a script that checks on engine and sends an email to the admin in case the playout gets interrupted. If possible, a notification should contain basic info on the error (e.g. stream broken, file corrupt).