Tietojen muokkausoikeus

[jpek-m]

Toteutus edellyttää näitä ratkaisuja:

1. Pakollisesti ratkaistava, mikä rooli antaa muokkausoikeuden ja mihin tietoihin.
2. Tosiasiassa ratkaistava myös, miten muutokset kirjataan, että ne voi jälkeenpäin tarkastaa tai perua.

Jos tutkija voisi muokata tuontierää, hänen olisi välttämättä saatava samat muutokset omaan aineistoonsa. Jos audit muokkaa tietoja, tieto muutokseta on kai tultava tiedon luovuttajalle?

Liittyy tehtävään #50 (mikä tosin toteutettaneen eri tekniikalla).

[elandal]

Tutkijalla ei pitäisi olla tarveta muokata tuontieräänsä. Auditoijilla on sulautuksessa tarve muokata hyväksyttä tietoa jota ei vielä ole sulautettu. Sulautetun tiedon muokkaamisoikeus kannattaa rajata erittäin tarkasti.

[elandal]

Muutoksesta tulee jäädä tietoon ainakin

• muutoksen kohde
• ajankohta
• muutoksen tehnyt käyttäjä
• vanha tieto
• uusi tieto

Voidaan toteuttaa esim. uudella Change nodetyypillä. Muutoksen kohdenodesta tehdään kopio relaatioineen jne. Kopioon tulee uusi muutettu tieto sekä linkki Change:en. Change edelleen linkki käyttäjään ja vanhaan kohdenodeen. Change nodeen myös muutoksen aikaleima. Muutokseen olisi varmaan syytä aina kirjata peruste. Tekstikenttä, talletetaan Change nodeen.

En osaa sanoa tietokannan tai kyselyn kannalta optimaalista tapaa linkille. Relaatio uudesta nodesta muutosnodeen, siitä relaatio vanhaan kohdenodeen ja käyttäjään? Hauissa pitää tämän jälkeen huomioida, että nodet joihin on relaatio Change tyyppisestä nodesta ovat vanhaa tietoa ja ohitetaan. Muutoshistoria säilyy ja voidaan esittää erikseen kohteesta. Webisivulla kohteessa voi olla linkki/ikoni jota klikkaamalla avaa muutoshistorian. Muutoshistoria on oletettavasti nähtävissä niille jotka ylipäätään kohteen näkevät. Kenties muutoksen tehnyt käyttäjä vain auditoijille?

[jpek-m]

Muutoksen kirjaamisen perusvaikeus on sen kohdistuminen useaan objektiin sekä poistojen hallinta. Miten nähdään muutoshistoria kohteeseen, joka on poistettu?

Helppona esimerkkinä kylännimi "Carla • Kaarila • Karla". Siellä on oletusnimille kaksi kielilinkkiä (place:Place) -[:NAME_LANG {lang:$lang}]-> (name:Place_name) ja kolme tavallista NAME-linkkiä nimivaihtoehtoihin ja lisäksi oletusnimi "Carla" on Place-solmussa.

• Jos oletusnimeksi vaihdetaan "Karla", muutos sisältää yhden solmun ja yhden kielilinkin päivityksen.
• Jos oletusnimen kirjoitusasua muutetaan, se kohdistuu kahteen solmuun
• Nimien järjestyksen muuttaminen kohdistuu kolmeen NAME-linkkiin

Muutosobjekti Change voisi sisältää yleiskuvauksen lisäksi monta riviä [tyyppi, objekti, vanhat arvot, uudet arvot], jossa tyyppi on lisäys/muutos/poisto.

Jos kohdesolmuista tehdään kopioita, se voi tuntuvasti vaikuttaa tietojen selaamiseen, muutoshistoriassa on helposti yhtä paljon solmuja kuin varsinaisessa aineistossa.

[elandal]

Eikö muutosten määrästä seuraava nodejen määrän kasvu ole vain tietokantakyselyjen ja/tai tietokannan rakenteen optimointiongelma? Periaatteessa voi toteuttaa monella tapaa, myös sisällyttäen dataa, ei pelkästään metadataa, Change nodeen.

Poistojen kohdalla oletan, että dataa ei poisteta tietokannasta vaan se arkistoidaan siten, että arkistoidut nodet jäävät tavallisissa hauissa ulos. Tällöin haku joka kohdistuu poistettuun tietoon (oletettavasti mahdollinen vain auditoijille ja ylläpidolle) saa myös poistettujen kohteiden muutoshistorian. Tietokannan optimointikysymys sama kuin muutoshistoriassa jos se toteutettaisiin siten, että vanhat nodet jäävät ja vain linkitetään muutossolmusta.

[PeterJPower]

Muutoksen tekemisen natsoista ajatuksia: Jokainen korjaa oman tarjokaseränsä tietoja vain lataamalla erän uudelleen. Online-muutosoikeus on jokaisella Auditoijalla, uutta roolia ei tarvita. Auditoija-roolia jaetaan siis kaikille sisältö-luotetuille, ei vain tarjokaserien tarkastajille. Tällä tavoin emme joudu enempää näkemään vaivaa rooliemme hallinnan kanssa (tähän muistutus, että joskus myöhemmin pitää palata siihen, mitä SSS:n jäsenyys toisi lisäarvoa Isotammen käytössä: printtaus rajattu vain heille tms). Muutosten tarkka kirjanpito saattaa johtaa volyymien suureen kasvuun ja suorituskyvyn vaarantumiseen. Voisiko rajata esim. kolmen viimeisen muutoksen kierrättämiseen?

[elandal]

Vanhojen muutosten arkistointi voisi tapahtua esim. tekemällä varmuuskopio muutostiedoista (tai muutoin tallettamalla ne tavalla josta voidaan palauttaa), kirjoittamalla näistä erillinen lokitiedosto jossa muutoksista ihmisen luettavaksi sopiva listaus, ja tämän jälkeen poistamalla ne.

Ylläpidolle uusi toiminto, vanhojen muutoston arkistointi?

Voisi olla sellainen jossa kustakin kohteesta jota on muokattu jätetään viimeisimmät kolme muutosta, tai jätetään ihan koko tietokannasta muutokset vaikka viimeiseltä kuukaudelta. Sen verran aikaa, että kiinnostuneet ehtivät reagoimaan ja tarvittaessa jättämään kommentin.

Toisaalta, muutosten arkistoinnin ja poistamisen tarpeesta ei vielä tiedetä. Eli tehdään ensin muutoksen mahdollistavat toiminnot, katsotaan mitä siitä seuraa (paljonko muutoksia lopulta tulee), ja jos muutoksia kertyy suorituskykyyn vaikuttavalla tavalla paljon, toteutetaan arkistointi/poisto?