Segnalazioni malfunzionamento wiki

[peppe84]

Dopo le 20 forse prima sono entrato.
Stavolta non e il proxy...

[mlazzari2]

Ora dovrebbe  essere *quasi* tutto ok.

Non penso che sia un problema del wiki ma di una pagina in particolare, comunque...
AmministrazioneSistema/FrammentazioneFileSystem
Quando voglio scaricare l'allegato mi riporta la schermata di errore in allegato

[mlazzari2]

Non penso che sia un problema del wiki ma di una pagina in particolare, comunque...
AmministrazioneSistema/FrammentazioneFileSystem
Quando voglio scaricare l'allegato mi riporta la schermata di errore in allegato

Per ora ho sistemato, poi controlleremo anche quello

grazie

da un po fa cosi appena clicco su qualsiasi pagina wiki!

ConfigurationError

IndentationError: unindent does not match any outer indentation level (wikiconfig.py, line 45)

The configuration files are Python modules. Therefore, whitespace is
important. Make sure that you use only spaces, no tabs are allowed here!
You have to use four spaces at the beginning of the line mostly.

ciao

Qualsiasi pagina del wiki cerchi di aprire mi da  ConfigurationError ...   

[nicotano]

in effetti anche io riscontro il medesimo problema nel momento in cui vorrei aggiornare una pagina del wiki, mando una mail di segnalazione

ConfigurationError

IndentationError: unindent does not match any outer indentation level (wikiconfig.py, line 45)

The configuration files are Python modules. Therefore, whitespace is
important. Make sure that you use only spaces, no tabs are allowed here!
You have to use four spaces at the beginning of the line mostly.

[mlazzari2]

da un po fa cosi appena clicco su qualsiasi pagina wiki!

ConfigurationError

IndentationError: unindent does not match any outer indentation level (wikiconfig.py, line 45)

The configuration files are Python modules. Therefore, whitespace is
important. Make sure that you use only spaces, no tabs are allowed here!
You have to use four spaces at the beginning of the line mostly.

ciao

Si, appena possibile vediamo di sistemare!

Ciao

[peppe84]

è appunto un semplice errore di intendazione alla riga 45

http://bazaar.launchpad.net/~ubuntu-it- ... vision/158

Matteo se hai accesso al repo puoi risolverlo anche tu mettendoci il giusto allineamento (prendi ad esempio le righe di sopra e di sotto).

ciao

[mlazzari2]

è appunto un semplice errore di intendazione alla riga 45

http://bazaar.launchpad.net/~ubuntu-it- ... vision/158

Matteo se hai accesso al repo puoi risolverlo anche tu mettendoci il giusto allineamento (prendi ad esempio le righe di sopra e di sotto).

ciao

Grazie Peppe, ora è ok, il fatto è che continuo ad avere problemi con bzr...

Ciao

Una curiosità: le pagine della sezione sicurezza non le posso modificare, giusto?

[peppe84]

E' evidentemente un problema di permessi (e di analisi).
Se avete introdotto le acl gerarchiche la pagina ArpON prende i permessi dalla pagina superiore cioè la pagina sicurezza. E i permessi sono i seguenti:

#acl GruppoAdmin:admin,read,write,revert GruppoEditori:read,write,revert Known:read All:read

Quindi ocio che, a cascata, solo admin ed editori possono modificare le sottopagine. Gli altri utenti registrati essendo degli "Know" possono solo leggere. Se non ci credete fatevi un giro in tutte le sezioni da utente normale (come il mio account) e ve ne accorgerete.

Dovreste commentare questa parte dal wikiconfig.py e fare uno schema di come volete avere i permessi.

Le acl gerarchiche le avevo studiate anche io prima dell'upgrade di marzo (e su sollecitazione di un utente del gruppo newsletter) e conclusi che era meglio evitare di usarle. Questo tipo di configurazione va bene solo per wiki ad esempio aziendali dove si vogliono attribuire permessi per fasci di pagine.

Esempio:
Pagina Logistica e sottopagine: si impostano i permessi nella pagina principale e a cascata tutte le altre pagine saranno accessibili solo all'ufficio logistica (senza specificare in ogni pagina i permessi)
Pagina RisorseUmane e sottopagine: si impostano i permessi nella pagina principale e a cascata tutte le altre pagine saranno accessibili solo all'ufficio risorse umane (senza specificare in ogni pagina i permessi)

E' evidente che per un wiki che svolge due funzioni (team management e raccoglitore di guide) non va bene.

La strategia giusta è quella di sempre: avere dei gruppi e decidere cosa far fare a ciascuno di essi.

Ciao

ps: forse il mio messaggio e il precedente vanno spostati in Segnalazioni malfunzionamenti.

Italian's wiki speaks english...
Per metà
La barra superiore con mostra il testo grezzo, modifica, notifiche, ecc. ecc. ha cambiato lingua

[Milo]

E' evidentemente un problema di permessi (e di analisi).
Se avete introdotto le acl gerarchiche la pagina ArpON prende i permessi dalla pagina superiore cioè la pagina sicurezza.

Sì, è vero.

Quindi ocio che, a cascata, solo admin ed editori possono modificare le sottopagine. Gli altri utenti registrati essendo degli "Know" possono solo leggere. Se non ci credete fatevi un giro in tutte le sezioni da utente normale (come il mio account) e ve ne accorgerete.

Ci crediamo sì, anche perché è così che funziona quell'opzione, solo non avevamo considerato il caso dei portali che hanno la pagina principale con quel tipo di ACL.

Le acl gerarchiche le avevo studiate anche io prima dell'upgrade di marzo (e su sollecitazione di un utente del gruppo newsletter) e conclusi che era meglio evitare di usarle.

Queste cose le avevi riportare quando avevi fatto le prove? Sarebbe stato utile averle disponibili...

Questo tipo di configurazione va bene solo per wiki ad esempio aziendali dove si vogliono attribuire permessi per fasci di pagine.
E' evidente che per un wiki che svolge due funzioni (team management e raccoglitore di guide) non va bene.

Potrebbe andare bebe lo stesso, con un escamotage, un po' macchinoso, oppure utilizzando "acl_rights_after" nella configurazione del wiki che dovrebbe poter garantire i permessi in scrittura dopo che sono stati elaborati tutti gli altri permessi.

La strategia giusta è quella di sempre: avere dei gruppi e decidere cosa far fare a ciascuno di essi.

Sono due concetti diversi, e non è detto che la strategia dei gruppi possa andare sempre bene, vedi i casi di gruppi che hanno bisogno di modificare ACL o eseguire altre azioni solo su un limitato gruppo di pagine. Con i Gruppi questo non lo puoi fare (sono limitati o a tutto il wiki o alla sola pagina dove ci sono gli ACL), con gli ACL gerarchici sì.

Con i gruppi significa che bisogna fare sempre affidamento a un amministratore per modificare gli ACL per un determinato gruppo di pagine, e le persone scarseggiano.

[peppe84]

Non li avevo riportati perché non erano interessanti ai fini della migrazione. Ma avevo fatto dei testi in locale sui permessi, sul jabber bot e sull'openid.

Tutto è nato dal gruppo newsletter che hanno un esigenza di permessi per i lavori in corso...
C'è da vedere come lavora acl_right_after e come lo si può incastrare nell'attuale configurazione. Bisognerebbe fare un altro bel pò di prove in locale.

Per me la soluzione valida sono i gruppi perché evito di usare appunto degli escamotage o delle cose molto complesse.
I casi in cui si se ne ravvisa la necessità sono poche e riguardano pochi utenti.
Basta aggiungere alcuni di questi dentro il GruppoOperatori che ha i permessi di admin o dentro un gruppo ad hoc chiamato GruppoPermessiSpeciali.

A scopo puramente didattico seguendo la guida http://wiki.ubuntu-it.org/AiutoSuListeControlloAccesso dovrebbe funzionare in questo modo:

1) acl_rights_before
2) permessi a livello di ramo (nel nostro esempio la pagina sicurezza)
3) (acl_rights_default)
4) acl_rights_after

Si prenda ad esempio la pagina ArpON. Con acl gerarchico abilitato è così:

1) acl_rights_before = (u"GruppoAdmin:admin,revert,delete,read,write " u"GruppoOperatori:admin,revert,delete,read,write " u"GruppoEditori:read,write,revert,delete ")

2) dopo applica questa: #acl GruppoAdmin:admin,read,write,revert GruppoEditori:read,write,revert Known:read All:read

Dopo il punto due la situazione quindi è questa: admin, operatori ed editori fanno quello che vogliono. I Know e gli All possono solo leggere.

Ed è qui che lui si ferma e non applica l'acl di default che è questo:
acl_rights_default = (u"Known:read,write,revert " u"All:read ")

Ed è a questo punto che mi perdo perchè se aggiungo la regola acl_rights_after = (u"Known:read,write,revert " u"All:read ")
ritorno al punto di parteza e in sostanza le acl gerarchiche non mi servono a un bel niente.

Se avete la soluzione sono molto interessato 

[mlazzari2]

La barra superiore con mostra il testo grezzo, modifica, notifiche, ecc. ecc. ha cambiato lingua

PreferenzeUtente → Lingua Preferita

La barra superiore con mostra il testo grezzo, modifica, notifiche, ecc. ecc. ha cambiato lingua

PreferenzeUtente → Lingua Preferita

Era già impostata in italiano...comunque adesso è tornato tutto ok

[mlazzari2]

Una curiosità: le pagine della sezione sicurezza non le posso modificare, giusto?

Ora si, abbiamo ripristinato il wikiconfig.py, ora dovrebbe essere tutto ok !

Ciao

Una curiosità: le pagine della sezione sicurezza non le posso modificare, giusto?

Ora si, abbiamo ripristinato il wikiconfig.py, ora dovrebbe essere tutto ok !

Ciao

It works

probabilmente c'è un errore in questa pagina http://wiki.ubuntu-it.org/Hardware/Video/DoppioMonitor/Xinerama che riguarda la gestione del doppio monitor con xinerama; sembra che il primo inserimento codice oltre a mancare delle virgolette di chiusura sia doppio