search

TIM-JYU / TIM

TIM (The Interactive Material) is an open-source cloud-based platform for creating interactive learning documents.
https://tim.education/view/about/en-US
MIT License
13 stars 4 forks source link

Ladattujen tiedostojen parannuksia #1019

Open dezhidki opened 6 years ago

dezhidki commented 6 years ago

In GitLab by @Smibu on Dec 19, 2017, 10:19

Tässä kortissa tiedostoilla tarkoitetaan myös kuvia.

Versiointi

Lista ladatuista tiedostoista

Tiedoston "siirto"

Tiedoston oikeudet periytymään dokumentista

Kansiokohtaiset tiedostot

dezhidki commented 6 years ago

In GitLab by @vesal on Dec 19, 2017, 10:24

Liitteen nimi voisi tulla aika suoraan aluksi dokun hakemisto + liitteen nimi Silloin lataamalla saman niminen doku uudelleen, se huomattaisiin samaksi ja ehdotettaisin tuota nimen vaihtoa/päälle lataamista. Tämä olisi käyttäjälle aika suoraviivainen tapa kun silloin päällekirjotius tapahtuisi siitä kohdasta jossa lataaminen tehdään.

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 21, 2018, 15:56

Tähän asti toteutettu:

Betalla kokeilussa: https://timbeta.it.jyu.fi/

Periaatteessa tämän hetken tilanteen voisi laittaa tuotantoon. Myöhemmin voi tehdä skriptin, joka käy läpi nykyiset ladatut tiedostot ja asettaa niille isäntädokumentit riippuen siitä, missä dokumenteissa niihin on linkkejä.

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 21, 2018, 16:16

Tuli WUFF...

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 21, 2018, 17:16

Juu, en muistanut, että selainrestartti ei riitä, jos tulee uusi taulu. Nyt toimii.

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 21, 2018, 18:05

vielä on se, että ei voi ladata olemassa olevan päälle. voisiko id joka tuolle tulee, olla docun id ja jos meinaa overridetä olemassa olevan, kysytään uusi nimi tiedostolle, tai automaattisesti laitetaan joku -2 nimiosan perään. jos kuitenkaan ei vaihda nimeä niin menee olmassa olevan päälle. jollon vanhan voisi renameta jollakn versionumerolla jolloin sen voi vielä löytää jos joku tekee kiusaa.

entä miten tehtävien upload? sama koskisi niiden oikeuksia.

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 25, 2018, 12:35

  • Jos dokumentti kopioidaan, siihen ladatuilla tiedostoilla on silloin useampi isäntädokumentti

Kuka saa kopioida tiedsoton? Voiko käydä seuraavasti:

1) kuva on "salattu" 2) joku kopio tiedoston 3) vaihtaa uuden tiedoston anonymous

Pitääkö tuo sallia vai kieltää vai ottaa oikeudet 1. isäntädokumentista? Vai varoittaa kun oikeuksia muutetaan.

Sehän saattaisin mennä vahinggossa noin:

1) kuva on "salattu" 2) joku kopio tiedoston 3) antaa samalla manage oikeudet jollekin 3. henkilölle joka ei tiedä kuvan "salaisuudesta" 4) 3. henkilö vaihtaa dokulle anonymous-oikeudet

Vesa

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 26, 2018, 13:49

vielä on se, että ei voi ladata olemassa olevan päälle. voisiko id joka tuolle tulee, olla docun id ja jos meinaa overridetä olemassa olevan, kysytään uusi nimi tiedostolle, tai automaattisesti laitetaan joku -2 nimiosan perään. jos kuitenkaan ei vaihda nimeä niin menee olmassa olevan päälle. jollon vanhan voisi renameta jollakn versionumerolla jolloin sen voi vielä löytää jos joku tekee kiusaa.

Se voi mennä ihan niin, että jos lataa samannimisen kuin joku aikaisempi, niin kysytään:

entä miten tehtävien upload? sama koskisi niiden oikeuksia.

Tehtävien oikeudethan menevät jo oikein.

  1. kuva on "salattu"
  2. joku kopio tiedoston
  3. vaihtaa uuden tiedoston anonymous

Nykyisellään tuo on siis sallittu ja silloin kaikki näkevät kuvan. Jos tulee tarve, niin voi varoittaa. Tosin saattaisi riittää ihan ohjeteksti oikeuseditorin yhteyteen, että oikeudet periytyvät myös kuville yms.

  1. kuva on "salattu"
  2. joku kopio tiedoston
  3. antaa samalla manage oikeudet jollekin 3. henkilölle joka ei tiedä kuvan "salaisuudesta"
    1. henkilö vaihtaa dokulle anonymous-oikeudet

Tuohonhan ei varoitus kai auttaisi, jos kerta henkilö ei tiedä kuvan salaisuudesta sen enempää. Eli vaikka varoitus näkyisi, niin saatetaan ajatella, että "eipä tässä mitään salaista ole, laitan oikeuden".

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 26, 2018, 15:22

Se voi mennä ihan niin, että jos lataa samannimisen kuin joku aikaisempi, niin kysytään:

  • korvataanko olemassa oleva (jolloin vanha versio häviää), tämä voisi olla oletusvalinta
  • tehdäänkö tiedostosta uusi versio (jolloin vanhan saa kaivettua jollain eri reitillä ja nykyiset URLit antavat uusimman version)
  • tehdäänkö uusi tiedosto (mahdollisesti pakottaen sille eri nimi)

Samannimisyys on siis lähinnä dokukohtaista ja siksi se polun alkuosa voisi minusta liittyä dokuun (vaikka sen id-numero ja sitten kuvan alkuperäinen nimi.)

Tuohonhan ei varoitus kai auttaisi, jos kerta henkilö ei tiedä kuvan salaisuudesta sen enempää. Eli vaikka varoitus näkyisi, niin saatetaan ajatella, että "eipä tässä mitään salaista ole, laitan oikeuden".

Mietitään tätä jatkossa, mutta tässä voisi olla joku että voisi jo dokua kopioidessa jotenkin sanoa että oikeuksia ei saa "heikentää". Eli ei nyt anna tämän häiritä julkaisemista.  Tuon ekan voisi tehdä niin on sitten jatkossa kaikki samalla tavalla.

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 26, 2018, 15:53

Samannimisyys on siis lähinnä dokukohtaista ja siksi se polun alkuosa voisi minusta liittyä dokuun (vaikka sen id-numero ja sitten kuvan alkuperäinen nimi.)

Juu, noita URLeja voi miettiä myöhemminkin. Toistaiseksi en ole niitä muuttanut mitenkään.

Mietittävä esim. jos dokun id on URLissa, niin miten pitäisi käydä URLeille dokua kopioidessa?

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 26, 2018, 16:01

Juu, noita URLeja voi miettiä myöhemminkin. Toistaiseksi en ole niitä muuttanut mitenkään. Mietittävä esim. jos dokun id on URLissa, niin miten pitäisi käydä URLeille dokua kopioidessa?

Eikös se vaan hyvin silloin kerro sen kuvan alkuperäissijannin ja jos kopioiin ladataan uusi kuva, niin eikös sen kuulukkin mennä "omalle uudelle nimelleen" tai sitten se pitäisi käydä lataamassa alkuperäisdokuun vanhalle nimelle, niin muuttuu kopiossakin.

Onko muuten niistä ladatuista ja missä niihin viitataan mitään nopeaa listaa, jolloin uutta samalle nimelle ladattaessa tietäisi moneenko paikkaan lataus vaikuttaa. Toki voi olla TIMin ulkopuolisiakin linkkejä joista ei tietenkään mitään voi tietää ja silloin ne käyttäytyvät kuten käyttäytyvät.

Jos valmista listaa ei ei ole, niin ehkä siinä kysymysken yhteydessä voisi Etsi-toiminolla sellaisen pyytää jos haluaa tarkistaa.  Hidastahan se on (jos hakusanoja ei indeksoisi mutta se lisäsisi tilantarvetta melkoisesti).

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 27, 2018, 14:49

Eikös se vaan hyvin silloin kerro sen kuvan alkuperäissijannin ja jos kopioiin ladataan uusi kuva, niin eikös sen kuulukkin mennä "omalle uudelle nimelleen" tai sitten se pitäisi käydä lataamassa alkuperäisdokuun vanhalle nimelle, niin muuttuu kopiossakin.

Joo, se on ihan järkevä tulkinta.

Onko muuten niistä ladatuista ja missä niihin viitataan mitään nopeaa listaa

Nykytuotannossa ei ole tuota nopeaa "missä viitataan", mutta jatkossahan sekin tulee olemaan. Muutenhan esim. nuo oikeustarkistukset ei pystyisi toimimaan nopeasti.

Ja niille vanhoille uploadeille voi tehdä hakuskriptin, joka linkittää ne dokuihin.

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 28, 2018, 16:54

marked the task Tiedostojen oikeudet pitäisi periä siitä dokumentista, johon ne on ladattu. as completed

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 28, 2018, 16:54

marked the task Skripti, joka assosioi vanhat uploadit dokumentteihin. as completed

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 28, 2018, 16:56

Ja niille vanhoille uploadeille voi tehdä hakuskriptin, joka linkittää ne dokuihin.

Tuo tehty ja ajettu betalla. Hyvin toimi. Laitan huomenna tuotantoon nuo 2 ruksattua. Pienen katkon (5 min) vaatii, koska skripti etsii olemassa olevat uploadit ja assosioi ne.

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 29, 2018, 14:08

Pienen katkon (5 min) vaatii, koska skripti etsii olemassa olevat uploadit ja assosioi ne.

Nyt on tuotannossa.

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 29, 2018, 14:16

Tilastoja tuotannossa:

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 29, 2018, 14:20

  • 5722 kpl assosioitua kuvaa/tiedostoa
  • 3656 kpl orpoa kuvaa/tiedostoa, joihin ei löytynyt linkkejä dokumenteista ja jotka näkee nyt vain niiden lataaja ja adminit

Eli onko yhteensä 9000 vaiko 5700? Pitäisikö noiden orpojen kohtaloa tutkia että miksi niistä on tullut orpoja? Onko ihan sen takia että on ladattu uusi kuva joka on saanut uuden nimen? Vai sellainen on vain ladattu mutta ei koskaan linkitetty. Sellainenhan kai syntyy jos tekee upload, mutta sitten cancel.

Pitäisikö niistä orvoista hankkiutua eroon, eli meneekö niihin paljon turhaa levytilaa?

Vesa

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 29, 2018, 14:27

Eli onko yhteensä 9000 vaiko 5700?

9378 siis yhteensä. Orvoilla ei ole mitään linkitettyä dokua.

Pitäisikö noiden orpojen kohtaloa tutkia että miksi niistä on tullut orpoja?

Kyllä noita muutamia katsoin ja valtaosa vaikuttaisi olevan assosioitujen kuvien vanhempia versioita. Esim. lokitiedostossa orpojen kohdalla näkyy:

Deleting anon access from upload 157789/taulu_iv-kayra_esim.jpg

ja assosioitujen kohdalla on samanniminen mutta id + 1 eli "uusi versio":

https://tim.jyu.fi/view/users/jhsaren/fysa1140_k18/tapaaminen5: adding child 157790/taulu_iv-kayra_esim.jpg

Pitäisikö niistä orvoista hankkiutua eroon, eli meneekö niihin paljon turhaa levytilaa?

Ainakin voisi tutkia ennen kuin poistaa mitään. Suurin osa vaikuttaa olevan kuvatiedostoja.

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 29, 2018, 14:32

Deleting anon access from upload 157789/taulu_iv-kayra_esim.jpg https://tim.jyu.fi/view/users/jhsaren/fysa1140_k18/tapaaminen5: adding child 157790/taulu_iv-kayra_esim.jpg

Ainakin voisi tutkia ennen kuin poistaa mitään. Suurin osa vaikuttaa olevan kuvatiedostoja.

Ehkä ainakin nuo voisi poistaa, joille löytyy vastaava assosioitu nimi eri numerolla. On´gelmaksi toki tulee jos joku on nimennyt noita kuva1 jne..

Jos se joskus ladattaessa kysyy sitä varmistusta, niin silloin voi tuollaisista kuva1 jne nimistä tulle ongelmia jos dokuun on jo aikaisemmin laittanut kuva1 nimisen erilaisen kuvan. Silloin pitäisi varmaan varmistuksessa kysyä että "dokussa on jo aikaisiemmin kuva1, korvaako tämä sen vai nimetäänkö uudelleen".

Ja tutkitaanko jatkossa orpojen syntymisiä silloin kun sellaisen kappaleen sisältö muuttaa tai jopa poistaa, jossa on linkki kuvaan joka on muuttumassa orvoksi?

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 29, 2018, 14:56

Ja tutkitaanko jatkossa orpojen syntymisiä silloin kun sellaisen kappaleen sisältö muuttaa tai jopa poistaa, jossa on linkki kuvaan joka on muuttumassa orvoksi?

Voisi ehkä rattaan takana olla jokin dialogi, joka listaa dokun kuvat ja merkkaa ne, joille ei löydy enää linkkiä dokusta ja jotka voi halutessaan poistaa. Vanhoissa dokun versioissahan niitä linkkejä on, ja on mahdollista, että joku haluaa palata vanhaan. Eli mitään automaattista poistoa ei kai kannata tehdä.

Assosiointiskripti ei käynyt läpi dokumenttien vanhempia versioita (pitäisi joskus toteuttaa sellainen, joka kahlaisi aiemmatkin kappaleet läpi kohtuuajassa).

dezhidki commented 6 years ago

In GitLab by @vesal on Jun 29, 2018, 14:59

Voisi ehkä rattaan takana olla jokin dialogi, joka listaa dokun kuvat ja merkkaa ne, joille ei löydy enää linkkiä dokusta ja jotka voi halutessaan poistaa. Vanhoissa dokun versioissahan niitä linkkejä on, ja on mahdollista, että joku haluaa palata vanhaan. Eli mitään automaattista poistoa ei kai kannata tehdä.

OK, hyvä huomio.

Assosiointiskripti ei käynyt läpi dokumenttien vanhempia versioita (pitäisi joskus toteuttaa sellainen, joka kahlaisi aiemmatkin kappaleet läpi kohtuuajassa).

No lähdetään siitä, että monikaan ei niihin vanhoihin palaa. Jatkossahan tuo ei ole ongelma?

dezhidki commented 6 years ago

In GitLab by @Smibu on Jun 29, 2018, 15:07

No lähdetään siitä, että monikaan ei niihin vanhoihin palaa. Jatkossahan tuo ei ole ongelma?

Ei ole ongelma, koska ne linkitykset säilyy kannassa heti tiedoston uploadaamisesta lähtien.

dezhidki commented 6 years ago

In GitLab by @Smibu on Jul 3, 2018, 14:46

Jäljellä oleva ongelma oli, että haku-regex oli liian tiukka. Se ei löytänyt sellaisia tiedostoja dokuista, joiden kuvausteksti oli tyhjä. Piti vaihtaa regexissä + -> * yhdessä kohti.

Uudet tilastot:

dezhidki commented 3 years ago

In GitLab by @Smibu on Jun 30, 2021, 18:09

unassigned @Smibu

sijualle commented 5 days ago

Jos dokumenttiin A lisää linkin toiseen dokumenttiin B ladattuun tiedostoon (esim[file](/files/1101/Projektiraportti.docx), dokumentista A tulee myös tiedoston isäntädokumentti (rivi blokassociation-tauluun jossa parent on dokumentin A block_id ja child on tiedoston Projektiraportti.docx block_id)

Mutta myös seuraavalla pätkällä dokumentista tulee tiedoston Demo3_vanha.mp4 isäntädokumentti

    ``` {plugin="showVideo"}
    file: /files/13/Demo3.mp4
    #file: /files/13/Demo3_vanha.mp4

Tai jopa

{!!!

file: /files/13/Demo3_vanha.mp4

!!!}



Oikeastaan tuo nykyinen regexiin perustuva linkkejä etsivä periaate on aika onneton ja luo helposti vahingossa uusia viitteitä dokumenteista tiedostoihin. Onkohan tuolle edes syy että linkkiä kopioimalla syntyy myös viite tiedostoon?