Hakemistorakenne TIMiin #402

Open dezhidki opened 10 years ago

In GitLab by @Smibu on Aug 11, 2014, 15:26

Dokumenteille pitäisi olla hakemistorakenne. Tällöin voisi olle dokumenttikohtaisia css-tiedostoja yms. ko hakemistossa.

Käyttöliittymä voi aluksi olla niin alkeellinen, että jos annan dokumentin nimeksi /ohj1/luentomoniste, niin se luo hakemiston ohj1 (jos sitä ei vielä ole) ja tekee dokumentin sinne.

Tällä voisi sitten yrittää kikkailla niin, että jos Ville tekee monta dokumenttia saman hakemiston alle, niin kaikissa on sama ylä/alapalkki. Saako tuon ihan css:ällä, sillä tavalla, että TIMissä olisi alussa joku lohku tyylillä yläpalkki ja sitten toinen alapalkki lopussa. CSS:ssä sitten voisi antaa noihin sisällöt (voiko siellä laittaa linkkejä???)

Hakemisto-kohtaista CSS:ää editoidaan tässä vaiheessa käsin, joskus sille voisi olla oma editori tai import.

Tuo voisi olla vielä monitasoinen siten, että jos alihakemistolla on alihkaemisto, niin noita dokujen css-tiedostoja haetaan puuta pitkin ylöspäin kunnes sellainen löytyy. TIMin juuressa voisi olla ko css-tiedosto tyhjinä.

Oikeuksien hahmottelua

Tarvittavia kansioon liittyviä oikeuksia:

kuka on omistaja (o)
ketkä voi lukea (katsoa kansion sisällön) (r)
ketkä voi luoda dokumentteja kansioon (c)
ketkä voi luoda kansioita kansioon (f)
ketkä voi muokata kansion oikeuksia (p)

Jotkut oikeudet sisältyvät toisiinsa. Eli jos esim. voi muokata oikeuksia, niin voi tietysti itse luoda kansioita/dokumentteja.

Oikeudet voisi toteuttaa esim. niin, että kussakin kansiossa on tiedosto permissions.txt, joka on tyyliin:

o 1
r 0
c 4
c 8

Eli ensimmäinen sarake on oikeuden tyyppi ja sitä seuraava on sen ryhmän id, jolla on kyseinen oikeus.

Tosin kannattaa varmaan luoda kantaan taulu PermissionType (tai tarkemmin FolderPermissionType):

id | name
 0 | FolderOwner
 1 | AccessFolder
 2 | CreateDocument
 3 | CreateFolder
 4 | ManageFolderPermissions

ja noihin sitten viittaa tiedostossa permissions.txt:

Ilmeisesti oikeuksien olisi hyvä periytyä lapsikansioille joissain tapauksissa, tai ainakin käyttöliittymässä olisi hyvä pystyä asettamaan automaattisesti oikeudet lapsikansioille (niihin joilla käyttäjällä on oikeudet).

Toinen vaihtoehto olisi tallettaa kansioiden oikeudet kantaan käyttämättä erillisiä tiedostoja, mutta meneekö hankalaksi? Kansiot täytyy tunnistaa jotenkin (hakemistopolku?) ja kansioiden siirtely aiheuttaisi luultavasti muutoksia myös kannassa.

Checklist

[x] aliakset ja rinnakiset hakemistot
[ ] hakemistokohtaiset stylesheetit
[ ] hakemiston vaihtaminen raahaamalla
[x] mitä tapahtuu vanhoille linkeille kun hakemistoa vaihdetaan (aliakset?) Ilman aliaksia katkeaa...
[x] hakemistojen oikeudet ja oikeuksien periytyminen
[x] kun luo dokun hakmeiston alla, niin nimeen pitäisi ehdottaa tätä hakemistoa
[x] hakemistorakenteen luominen ilman dokumenttia
[x] oletusoikeudet: edit: "korppiuser", read: anonyous

Vesa Lappalainen

In GitLab by @Smibu on Sep 2, 2014, 13:10

@Smibu @tomijkarppinen Tämä teidän pitäisi kanssa jakaa keskenänne. Ehdotan että Mika ainakin aloittaa, koska tämä vaatii syvempää TIMin ymmärrystä. – Vesa Lappalainen

In GitLab by @Smibu on Sep 12, 2014, 12:31

@Smibu @tomijkarppinen Ruvetkaa tätä miettimään.

Samalla oli jossakin kortti siitä, että dokumenttiin pitäisi voidaa viitata muutenkin kuin vain /view1, eli mieluusti tyyliin view/ohj1 eli tuon synonyymin voisi antaa samalla kun dokun luo tai ainakin managessa. – Vesa Lappalainen

In GitLab by @Smibu on Nov 18, 2014, 16:30

Sitten kun tätä hakemistorakennetta aletaan tekemään, niin kannattaa samalla tehdä niin, että jokainen dokumentti on omassa repossaan (hakemistossa). Se luultavasti helpottaa Villen käyttötapausta (että voi kloonata dokumentin ja siihen liittyvät kamat itselleen ja pushia muutoksia omalta koneelta) ja sitten myös tuota versiohistoriahakua.

In GitLab by @Smibu on Jan 7, 2015, 13:12

@vesal @tomijkarppinen Lisäsin tuohon kuvaukseen kansioiden oikeuksien hahmottelua. Voi kommentoida kuvaukseen tai kommenteilla.

In GitLab by @Smibu on Jan 7, 2015, 13:57

@Smibu Minusta tuo että dokun voisi siirtää mahdollisimman pienellä vaivalla kansiosta toiseen, olisi hyvä. Eli dokuilla voi silti olla sisäinen juokseva numero, jolla niihin tehdään viitteet, mutta sitten sijainti on jossakin hakemistossa (onko silloin .git mukana?). Kannassa ehkä ainoa viite olisi se että mistä kansiosta/tiedostosta tietyn id:n odku löytyy. Tosin jos tuo id pysyy vakiona, niin silloin toki oikeudetkin voivat olla kannassa tuon id:n perusteella. – Vesa Lappalainen

In GitLab by @Smibu on Jan 7, 2015, 14:19

@vesal IRC-keskustelua:

14:10 <@mikkalle> kun mietin sitäkin että kannattaako dokumenteista tallentaa mitään viitteitä kantaan eli saisiko niidenkin oikeudet paremmin tiedostojen avulla

14:11 <@mikkalle> eli jos haluaa dokun niin url olisi aina jotain /view/ohjkurssit/ohj1 eikä mikään id

14:12 <@mikkalle> sinänsä kannankin avulla onnistuu, mutta sitten täytyy kanta ja hakemistorakenne olla linkitetty, esim. kannassa on dokun polku

14:13 <@mikkalle> ja sitä sitten pitää osata päivittää, jos dokua/kansioita siirtelee

14:13 <@tojukarp> Joo, ehkä se kannattaa pitää siellä tiedostossa.

14:14 <@tojukarp> Kantaan sitten ehkä myöhemmin joku välimuisti (tai Ephemeraliin jos sitä käytetään vielä) jos menee hitaaksi.

14:14 <@mikkalle> joo

Eli kannattaako kannassa lopulta pitää ollenkaan viitteitä dokuista, jos tuo hoituu tiedostojärjestelmän kautta?

Edit:

14:31 <@mikkalle> no jaa kyllähän siellä kannassa varmaan se dokun id täytyy olla jotta kommentit ja lukumerkinnät voi linkittää

14:33 <@mikkalle> mutta voihan myös tehdä niin, että kun dokun repon luo, niin kansionnimeksi tulee vaan sen id. Silloin ei tarvi päivitellä kantaa, jos siirtelee

In GitLab by @Smibu on Jan 7, 2015, 14:21

Ja tehdäänkö niin kuin silloin joskus suunniteltiin git-repo jokaiselle dokumentille erikseen? – Tomi Karppinen

In GitLab by @Smibu on Jan 7, 2015, 14:27

@tomijkarppinen @vesal Joo, eli 1 repo per dokumentti on mielestäni joustavaa. Versiohistoriahaku nopeutuu ja dokumenttiin liittyvät muutkin mahdolliset tavarat (vaikka ne CSS-tiedostot) voi versioida samaan repoon. Dokumenttien siirtely on helppoa myös.

In GitLab by @Smibu on Jan 7, 2015, 15:15

@Smibu @tomijkarppinen Hakemiston fyysisellä nimellähän ei kai hirvesäti ole väliä. Tärkeint on että käyttöliittymä saadaan sen näköiseksi, että siinä on kansioita jotka voivat olla sisäkkäin. Tällaisenhan pystyisi periaatteessa tekemään ihan flättinäkin (eli kaikki samalla tasolla ja kanta määrää hierarkian), mutta suorasta hierarkiasta voi olla etua noissa oikeuksisa ja stylesheeteissä.

Mulla esim. ComTestissä on niin, että tiedostoa ComTest.ini etsitään nykyhakemistosta. Jos ei löydy, niin pykälää ylempää jne kunnes löytyy. Jos ei löydy käytetään oletuksia (joka TIMissä voisi olla ylimmältä tasolta löytyvä vastaava tiedosto).

Näin voisi oikeudet ja sylesheetit (esim. documentstyleheet.css) kumota toisiaan, mutta peiytyminen tulee helposti kun teen kansion ohj1 (mikä sitten sisäinen nimi onkaan) ja laitetaan sen alle perusjutut. Sitten alihakemistossa moniste, ei tarvitse olla mitään, koska ylöspäin kiipeämällä löytyy tuo vastaava tieto.

Mites versionhallinta hoitelisi tuon ylemmän kansion tavaran?

Ja kannattaako jokainen doku olla oma repo, vai aina yksi hakemisto? Eli jos m ulle tulee Ohj2:een 12 kpl Demo 1, Demo 2 jne dokuja, niin onko kätevämpi että ne ovat samassa demot-repossa.

En tosin tiedä voiko jotekin repon tehdä vain samassa tasossa olevista tiedostoista? – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2015, 15:40

@vesal Betalla on nyt kokeilussa kansiorakenne. Sisäisesti toimii flättinä ja oikeuksia/stylesheettejä ei vielä ole. Jos tekee uuden dokumentin esim. ohj1/demo1, niin syntyy automaattisesti kansio ohj1 ja siihen voi viitata urlilla tuohon haluttuun tapaan ja pääsivulla näkyy kansiona. – Tomi Karppinen

In GitLab by @Smibu on Jan 11, 2015, 18:04

@tomijkarppinen @Smibu Hyvältä näyttää alustavasti.

Jonkin verran tuntuu kestävän hakemiston sisällön saaminen?

Manage menee vielä id:llä (ja oikeastaan id saakin toimia rinnalla, koska on jo niin paljon linkkejä 1 ja 2 dokuhuihin). Mutta manageen ei pääse nimellä (ei vakavaa tähän hätään, editiin pääsee)

Sitten taisi käydä huonosti Mikan tiedoston paloittelulle, eli syntaksille view/1/200/300

Kun luo uuden dokun alihakemistossa ollessaan, niinn varmaa nimen pitäisi tulla suhteellisesti, eli jos luon /ohj1/demot -hakemistossa tiedoston demo3, niin se voisi tulla nimelle /ohj1/demot/demo3 Ehkä niin, että edit-lotjuun laitettaisiin tuo etuosa odottamaan niin käyttäjälle ei tule epäilystäkään mihin tulee. – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2015, 18:15

@vesal Laitanko samantien tuotantoon? Voin vaikka huomenna katsella noita parannuksia. – Tomi Karppinen

In GitLab by @Smibu on Jan 11, 2015, 19:32

@tomijkarppinen Ei vielä. Mulla on linkkejä view/1 ja view/2 ja nuo eivät toimia ainakan betassa tällä hetkellä. Noita id ja nimi -muotoa pitää elättää rinnakkain vielö jonkin aikaa. Sitten tuleeko välilyönneistä yms ongelmia? – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2015, 19:41

Voihan sen laittaa toimimaan rinnakkainkin jos sovitaan että ei tehdä dokumentteja joiden nimet on pelkkiä numeroita. Välilyönnit koodautuvat automaattisesti 'Reference to deleted milestone 20':ksi. – Tomi Karppinen

In GitLab by @Smibu on Jan 11, 2015, 19:46

@tomijkarppinen Se täytyy ainakin käyttöliittymässä estää sitten :-)

Vaihtaakos tuo nyt "hakmeistoa" jos renameaa managessa tiedoston? – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2015, 19:49

@vesal Vaihtaa. Ja tyhjät hakemistot häviävät automaattisesti. – Tomi Karppinen

In GitLab by @Smibu on Jan 11, 2015, 19:51

@tomijkarppinen Jos tuon view/id saa toimimaan, niin sitten saa laittaa tuotantoon, mutta jos tuo vaihtaa hakemistoa, niin ei tuossa mitään vakavaa ole vaikka nuo ensi viikolla vaihtelee järkeviin alihakemistoihin. – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2015, 23:34

@tomijkarppinen Paitsi kun laition /ohj1 niin kävi huonosti :-) Eli kannataa nimestä poistaa mahdollsiet alkuerikoismerkit :-) – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2015, 23:48

@tomijkarppinen Tarviiko se muuten urlissa tuota folder=?

Eikö saa niin, että jo on nimi, joka ei pääty dockumenin nimeen, niiin silloin on folder-nimi. Olii käyttäjälle loogisempaa kun riisuu urlista vähän pois niin menee vastaavaan yläkansioon.

Voisiko jopa mennä niin pitkälle, että jättäisi koko view pois tuosta? Jos edit yhdistetään view. niin silloin tuo view tulee tarpeettomaksi. Toki on pakko vielä elättää pitkään, kun on niitä view-linkkejä. MUTTA koska vielä ei ole yhtään view/nimi linkkiä, niin voisi pyhittää niin, että jos haluaa id:llä näyttää, niin pitää olla se view.

Ja view ja manage nimiset päätason hakemistot kielletään :-)

eli tim.it.jyu.fi/ohj1 => näyttää ohj1 kansion tim.it.jyu.fi/ohj1/demot => näyttää demot kansion tim.it.jyu.fi/ohj1/demor/demo1 => näyttää dokumentin demo1 koska sellainen sattuu olemaan

tim.it.jyu.fi/view/1 => näyttää dokumentin jonka id on 1

tim.it.jyu.fi/manage/ohj1 => antaa vaihtaa ohj1 hakemiston nimeä esim

tim.it.jyu.fi/manage/ohj1/Ohjelmointi 1 => antaa muokata Ohj1 monistetta tim.it.jyu.fi/manage/1 => sama muokkaus

@Smibu Tuolle Mikan dokumentin osan näyttämisella voi joutua keksimään uutta URL-syntaksia (jossa ottaa huomioon myös tietyn otsikkotason) – Vesa Lappalainen

TIM-JYU / TIM

Hakemistorakenne TIMiin #402

Oikeuksien hahmottelua

Checklist