Aggiunta blocco modifica profilo utente in base ad una nuova capability

[sviluppoRobyone]

Descrizione

In seguito ad una modifica autonoma dei dati della persona da parte di docenti, ci è stato chiesto di inibire la possibilità di modificare il proprio profilo per evitare problemi privacy e correttezza di dati pubblicati.
Dopo vari test per capire se era possibile togliere singoli campi, abbiamo ipotizzato di bloccare l'accesso alla pagina.

Il tutto avviene per i ruoli che non hanno abilitato la capability nuova "edit_own_profile".

Chiediamo anche a voi un riscontro in quanto attualmente, se non c'è la capability, abbiamo tenuto la retrocompabilità lasciando modificare il profilo.

Checklist

• Le modifiche sono state verificate sui Browser supportati e, in caso di modifiche frontend, per diverse risoluzioni dello schermo.
• Sono stati effettuati controlli di accessibilità in ottemperanza a quanto descritto nell'area "Accessibilità" delle linee guida di design.

[VinsMach]

ciao @sviluppoRobyone ho provato a replicare la vostra soluzione, ho aggiunto la capacità personalizzata edit_own_profile, ma mi son accorto che non riesco a replicare la vista come riportato nello screen... leggendo inoltre il codice leggo "is_admin() && !current_user_can('edit_own_profile')", cioè per bloccare l'utente, quest'ultimo deve avere un ruolo su wp da admin? forse si potrebbe togliere la condizione is_admin ... ma vorrei maggiori dettagli sul funzionamento

grazie

[sviluppoRobyone]

Avevamo aggiunto is_admin per controllare se siamo nella pagina del pannello di amministrazione, effettivamente potrebbe essere tolto.
Per quanto riguarda la replica, è sufficiente aggiungere e loggarsi con un altro utente che al quale non sia stata data la capability (ad esempio il docente che vede le circolari nel nostro caso era un utente Sottoscrittore senza permesso di modificarsi il profilo).
Rimango a disposizione

[VinsMach]

ho dato uno sguardo al vostro codice, e simulato la tipologia di utente... fate una prova con queste righe e ditemi che ne pensate @sviluppoRobyone

function block_profile_editing() {
    $user = wp_get_current_user();
    $user_role = trim($user->roles[0]);
    $role = get_role($user_role);
    if( (! $role->has_cap( 'edit_own_profile' )) && strpos($_SERVER['REQUEST_URI'], 'profile.php') !== false) {
        wp_die(__('Non hai i permessi per modificare il tuo profilo, contatta l\'amministrazione del sito. <br /><a href="index.php">Torna alla bacheca</a>'));

    }
}
add_action('admin_init', 'block_profile_editing');

function remove_profile_menu_for_users() {
    $user = wp_get_current_user();
    $user_role = trim($user->roles[0]);
    $role = get_role( $user_role );

    if( $role->has_cap( 'edit_own_profile' ) ) {
        if (!current_user_can('edit_own_profile')) {
            remove_menu_page('profile.php'); // Removes the profile page from the menu
        }
    }
}
add_action('admin_menu', 'remove_profile_menu_for_users');

function prevent_profile_update($errors, $update, $user) {
    $user = wp_get_current_user();
    $user_role = trim($user->roles[0]);
    $role = get_role( $user_role );

    if( $role->has_cap( 'edit_own_profile' ) ) {
        if (!$update || !current_user_can('edit_own_profile')) {
            $errors->add('no_profile_edit', __('Non hai i permessi per modificare il tuo profilo, contatta l\'amministrazione del sito.'));
        }
    }
}
add_action('user_profile_update_errors', 'prevent_profile_update', 10, 3);

[sviluppoRobyone]

Confermo e ringrazio per le correzioni

[enrimk]

Confermo e ringrazio per le correzioni

@sviluppoRobyone È cambiata proprio la logica del controllo però.

[sviluppoRobyone]

Abbiamo svolto ulteriori verifiche ed effettivamente il controllo della presenza della capability risultava sempre vero e quindi non veniva più garantita retrocompatibilità. Abbiamo inoltre considerato ora che ci sia la possibilità di più ruoli abbinati all'utente.

Ringraziando, attendo nuovo riscontro

[enrimk]

Ma se il controllo di retrocompatibilità viene abbandonato, allora il controllo della capability non sta già tutto in current_user_can('edit_own_profile') ?

[sviluppoRobyone]

Il controllo della retrocompatibilità rimane, nella porzione del codice:

$has_cap = false;

    foreach($user->roles as $user_role) {
        $role = get_role($user_role);
        $has_cap = ($has_cap || isset($role->capabilities['edit_own_profile']));
    }

Se per almeno un ruolo è presente quella capability, allora è lecito chiedersi se quell'utente ha o non ha quel permesso.
Nel momento in cui non ci sono ruoli che l'hanno configurata, ci si trova nel caso attuale di tutti gli istituti che non hanno inserito quella capability e quindi permette la modifica.

Viene cambiato il metodo di controllo, prima con has_cap() il sistema restituiva falso sia per variabile non settata che settata a false

[enrimk]

I ruoli che vengono controllati però non sono quelli/quello dell'utente corrente?

Edit: forse ho capito, davo per scontato che capabilities non fosse popolato sui permessi definiti ma non attivi.

[sviluppoRobyone]

Confermo che prima della porzione del codice riportato qui nei commenti c'è $user = wp_get_current_user(), quindi:

$user = wp_get_current_user();
$has_cap = false;

    foreach($user->roles as $user_role) {
        $role = get_role($user_role);
        $has_cap = ($has_cap || isset($role->capabilities['edit_own_profile']));
    }

Vengono controllati tutti e soli i ruoli dell'utente corrente

[zetareticoli]

Lato feature, mi torna che ci possa essere questo controllo.

Le ultime modifiche introdotte quindi sono da considerarsi finali?

@sviluppoRobyone @marcorubin

[sviluppoRobyone]

Buongiorno,
abbiamo effettuato un nuovo test e corretto un bug trovato.
Abbiamo altresì applicato l'aggiornamento all'Ente che lo chiedeva, avremo un riscontro entro i prossimi giorni.

Vi aggiorno, grazie