Setkání komunity

Zóny v interních systémech musí zůstat zachovány

• FSS – autoritativní server, Udržují ručně
• PřF – řešení výpadku systému, požaduje funkčnost i při odstřižení od sítě rozdělení resolvování dovnitř univerzity a ven
• FI – udržuje si konfiguraci v gitlabu, validace externími dostupnými nástroji
• Teiresias – uvítá, když si budou moci upravovat své (sub)domény sami

1) jak přidat hosta do schůzky státnic, jak přidat hosta do výuky, jak upravit, aby mohl prezentovat, co uvidí či neuvidí?
Řečeny různé možnosti, které lze poradit. Výsledné doporučení: je potřeba postupovat individuálně případ od případu dle možností toho hosta a dle schopností toho, kdo schůzku organizuje. Lze učitele odkázat na pomoc týmu Jitky Daňkové.

2) Jaké je nejčastější připojení v rámci týmů? Plánované schůzky nebo Sejít se hned?
V​ede možnost sejít se hned. Je to dáno snadností použití. Při mnoha konverzacích totiž schůzky naplánované na začátku semestru "odplouvají" dozadu a studenti je v konverzaci v týmu nenajdou. A tak někdy zakládají i sami vlastní a část lidí je někde a část jinde. Problémy zaznamenány i na FSpS v souvislosti s lidmi, kteří si výuku platí a dostanou jen odkaz a nejsou členy týmu. Řešení nastíněné situace pro tazatele dále nerozebíráno.

3) Možnost prezentace pro konkrétní osoby
Ukázáno nastavení, od včerejška už je to možná funkční. Darina Pešáková s kolegy prověří a budou upraveny následně kdyžtak návody a zveřejněno v rámci popisu včerejších novinek v MS Teams.

4) Zda jde nastavit různé nastavení možnosti prezentovat rovnou pro role vlastník a člen?
Ne nejde.

5) Zda mohou technici vidět statistiky za jednotlivé fakulty?
Ne, nemohou. Řešením je kontaktovat osobu, která má globální práva k aplikaci, aby výstupy, které k dispozici jsou, poskytla.

6) Je možné rozdělit Breakout rooms na osoby po jedné a pak mezi nimi přecházet?
Ano, je to možné. Učitel potom přechází mezi jednotlivými místnostmi (obdoba toho, jak to funguje v ZOOM)

7)Problematika nahrávání přednášek
Sdíleny zkušenosti, názory, prezentován laicky právní pohled na problematiku. Výsledek: počkejme na oficiální vyjádření Právního odboru RMU ve věci nahrávání přednášek a seminářů a zkoušek. Nejsme zde na tomto fóru s to poskytnout tu správnou odpověď. V rámci uživatelské podpory jsou aktuálně učitelé instruováni, jak mohou nahrávání od studentů omezit a jak mohou stažení nahrávek zamezit dostupnými prostředky. I nadále budou instruováni, dokud nebude k dispozici informace, že má být postupováno jinak.

8 ) Lze automatizovat přesuny nahrávek z MS Teams do IS MU?
Zatím není známo, zda toto půjde a jak. Budou se teprve zjišťovat možnosti. Nastíněna možnost přes Flow.

9) Co se stane s videi po změně licence A3?
Vše přejde na ukládání do SharePointu nebo OneDrive. (Tedy i ta již pořízená videa asi, ale jistá si odpovědí nejsem)

10) K čemu potom bude Stream?
Bude to jen takový "hub", umístění videí už bude jinde

• Incident management
• Service request management
• service management
• procesne jsme nachystani potrebujeme podpurny nastroj
• rt nevyhovujici
• probiha PoC Confluence
• bud integrovano, probiha PoC Jira service management, Jira Core a Jira Software
• do konce 01/2021 predstaveno demo IT Komunite
• nasledne zjisten zajem zda do toho chceme jit
• predstaveni managementu univerzity pouzitelnost i v ramci business procesu

Dotaz na použití skupin pracovišť

• Pouze dva lidé se vyjádřili -> nevíme, jestli to znamená nezájem o danou funkci, nebo jen neochotu diskutovat/ozvat se
• Jedna odezva na kombinaci pracoviště s výjimkami (studenti), kde se ukázalo, že je to potřebné. Bohužel nikdo další se opět neozval.
• Diskuse o zapojení studentů do pracovišť automaticky podle školitele.
  • Reálně to moc nejde, protože školitel může být na více pracovištích, ale studenta typicky vede jen v rámci jednoho. Stejně tak např. ředitel vede studenty a nechceme je dávat do jednoho pracoviště.
  • Návrh na speciální aplikaci, kde by si to školitele sami zaklikávali. I tam je to problematické, protože bychom to asi nechtěli s globálním dopadem, ale spíše jen pro vybrané služby. Tudíž aktuální funkcionalita kombinace synchronizovaných skupin ručními výjimkami funguje nejlépe.

Skupiny IS/INET/PERUN

• Perun slouží jako agregátor skupin. Potenciálně může agregovat i skupiny z dalších systémů.
• Uživatelé mohou spravovat skupiny v ISu, ale je možné, že tam nebudou mít k dispozici všechny možnosti, které nabízí Perun (např. Sponzorované účty).

MyAcademic ID

• Jiří Ledvinka uvedl příklad ze své zahraniční cesty v rámci Erasmu, kdy měl v mobilu virtuální ISIC.
• Pro zajímavost, skupina kolem správy identit neřeší jedn identity MU, ale je aktivní i v mezinárodním prostředí, a právě MyAcedemic ID je jedna z aktivit, na které se také podílíme.

Kuchařka pro integraci služby

• Vznikla poptávka po návodech na integraci služby
• Budeme řešit v příštím roce. Letošní rok byl zaměřený na uživatelskou část (skupiny, přístupy…) a v příštím roce se více zaměříme na integraci služeb. Je to problém typu „slepice-vejce“, takže teď jsme v situaci, kdy to uživatelé už mohou používat, ale ještě je málo služeb.
• V budoucnu chceme zapojit všechny služby ÚVT a rádi bychom kdyby se zapojili i služby CIT.

AD

• Rozdělení na více samostatných „AD“, kde každá služba se dostane jen ke svým datům.
• Cíl je zpřehlednění a snadnější změny a jejich dopad na službu.

Práce s atributy v Perunovi

• Aktuálně může být práce s atributy komplikovanější z pohledu uživatele. Ve většině případů ji potřebují jen správci služeb.

Template pro zakládání objektů v Perunovi

• Návrh na novou funkcionalitu, která by pomohla zrychlit rutinní operace.
• Použitelné pravděpodobně jen pro správce službě, a to ještě pro ty, kteří zakládají podobné objekty.
• Pravděpodobně bude velice náročné na implementaci, aby to fungovalo obecně pro více než jen jednu osobu.
• Existují alternativy pro automatizaci, např. API přístup.
• V dohledné době se nebude implementovat.

Hromadné zakládání sponzorovaných účtů pomocí CSV

• Tato funkcionalita je nasazena v testovacím prostředí a do konce roku by měla být dostupná na produkci.

Doraz na rychlost propagace nových účtů

• Konkrétně O365
• Závisí na typu služby. Může být od jednotek minut až do několika hodin v extrémním případě.
• V o365 se může zpozdit i v samotném cloudu, kde nemáme šanci to ovlivnit.

Požadavek na slovníček pojmů na IT MUNI

• Prodiskutováno, zpracujeme.

Potřeba na interní návody

• Diskuse ohledně správy služeb obecně. Závěrem byla potřeba si u každé služby dokumentovat její chování včetně toho, jak jsou spravovány identity. Obecné návody nikdy nepokryjí všechny technické detaily.

Skupiny z ISu – jak je poznat v Perunovi.

• V Perunovi modou být některé skupiny synchronizované z ISu, ale není to snadno poznat v GUI. Závěr, rozšíříme GUI, aby se to lépe zobrazovalo.

IT komunita není komunitní.

• Málo komunikujeme s IT Centry.
  • ÚVT tlačí a rozhoduje bez konzultace s ostatními IT centry. Pocit neúčasti.
• Samotná IT centra nemají moc zájem komunikovat.
• Dříve se všichni znali, teď už se neví, kdo co dělá a komu se ozvat.
• Informace o službách pro IT komunitu, které nejsou určené pro veřejnost (něco jako kb pro servicedesk).

Péče o komunitu

• Dříve byla setkání s vedoucími CIT, letos (2020) se neuskutečnilo.
• Péče o komunitu a komunikaci s IT centry je časově náročné.
• Více společných (odborných) aktivit - workshopy, diskuse, přednášky. ÚVT má být metodické centrum.
  • Sjednocení znalostí u služeb, které dodáváme (ÚVT). Jsou tady různé úrovně znalostí.
• Pochvala za iniciativu - samotné setkání a hlavně za program navíc (diskuse).
  • Pozitivní zpětná vazba na místnost "Kafe", kde se řešila zajímavá témata.
  • Vhodné

Komunikační kanály

• Spousta komunikačních kanálů. Neví, co sledovat dříve (yammer, ms tems, fb, e-mail).
• MS teams: vznik kanálu "Fuck-upy"?
• Neví, kde najdou všechny dokumenty, zápisy apod.