Sovelluksen sisällä on tyypillisesti tarjolla eritasoisia toimintoja eri käyttäjäryhmille. Esimerkiksi

  • Kaikki käyttäjät saavat luoda uusia rivejä
  • Käyttäjä saa muokata ainoastaan luomiaan rivejä
  • Esimies saa muokata kaikkia alaistensa luomia rivejä
  • Ainoastaan pääkäyttäjät saavat poistaa rivejä
  • Ainoastaan pääkäyttäjät saavat luoda/muokata/poistaa luokittelutietoja

Model-driven Power Appsissa kaikki ylläkuvattu voidaan toteuttaa hyödyntämällä Dataversen monipuolista käyttöoikeusmallia.

Canvas Power Appseissa lähestyminen onkin sitten monesti paljon vaihtelevampaa. Ja vaihtoehtoja on nyt entistä enemmän uusien DataSourceInfo ja RecordInfo -funktioiden myötä. Niiden avulla Power Appsissa voi selvittää käyttäjän käyttöoikeudet (Dataversen) tauluun tai yksittäiseen riviin.

Selvitetään esimerkin avulla, mitä iloa tästä uudesta mahdollisuudesta on.

Esimerkki – Kirjojen ylläpito

Jatketaan parin viikon takaisella teemalla. Tehdään sovellus, jolla ylläpidetään kirjojen tietoja. Sovelluksella on kaksi käyttäjäryhmää.

  1. Käyttäjät – Näkevät kaikkien kirjojen tiedot, mutta voivat muokata ainoastaan lisäämiään kirjoja.
  2. Pääkäyttäjät– Voivat muokata ja poistaa kaikkia kirjoja. Ylläpitävät kirjojen tyylilajeja.

Vanha tapa

Sovelluksemme tarvitsee tiedon siitä, onko käyttäjä pääkäyttäjä. Tämän voi toteuttaa usealla tavalla, joista seuraavia olen nähnyt eniten. Kaikissa esimerkeissä käyttäjän rooli selvitetään sovelluksen käynnistymisen (OnStart) yhteydessä. Sen voi teki tehdä myöhemmässäkin vaiheessa, mikäli se on järkevää.

Ylläpidetään pääkäyttäjiä sovelluksessa

Ensimmäisenä mieleen saattaa tulla tämä. Kirjoitetaan sovelluksen pääkäyttäjät lauseeseen, jossa tarkistetaan onko sovelluksen käyttäjä yksi heistä. Mikäli on, asetetaan muuttujan (varIsAdmin) arvoksi true.

Älä tee näin. Mikäli pääkäyttäjät vaihtuvat (usko pois ne vaihtuvat), tulee jonkun löytää oikea kohta sovelluksesta, osata tehdä siihen muutos ja julkaista sovellus uudelleen.

Hieman raskaan kuuloista.

Ylläpidetään pääkäyttäjiä taulussa/listassa

Fiksumpaa on ylläpitää listaa pääkäyttäjistä jossain muualla, kuin sovelluksen sisällä. Mikäli sovellus tallentaa muutkin tiedot SharePointiin, on luontevaa tallentaa myös pääkäyttäjät SharePoint -listalle.

Tyyli on vapaa. Voit käyttää henkilö-kenttää, jolloin pääkäyttäjien osoitteisiin ei pääse tulemaan typoja. Lista voi olla Dataverse for Teamsissä, Dataversessä, SQL-kannassa, Excel-tiedostossa (älä kuitenkaan) tms. riippuen sovelluksesta.

Power Apps osuus muuttuu vain hieman.

Lopputulos on kuitenkin sama.

Microsoft 365 -ryhmä pääkäyttäjille

Joskus on järkevintä hyödyntää ryhmää. Esimerkiksi kun pääkäyttäjillä on jo oma tiimi Teamsissa.

Sovelluksessa käyttäjä saa pääkäyttäjä-statuksen, mikäli on kyseisen Microsoft 365 -ryhmän jäsen.

Pääkäyttäjän toiminnot

Nyt kun tiedämme, onko käyttäjä pääkäyttäjä vai eikö, on loppu helppoa. Voimme lisätä sovellukseen painikkeen, jolla siirrytään ylläpitämään kirjojen tyylilajeja (genre). Mutta painike näkyy ainoastaan ylläpitäjille.

Visible = varIsAdmin

Lisätään galleria, jossa näytämme kaikki kirjat. Kirjan voi poistaa roskakori-ikonia painamalla. Se ei kuitenkaan ole näkyvillä, kuin pääkäyttäjillä.

Käyttäjien toiminnot

Käyttäjät saavat muokata ainoastaan lisäämiään kirjoja. Pääkäyttäjät saavat muokata kaikkia kirjoja.

Lisätään galleriaan ikoni, jota painamalla siirrytään muokkaamaan kirjan tietoja. Ikoni näkyy ainoastaan pääkäyttäjille, sekä käyttäjille joiden luoma (Created By) kyseinen kirja on.

Visible = varIsAdmin Or ThisItem.'Created By'.'Primary Email' = User().Email

Uusi tapa – Hyödynnetään Dataversen käyttöoikeuksia

Sovelluksemme tietovarastona toimii Dataverse. Mikäli emme ole törttöilleet aivan huolella, meillä pitäisi olla luotuna sovelluksen käyttäjäryhmille omat käyttöoikeusroolinsa (security role).

Pääkäyttäjän rooli (Book Admin) näyttää tältä. Täydet vihreät rivit. He saavat tehdä kaiken.

Käyttäjän rooli (Book User) taas näyttää tältä. Heillä on kirjoihin (Book) organisaatiotason (vihreä pallo) lukuoikeudet ja käyttäjätason (keltainen pieni piirakka) luonti, muokkaus ja liitos (Append) oikeudet. Eli he saavat muokata ainoastaan luomiaan rivejä.

Tyylilajeja (Genre) he voivat lukea ja liittää (Append to).

Täällä on kuvattu kaikki tarpeellinen. Nyt voimme hyödyntää tätä tietoa myös sovelluksessamme.

Onko käyttäjällä oikeus luoda tauluun uusia rivejä?

Milloin näytämme käyttäjälle painikkeen, josta pääsee ylläpitämään käytettäviä tyylilajeja? Silloin kun käyttäjällä on oikeus ylläpitää niitä! DataSourceInfo funktiolla voimme selvittää onko käyttäjällä tauluun X käyttöoikeus Y.

Näytetään painike, mikäli käyttäjällä on oikeus luoda tauluun uusia rivejä. 

Visible = DataSourceInfo(Genres, DataSourceInfo.CreatePermission)

Mitkä käyttäjän oikeudet tähän riviin ovat?

Voimme tehdä saman myös rivitasolla RecordInfo-funktion avulla. Näytetään kirjan kohdalla muokkaa-ikoni ainoastaan mikäli käyttäjällä on oikeus muokata kyseisen kirjan tietoja.

Visible = RecordInfo(ThisItem, DataSourceInfo.EditPermission)

Ja sama kirjan poistamiselle.

Visible = RecordInfo(ThisItem, DataSourceInfo.DeletePermission)

Hienoa! Mutta aivan ilmaista tämä ei ole.

Alkuperäisessä lähestymisessä ikonin näkyminen perustui joko muuttujan (varIsAdmin) arvoon, tai rivillä olevan kentän (Created By) arvoon. Kumpikaan ei aiheuta kyselyä Dataverseen.

RecordInfo-funktio taas tekee kyselyn Dataverseen. Ja jos käytämme sitä galleriassa, tehdään kysely jokaisen rivin kohdalla.

Auts.

Fiksumpaa onkin tarjota käyttäjälle galleriassa ainoastaan linkki/ikoni/painike, jolla kirjan kaikki tiedot saa auki. Ja tällä näytöllä tarjota käyttöön toiminnot, jotka käyttäjällä on oikeus suorittaa.

Näin galleria ei generoi n kappaletta käyttöoikeustarkistuksiin liittyviä kyselyitä.

Yhteenveto

Miksi ryhtyisin hyödyntämään käyttäjän todellisia käyttöoikeuksia perinteisen lähestymisten sijaan? Käyttäjän käyttöoikeudet kuitenkin tyypillisesti tulevat eri ryhmien perusteella (lue lisää). Eikö se nyt ole aivan sama käyttää niitä? Kuten ennenkin.

Käyttäjät voivat kuitenkin saada käyttöoikeusrooleja Dataversessä montaa eri reittiä. Käyttöoikeusrooli voidaan antaa admin-portaalissa vaikka suoraan käyttäjälle.

Tällöin perinteisessä mallissa käyttäjällä voi todellisuudessa olla oikeus suorittaa toiminto, joka häneltä on käyttöliittymästä piilotettu. Uudessa mallissa hänellä on aina kaikki oikeat toiminnot saatavilla.

Käyttöoikeusmalli voi myös muuttua. Päätetään että käyttäjät saavatkin poistaa luomiaan kirjoja. Vanhassa toteutustavassa tämä on muutos sovelluslogiikkaan. Sovellukseen tehdään muutoksia ja se julkaistaan uudelleen. Uudessa mallissa päivitämme käyttöoikeusroolit vastaamaan uutta mallia jonka jälkeen sovelluksessa käyttäjille ilmestyy roskakori-ikonit oikeisiin kohtiin.