UserRole

[LiisKasper]

Õiguste kirjeldamiseks Strapisse uus collection UserRole ja collection Function Koosolekul selginenud idee ja mudeli kirjeldus:

User collectionile lisada relatsioon välja nimega my_role. NB olemas on juba roles (mis viitab Strapi andmin paneeli toimetamise õigustele)

Useri juures on olemas viide (my_products) colletionile Product. Product collectionis hetkel aega märgitud pole. Kas käime eraldi aega kontrollimas ProductCategory all v peaks see igale categorile aja lisamisel kuidagi ise ka producti juurde tekkima (lifecycle) Sama küsimus tekib UserRole viitega. Mulle tundub, et tahaks anda rolle kogu productCategorile aga user viide on ühele productile. Kas käime eraldi categori all küsimas v peaks mõlemale collectionile need relatsioonid tekkima?

UserRole collection User.my_roles viitab collectionile UserRole.users, mis on kirjeldatud nii: name korratav component UserRight valid_from valid_to

UserRight, Õiguse kirjeldamine: name function (viide collection Function, alati ainult üks ) read (boolean) write (boolean) execute (boolean) valid_from valid_to

Function, kirjeldus: name description (nt article/123) valid_from valid_to

[LiisKasper]

Lisan mudeli Strapi dev keskkonda. Harusse userright#471

[LiisKasper]

collection Product saab juurde kaks välja valid_from valid_to

Producti õiguseid ja aega loetakse productCategory alti, aja puhul on producti enda juures võimalus täpsustada ajalist kehtivust, sellisel juhul loeme väärtuse producti alt.

[jaanleppik]

• minul tekitab segadust / komistust USERi all olev relatsioon UserRole'le - nimega My_role - minu meelest oleks lihtsam ja arusaadavam, kui see relatioon oleks nimetatud user_role, nagu ka collection, millele see viitab. Seda enam, et selle toimetajaks pole kasutaja ise, vaid toimetaja, e keegi ei hakka sellest rollist mõtlema kui minu rollist. Mis arvate?
• UserRole collectioni poolt relatsioon User'iga - mõtlen, et kui sinna tuleb sadu usereid, siis UserRole poolt seda toimetamine saab olema esimene selline keiss, kus on sellisel hulgal valitud väärtusi. Eks näen, kuidas see õnnestub :)

[jaanleppik]

USERile peaks saama mitut rolli valida, aga praegu ei saa.

[jaanleppik]

Saan aru ses mõttes sest My_role relatsiooni nimest, et see on justkui sarnane My_products relatsioonile.

[jaanleppik]

Loon ka Product_Category juurde relatsiooni UserRole'ga

[LiisKasper]

USERile peaks saama mitut rolli valida, aga praegu ei saa. - Rollil saab olla mitu funktsiooni (õiguse kirjeldust), kas saab ka olla mitu rolli? Ilmselt saab jah, muudan relatsiooni ja välja nime. Aga kindlasti tuleb siis väga jälgida, et mitmele inimesele lisatud rolli ei muudetaks. St peab aru saama, et roll muutub siis kõigil, kellele see lisatud on! Ja sealt edasi sama tuleb jälgid õiguse kirjelduse juures. Ja millisele rollile see kirjeldus on lisatud. Loon ka Product_Category juurde relatsiooni UserRole'ga - Kas ei piisa ainult seosest productiga ja läbi selle info päringutest? See relatsioon on juba olemas. Ok, Category saab ka omada rolli, mis peab kasutajale õiguseid andma

[jaanleppik]

Product on meil üksik product, e näiteks 500 yhte tyypi passi. Nendega kaasnevaid rolle / õigusi ei taha kirjeldada iga yksiku passi juures, vaid selle passi tyybi e kategooria kirjelduse juures.

[LiisKasper]

Jah, Product seotud productCategoriga, saame lugeda infot category alt ka siis kui pole otse relatsiooni categorile. St loemegi nii, sest product all on võimalus kitsendada category õiguseid.

[LiisKasper]

Jaan lisas uue komponendi PeriodRelative, millele on viide PrductCategory all väljalt validity_period_relative. Et oleksime valmis relatiivse aja alsel täitma toote all alguse ja lõpu aegu. Mudel tundub toimiv. Panen live.

[jaanleppik]

• kuidas siduda omavahel roll + funktsioon e õigus + näireks artikkel, millel public on FALSE?
  • peab lisama relatsioone FUNCTIONi juurde? relatsione kõikidele collectionitele, millel on ‘public’ boolean?
  • kas ja milliste ühisnimetajate järgi saaks neid valida? public = FALSE &
    • domeen?
    • festival edition?
    • kõikide collectionite relatsioonid, millede hulgast peab valima?
    • public booleani valik ise kah? sest tekivad ka teised funktsioonid, millede puhul ei kontrollita public booleani, vaid midagi muud?
    • ARTIKLI TÜÜP sobiks ühisnimetajaks siin…
      • luua juurde artikli tüüp, millel public = FALSE
      • ja funktsiooni tingimustes määrata selle lugemise õigus (rolli jaoks), e kõikide seda tyypi e peidetud artiklite, lugemise õigus näiteks. siis ei peaks kümneiod artikleid eraldi valima, vaid määrates artiklile kindla tyybi, liitub artiklle kohe juba loodud loogikaga.

IGATAHES Nimetasin esimese funtktsiooni, mis lubab lugeda PÖFFi artikleid, mille public = FALSE nii: r_not_public_poff_articles r nagu read public staatus artikli tyyp, mis sisulislt markeerib siin ka domeeni

ja siis tegin prooviks ja ettepanekuks, aruteluks FUNCTION CONDITIONS komponendi, kus saaks toimetaja neid funktsioone e õigusi juurde luua, e funktsiooni tinfimuste kaudu kirjeldada Selle komponendi elemendid võib ka lapikuna FUNCTIONI alla lisada, aga praegu tegin komponendina Siis saaks funtsiooni tingiimusi sama loogika alusel juurde hakata ehitama...

[jaanleppik]

https://docs.google.com/spreadsheets/d/1UqH4HGaXagzGc4gPaNL8Y37qFtwl8row4oML_WJkb6Q/edit?usp=sharing

Seal on kirjas, millistele elementidele sai boolean 'public' külge

[jaanleppik]

Course või Industry event (mülemad on kursused laiemas mõttes) -> relatsioon Product Category -> relatsioon User_Role (õpilane ja / või pressi akre omanik ja / või õpetaja)

Mihkel ostab Kursusel B osalemise õiguse - EELDUSED

• On product_category 'Kursusel B osalemine', kus on näiteks 20 toodet e piletit (kuna kusruss mahutab 20 õpilast).
• Product category ja Industry_Event'i B (või Course B) vahel on relatsioon.
• Industry_Eventil (või Coursel) on ka Moodle course ID väli. Kui see on täidetud, siis see tähendab, et kursusel on osi, mis on läbitavad ka Moodles. Selle välja täidab toimetaja - kes loob kursuse nii Strapis kui Moodles. (NB! kust toimetaja saab lugeda moodle course id?)
• (Product category lehel peab olema link ka Industry_Eventile / Coursele, kuhu toode õiguse annab. Nii enne ostu toote sisuga tutvumiseks kui ka peale ostu osalema minekuks.)
• On olemas User_Role STUDENT
• Kui kasutajal on User_Role STUDENT, -- rolli all on funktsioon, mis loeb tema kasutaja andmetest, kas ja milliste kursustega on tal seos: My_Products või My_Prodyct_Categories (et oleks inimloetavalt aru saada, mis kursustele on piletid ostetud.) --- rolli all on funtsioon, mis kontrollibm, kas frontend võib kasutajale näidata kursuse not_public osi
• User'il on ka Moodle_ID väli - kasutaja ID moodle keskkonnas salvestamiseks

Mihkel ostab Kursusel B osalemise õiguse - PROTSESS

• Mihkel ostab toote B123, mis kuulub Product_Category'sse 'Kursusel B osalemine'
• My_products saab seose tootega B123, mis kuulub Product_category'sse 'Kursusel B osalemine'
• Mihkli kasutajale määratakse UserRole STUDENT
• Kui Kursusel B on ka Moodle_ID väli, siis -- Lifecycle kontrollib, kas Mihkli kasutaja e-mailiga kasutaja on Moodles olemas -- Kui kasutajat moodles ei ole, siis lifecycle loob Moodles kasutaja -- Lifecycle kirjutab Moodle kasutaja ID Strapisse User'i andmetesse Moodle_ID väljale -- Lifecycle kirjutab Moodle kasutaja ID Moodles ka kursuse alla, et kasutaja oleks Moodles kirjas kui antud kursusel osaleja.
• Kui Industry / Discovery Campuse lehel kursusel (Industry event / Course) on mitte-avalikke osi, siis -- Frontend kontrollib, --- kas kasutajal on UserRole STUDENT --- kas kasutajal My_Products all seos toodega, mis kuulub Product_Categorysse, millel on seos antud kursusega -- Kui mõlemad tingimused on täidetud, siis näiteb Frontend kursuse not_public osi. Kui vähemalt 1 tingimus pole täidetud, siis ei näita.

Q: Kas kursuse ja kasutaja Moodle_ID võib olla mõlema juures nimetatud Moodle_ID, nagu praegu, või peaks olema nimetatud Moodle_Course_ID ja Moodle_User_ID?

A:

• strapi:course juures moodle_id - UID
• strapi:users-permissions.user juures moodle_id - UID
• igal pool mujal user - relatsioon ja course - relatsioon

[LiisKasper]

Mina pakuks, et moodle_id, nii nagu praegu on. Antud objekti remote(moodle) id. Seni oleme nii lähenenud. Toote küsimusele sain vestluse käigus vastuse.

[mpennaste]

• (NB! kust toimetaja saab lugeda moodle course id?) Mina pole muud viisi leidnud kui et urlirea lõpust olles kursuse lehel nt admin paneelis vms

Samal lehel muidugi näitab ka miskit välja nimega ID, aga see... pole see mida meil Strapisse vaja

[mpennaste]

• -- Lifecycle kontrollib, kas Mihkli kasutaja e-mailiga kasutaja on Moodles olemas

Selle kohta ka, et... esialgu ma kontrolliks kas tema kasutajal pole juba moodle_id küljes (st üks päring mujale vähem), siis kui pole, siis alles kontrolliks kas on juba Moodle kasutaja ja kui pole, siis looks selle. Samas muidugi kui keegi (sh ta ise) oma kasutaja vahepeal ära kustutanud vms, siis see oleks jama. Mõttekoht.

Lisaks mainin ka ära, et kindlasti peab olema kontroll ka kasutaja profiili osas, st Moodle nõuab kasutajat luues kohustuslikke välju ning nendeks on ka eesnimi ja perenimi (lisaks kasutajanimele, e-mailile), seega selleks, et kasutaja luua peavad need täidetud olema.

• Veel infoks, mingi hetk avastasin, et Moodle kasutaja loomise API lubab saata ka "createpassword" = 1 parameetri ning sel puhul saadetakse kasutajale juba Moodle poolt kasutajainfo ja ajutine parool, ma kasutaks seda varianti, jääb ära kasutajakonto loomisel ise random parooli loomine ning meili saatmine. Lisaks sisselogimisel automaatselt palutakse uuendada.

[jaanleppik]

Minu meelest oleks soovitud tulemus selline, et kasutaja ei peaks Moodle keskkonnas eraldi oma kontot haldama, et Moodle kasutamine käiks PÖFFi / Discovery Campuse konto abil. Aga see eeldab, et PÖFFi oma OAuth toimib?

https://www.figma.com/file/zHM1PNRxwZTWuJuRxHYO9M/OAuth_flow

Palun vaadake seda joonist kah ja tulistage auklikuks

[mpennaste]

Minu meelest oleks soovitud tulemus selline, et kasutaja ei peaks Moodle keskkonnas eraldi oma kontot haldama, et Moodle kasutamine käiks PÖFFi / Discovery Campuse konto abil. Aga see eeldab, et PÖFFi oma OAuth toimib?

Igaljuhul on Moodles ju kasutajad eraldiseisvalt (isegi kui oleks seda external DB auth'i kasutanud). OAuth samuti ka seda ju kuidagi ei muudaks, sest PÖFFi OAuth lihtsalt kinnitaks, et Moodle kasutaja emailiga randomemail@example.com on just see kes parasjagu Moodlesse sisse logis. Täpselt samamoodi nagu hetkel seda Google või FB vms nt kinnitab. Või saan ma millestki valesti aru?

[mitselek]

Me ei saa kuidagi piirata inimesel oma moodle profiili haldamist. Kui toimub strapi kaudu kasutaja loomine, võime seda algväärtustada nii hästi, kui oskame aga edaspidi peaksime selle näppimisest hoiduma.

[mitselek]

• "createpassword" = 1

tundub mõistlik. strapi ja moodle on eraldiseisvad (ja iseseisvad) keskkonnad - kui moodles on mingi funktsionaalsus, siis on mõistlik lasta sellel oma asja teha.

aga.

Parooliga autentimine ei peaks olema teema ju.

Paneme selle Argo tehtud oauth teenuse püsti ja Argo kirjutab sinna juurde emailiga autentimise.

[mpennaste]

Parooliga autentimine ei peaks olema teema ju.

Nõus kui oleks need Eesti autentimisviisid ka, aga hetkel sellise seis, et paroolikasutajad PÖFFis on teema ning oleneb kui kiirelt meil midagi vaja on, sest kogu selle logimise ümberväntamine saaks olema "tore" ja mitte lihtne ülesanne, üldse logimise teema. Tulevikus oleks ilmselgelt tõesti hea see asi paroolivabaks saada.

[mitselek]

• kui paroole pole, ei saa neid meilt varastada;
• kui paroole pole, et saa keegi varastatud parooliga meile sisse on veel argumente vaja?

Eesti autentimised + emailiga autentimine on mõlemad ühe oauthi sees - me peame ainult selle oauthi püsti panema ja oma keskkondadle see oauth avada.

[mpennaste]

on veel argumente vaja?

See suur, et olen ma sellele kõigele vastu vaielnud, et niiviisi tulistad?

Ma mainisin lihtsalt ära, et iga autentimisviisi lisamine ei ole nii lihtne, et lihtsalt "peame püsti panema" / "ja oma keskkondadle see ... avada" vaid seal on hunnik koodi backis (kuni node mooduliteni välja) ja front poolel samuti mida peab jälle siis seedima ning toimetama eraldi ja seejuures paroolinduse ka eemaldama. E-mailiga sama oauth kaudu autentimine vähemalt lahendaks ilmselt selle tõesti, et me ilmtingimata ei pea omama inimese isikukoodi (mida meil ei ole).

[mitselek]

Eiei, mu toon oli sobimatu - üldse polnud tulistamist.

Selle oauth teenuse saame hõlpsalt püsti - see on suht nobrainer. Ja strapil oauth teenuse lisamine auth provaiderite hulka on meil ka juba läbi tehtud

[jaanleppik]

https://docs.google.com/document/d/1ZkOUl7gnljAh6EgtXRaY4X3DH6WCHLvnlG460AJ6UAQ/edit?usp=sharing

[jaanleppik]

UserRole (collection)

• name
• valid_from
• valid_to
• product_categories -> Product_Category
• users -> User
• user_rights - repeatable component UserRight -- functions -> UserFunction -- dumb_folders -- smart_folders

[jaanleppik]

UserFunction (collection)

• name
• description
• function_parameters / repeatable component FunctionParameters (asi, mis nõuab veel mõttetööd) -- property -- value

[jaanleppik]

PatternCollection (collection)

• name
• pattern - collectioni nimetus või viide mitmele collectionile korraga, hetkel (Pattern on collectioni nimetus Strapi / URL’i süntaksi järgi)

[jaanleppik]

SmartFolder (collection)

• name
• description
• pattern_collections -> PatternCollection
• conditions (repeatable component) -- property -- value

[jaanleppik]

DumbFolder (collection)

• name
• description
• films -> Film
• cassettes -> Cassette
• poffi_articles -> POFFi_Article
• …s / avatud loetelu relatsioonidest collectionite objektidele

[jaanleppik]

Keiss 1 PRESS kui kasutajate grupp ja PÖFFi artiklite grupp, mis peaks olema loetav ainult PRESS kasutajate grupile

ARTIKLID

• Collection / PatternCollections: PÖFFi_Articles
• public = FALSE
• ArticleType = for_press (includes, st pole ainuke artikli tüüp)

ROLL

• UserRole = PÖFF Press 2022 -- UserRight (component) -- name = Read PÖFF Press Articles -- SmartFolders = Pressi Artiklid / PÖFF -- Functions = show_not_public -- valid_from = 1. jaanuar 2022 12:00 -- valid_to = 31. detsember 2022 12:00

[mpennaste]

Kas juba mõni artikkel ka ses osas olemas?

Lisaks jäi silma:

Koodi jaoks oleks hea kui oleks kõik nagu Strapis otse kasutada saaks, näide:

St siis kusagil Strapis funktsiooni või mille iganes all oleks kirjas ala "public" ja kusagil selle väärtus FALSE ning kui see ja võib olla veel midagi vastab tõele, siis show

[jaanleppik]

Selline artikkel praegu näiteks: https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::pof-fi-article.pof-fi-article/39 sellel on for_press artikli tüüp lisatud nyyd

[jaanleppik]

https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::function.function/1 lisasin funtsiooni parameetritesse kah public = FALSE

[mpennaste]

https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::function.function/1 lisasin funtsiooni parameetritesse kah public = FALSE

Kas siin eeldame siis, et funktsioonis on alati need parameetrid mille alusel soovime näidata, st mitte peita? St eraldi "show"/"display"/"allow" vms väärtust seal pole.

[jaanleppik]

ei tea :) alustame neist generic funtktsioonidest, esimeseks millegi näitamine, mis pole kõigile avalik. ja vaatame, kui kaugele nende paari genereic funtskooniga jõuame: show, edit jne

[mpennaste]

Okei, hetkel meil lihtsalt pole kusagil "show" väärtust vms. Aga eeldame, et siis kui on funktsioon, siis näitame.

[jaanleppik]

jah, võibolla olekski neid funktsiooni parameetreid nii he akasutada, et seal olekski show = TRUE Sest see public = FALSE on juba smart folderi tingimustes olemas, selle koht pole jah funktsiooni juures...

[LiisKasper]

palusid mul mõelda, kuidas teha userRole, mis lubaks teise useri profiili muutmist. Palun välja, et see võiks käia u nii. Kasutaja, enda kasutajat luues, saab endale UUE õiguse muuta enda profiili. (ei tea kuidas seda õigust üle kirjutada, mis asi on smart- ja dumbFolder, kuidas nende sisu loetakse, ainuke millest aru saan tundub olevat function aga ilmselt teisiti, kui teie äriloogikas kokku leppisite, kust ma selle kohta lugeda saaks?) Kui järgmine kasutaja saab õiguse muuta teise profiili, siis olemasoleva kasutaja õiguse juurde paneme kirja järgmise useri ja nii saab ta õiguse juba loodud profiili muuta. (isegi, kui see profiil on tühi) Eeldus, et profiili saab üldse luua on kasutaja olemasolu?!