Haluan rajoittaa ryhmäni lukuoikeuksia

...Tai vain kirjoitusoikeuksia.

Tästä asiasta tuntui nousevan pari kysymystä, joten päätin tallentaa muotoilemani mielipiteet johonkin talteen.

Mielestäni on täysin sallittua rajoittaa oma peliprojekti vain oman peliprojektin jäsenille. Mekanismin tarkoitus on olla ensisijaisesti apuväline tiedonvaihtoon, ja mielestäni tätä tarkoitus palvelee myös ryhmän sisäinen tiedonvaihto. Siinä on jo ihan tarpeeksi tekemistä.

Ihan aluksi sananen PmWikin tavasta hallita "ryhmiä"

12:34 <Pervert> Eli "ryhmä" on vähän huono sana, koska sillä tarkoitetaan tapauksesta riippuen joko
12:34 <Pervert> 1) wikiryhmää, kuten Lohkuja/
12:34 <Pervert> 2) käyttäjäryhmää, kuten @Lohkuja
12:35 <Pervert> Kuka tahansa voi asettaa wikiryhmän käyttö-oikeudet, siihen käytetään ryhmän 
                GroupAttributes-sivun -oikeuksia. Eli esim. Lohkuja/GroupAttributes?action=attr
12:35 <Pervert> MUTTA
12:35 <Pervert> GroupAttributes -sivun varsinaisella sisällöllä ei ole mitään merkitystä, vaikkakin 
                tässä tapauksessa olen kirjoittanut sinne käyttäjäryhmän tiedot
12:36 <Pervert> Käyttäjäryhmän asetuksia hallitaan taas tuolla sivulla Mekanismi/UserBase 
                sijaitsevalla (:membership:) -reseptillä, jonka funktio on oikeastaan vain muokata 
                htpasswd ja htgroup-tiedostoja
12:36 <Pervert> Valitettavasti (:membership:) on sikäli rajoittunut, että se tunnistaa vain i) 
                adminit ii) peruskäyttäjät, joista vain admineilla on oikeus luoda käyttäjäryhmiä.
12:37 <Pervert> Samaten vain admineilla on oikeus muuttaa käyttäjäryhmiä.

Tässä siis nykytilanne. Sivulla Kehitysajatukset voi promotoida muutoksia tilanteeseen. Esimerkiksi pelintekijä / projektinjohtaja voisi hyvinkin hyötyä kyvystä muokata ryhmänsä jäseniä.

Vastalause

Toisaalta wikityöskentelyn vahvuus tulee siitä, että samaa dokumenttia pystyy käsittelemään kuka tahansa. Tähän asti olen havainnut, että useat peliprojektit paranevat ulkopuolisesta syötteestä eli palautteesta. Yleistäen myös pelintekijät tuntuvat haluavan projektistaan palautetta.

Olisi erittäin suositeltavaa, että suljetun projektin vetäjät joko

• a) loisivat edes yhden, kaikille avoimen lyhytkuvauksen projektistaan, esimerkiksi ryhmän pääsivulle tai
• b) pyytäisivät ylläpitoa poistamaan ryhmän muutostiedot sivulta AllRecentChanges.

Jälkimmäinen vaihtoehto vähentää ulkopuolisten turhaa uteliaisuutta, ja myös epäkäyttäjäystävällisiä access denied-tyyppisiä virheilmoituksia. Väitän suurimman osan käyttäjistä kuitenkin lukevan Mekanismia nimenomaan AllRecentChanges -koosteen kautta (joko rss:llä tai ilman).

Ainakin Ropeconissa (2008) sain huomattavasti nihkeää palautetta Kolmannen Orleansin sähläys/työtilan "3rdOrleans" acces-denied-sivuista, juurikin siksi, että osa käyttäjistä lukee wikiä ko-sivun kautta. --V

Sisäinen salailu

Helpoimmat mahdolliset ohjeet sivun näkyvyyden rajoittamiseen:

1. Navigoi haluamallesi sivulle ja lisää osoiterivin loppuun ?action=attr
2. Sivuilla on neljä perusoikeutta, joita voi rajata. Read vaikuttaa näkyvyyteen ja Edit muokkausoikeuksiin
3. Lisää Read-kohtaan ne käyttäjätunnukset, joilla on oikeus nähdä sivu muodossa id:Alice,Bob,Carol
4. Lisää Edit-kohtaan ne käyttäjätunnukset, joilla on oikeus muokata sivua yo. muodossa.
5. Paina Save. Järjestelmä varmistaa valinnat kysymällä käyttäjätunnuksesi ja salasanasi.

id:* tarkoittaa ketä tahansa järjestelmään onnistuneesti kirjautunutta käyttäjää (mutta ei anonyymiä kävijää).

Jokaisessa ryhmässä on myös metasivu GroupName.GroupAttributes. Itse sivun sisällöllä ei ole merkitystä, mutta sen ?action=attr -käyttöliittymä määrittelee koko ryhmän näkyvyyden.

Jos ongelmia -> kysy Perv tai Vili tai lue sivulta AuthUser kohta "Controlling access to pages by login".

In English

To be translated.

Siivottu projekteja "Talviuni"-osastolle. Shade 2016-09-19 14:14