Is there a reason why the schedule management component doesn’t have a onDelete extension function like the user management component does? I’d like to block users from being able to delete schedules but it looks like there is only appropriations for blocking creating new and editing, not deleting. Is there another way to do that with an AD-internal hybrid?
Because we haven't written it yet? 
On a more serious note, one of the things I'd like to do this maintenance sprint is go through the Schedule, User and Roster Management components, get all the behavior to a sane state, and make a consistent, useful set of extension functions. I dream big. 
Well keep dreaming because that would be awesome. 
Because we haven't written it yet?
On a more serious note, one of the things I'd like to do this maintenance sprint is go through the Schedule, User and Roster Management components, get all the behavior to a sane state, and make a consistent, useful set of extension functions. I dream big. [/quote]
please make all of these user management functions available as scripting functions also!
especially editing rosters! ability to edit them using a scripting function or save them in a database so that they could be managed with queries would be great! alot of us have been asking for that for many years now!
We’re leaning towards adding database-based and role-based roster options instead of scripting options. With database-based rosters, you can manage it through scripting or outside of ignition altogether, giving you the most flexibility. It’s on the horizon, but I don’t know what release it will wind up in.
We also plan to add the ability to edit users through scripting. Probably won’t be able to change the username or password through scripting, especially in user sources other than the internal DB, but you’d be able to change their schedule, etc. Again, no idea on the timeline for this.
I’ll make a ticket for adding/changing/deleting roles through scripting while we’re at it. It will probably be the least useful of these changes, but it will also be really easy, so that’s something. 
[quote=“KathyApplebaum”]We’re leaning towards adding database-based and role-based roster options instead of scripting options. With database-based rosters, you can manage it through scripting or outside of ignition altogether, giving you the most flexibility. It’s on the horizon, but I don’t know what release it will wind up in.
We also plan to add the ability to edit users through scripting. Probably won’t be able to change the username or password through scripting, especially in user sources other than the internal DB, but you’d be able to change their schedule, etc. Again, no idea on the timeline for this.
I’ll make a ticket for adding/changing/deleting roles through scripting while we’re at it. It will probably be the least useful of these changes, but it will also be really easy, so that’s something. [/quote]
thank you. as of now you have to use the filter extensions to limit which rosters and available users to be put in a roster are visible. If you have quite a bit of users it really slows down the roster component. For me personally, nothing is worse than a bogged down interface. I was thinking about calling in to support put another set of eyes on the way I am doing the filtering just to make sure there wasnt a better way…
also, it would also be nice to be able to build all of the user management screens to match the look and feel of your project.
Hi Kathy,
In the 7.9.4-beta 1 changelog:
Scripting Added Functionality Added scripting functions to allow adding, editing, and deleting user roles.
I don't find anything in the system.user...
That was implemented for 7.9.4 and the code got stomped on in a merge accident. 
We discovered it was missing after the beta was released, and it’s been reimplemented for 7.9.5. (Yes, the code is really there this time! 
) Hopefully the change log will correct itself for the RC, but I haven’t encountered this situation before, so I’m not really sure.
Ok I See…do you already have an estimate timeline for 7.9.4 and then 7.9.5 first beta ?
Last I heard is we’re looking at about a month for 7.9.4 final, with 7.9.5-beta1 shortly after that. That information is a couple of weeks old, so I don’t know if the timeline has changed. Support or your sales rep can get you more current info if you need it.
Thanks for the feedback, there are no emergency.
1 Like