I'm glad Ruediger found a solution for dealing with a replacement capture agent, but I still think that we have a need for bulk editing of all capture properties. Here at Berkeley, we have last minute room changes to deal with. Also, remember, Chris, when you needed to change a class from T,Th to MWF? (MH-3255). At this point, however, our 2011 Vision Draft <http://opencast.jira.com/wiki/display/MH/2011+Vision+DRAFT> has "Edit recurring event (all aspects, not just metadata)" in the "Pushing Off even Further" category (i.e. beyond 1.2).
As far as inherited attributes, that's not in our Vision at all, though we do have a user story for it (MH-3413). Perhaps we should come to consensus in a Product Owner meeting as to whether these stories should be reconsidered for 1.2? Would also be good to hear from anybody on these lists (I've included Matterhorn-users) as to their needs related to these issues (particularly if they've become pain points). Judy On Jan 13, 2011, at 11:54 PM, Ruediger Rolf wrote: > Hi Chris, > > I don't find this a problem currently. I had to replace two catupre agents > already, one only for a few days. I just used the same capture agent name in > the replacement and it immediately used the others capture agent schedule. > > If you have a mobile capture agent, I would find it a better idea that it > loads the schedules for several IDs. In this way you can reasign this mobile > capture agent for several tasks. The only problem would be that these > schedules could have conflicting events. But this is currently is bug > currently anyway (http://opencast.jira.com/browse/MH-6059), and we have ather > conditions for mobile agents that are hard to check for the admin UI (the > time it takes to setup the agent in a new room). > > Rüdiger > > Am 14.01.11 01:45, schrieb Christopher Brooks: >> Here's a shot at a story for admin that I'd love to see in 1.2: >> >> "I would like a way of migrating the schedules from one agent to the >> other, in case of hardware failure" >> >> Bulk reassign? >> >> Are we planning to revisit the notion of inherited attributes for >> schedules for 1.2? Or could we maybe spend a create problem solving >> conference call on what this would enable, and considered it for a >> major point release? >> >> Chris >> > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ Judy Stern Educational Technology Services, UC Berkeley [email protected] _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
