Centova Technologies Forum

Centova Cast v3 => Bugs and issues => Topic started by: Headshaker on March 05, 2014, 02:36:40 am

Title: Unique DJ account username
Post by: Headshaker on March 05, 2014, 02:36:40 am
Hi,

 I have a problem with DJ who is playing on 2 channels/station on the same CC installation.

 The issue is that he cannot be added to both channels/stations as I get red asterix next to username field so I assume that field needs to be unique.

 I think that this is a bit silly as many DJs can play on different stations using same DJ name.

 You could create validation for username that already exists for specific station.

 Regards
Title: Re: Unique DJ account username
Post by: DJNightfire on March 05, 2014, 10:06:40 am
I think there should be an option to add the DJ's to different channels, with a drop down or something. I have the same problem too. I just have to give them a new username/password, which is a pain for them as there's so many they have to keep remembering/write down
Title: Re: Unique DJ account username
Post by: Headshaker on March 05, 2014, 01:45:07 pm
Yes, that scenario is very common.

I know it is hard to resolve something like that  but actually they could create separate dj login page based on station, ie:
https://domain.com:2199/djlogin/RADIOXYZ

then you can execute query based on username AND station so there won't be username conflicts for separate stations.
Title: Re: Unique DJ account username
Post by: redman on March 05, 2014, 11:44:22 pm
Yeah I just had the same problem. One station, once they setup a user, another station cannot setup that username as it's already taken by another station. the user system should be segregated to each station.
Then when scheduling after setting up a DJ/user, you can select them from a drop down and add them to the schedule. Preferably with the ability of scheduling multiple time slots on the same day or different day if needed.
Title: Re: Unique DJ account username
Post by: Centova - Steve B. on March 10, 2014, 02:11:42 am
This was a bug and was not the intended behavior.  It's fixed for the next build.  Thanks!