Evitar superadministrador pueda eliminarse el mismo.

oooooraes

no pues, por seguridad yo les diría que no le puedes dar acceso a esa cuenta a gente que se le puede ir el dedo y borrar la cuenta. Que barbaros jajaja que chistosos son los clientes.

Pues mira, si quisieras quitar ese botón, lo puedes hacer con un js que elimine el botón en esa forma, o usando un hook_form_alter (http://api.drupal.org/api/drupal/modules--system--system.api.php/functio...). Sabes usar los hooks de drupal? A que le hayas más a PHP o a js?

Resolver estas cosas por CSS no es una buena opción, ya que un usuario malintencionado bien puede cambiar el css con firebug o enviar un formulario hecho en casa.

• Jamás daría el user 1 a un cliente. Para ello puedes crear un rol admin y dar los permisos que quieras.
• Para operaciones de este tipo, lo que te recomiendo es que además de modificar el form para que desaparezca el botón, le añadas una función validate().

Para hacer que no aparezca el botón de borrar lo más recomendable es hacer un Hook, ya que con CSS o JS puede seguir habiendo problemas si el usuario utiliza firebug o una aplicación similar.

Para evitar modificar el módulo directamente yo te recomendaría hacer uno personalizado especialmente para esto. Se debe sobreescribir la función user_profile_form, existen dos funciones que puedes utilizar para esto: hook_form_alter o hook_form_FORM_ID_alter. Y el módulo debería tener lo siguiente:

Espero te sirva esto.

Nico, mediante una función preprocess puedes capturar el contenido justo antes de ser enviado al cliente.
En tu caso puedes utilizar la función preprocess: template_preprocess_user_profile
Aqui tienes un listado de algunas de ellas con su explicación:
http://api.drupal.org/api/search/6/preprocess

Por otro lado no recomiendo remover esto por ningún medio desde el cliente (js, css)

Espero que te sirva.

saludos!

luis-san

Leyendo bien el pedido {que el user/1 no pueda eliminarse a si mismo} podemos sacar la siguiente conclusion :

Que el superadmin no esta capacitado para comprender lo que sucede y/o sus implicancias por lo que no deberia ponerse a su alcance dicha opcion. Lo que hace evidente que darle esa capacidad (el user/1) a este individuo es, literalmente, una falla de seguridad.
Es decir, solucionariamos solo el problema que el cliente vio y reporto.

Entonces... si esta persona es capaz de hacer semejante desastre es muy probable que pueda hacer muchisimos otros de gravedad similar, por lo que deberiamos crear una coleccion de hooks APB (a prueba de boludos ;).

A mi juicio yo no meteria hooks (mejor dicho : yo no gastaria mi tiempo) para impedir solo una de las cagadas que pueda hacer este user porque, de todos modos, podria hacer otras.

En cuanto a la solucion del hook, convengamos que es la mas "elegante", pero insuficiente.
Es como matar una mosca (de cientos) con un martillo.

salut

Me parece un asunto delirante... ni por error podría alguien borrar el usuario 1 por esta vía. En cualquier caso, ocultar el botón en el formulario no es suficiente. La url user/1/delete sigue funcionando. Claro, tampoco es de esperar que tal superadmin sea capaz de obtener esa url por sus propios medios.

Para bloquear la url user/1/delete se puede definir un elemento de menu (hook_menu) más o menos así:

por supuesto que no lo he testeado XD.

Era evidente.
Si queres hacer cagadas tenes otros metodos (y sin contar que un superadmin tiene acceso a la SQL y al sistema).

Esto valida todos los conceptos que ya mencione anteriormente:

A. perdida de tiempo inutil (el cliente no te lo va a pagar)
B. Drupal esta diseñado tal como viene.
C. hay otros metodos para hacer cagadas en Drupal (y no solo borrarse a si mismo)
D. ese usuario no puede ser user/1

Por lo que la mejor solucion sigue siendo la de ocultarle el puto boton por CSS (suponiendo que borraria su cuenta por error, claro esta).

salud

ya comienza a dar risa esta cadena...
y lo peor de todo es que el interesado esta esperando que le respondamos por mail !

mucho me temo que el error comienza por ahi :
un tio que escribe en el grupo para pedir ayuda basandose en un pedido semejante y que no consulta el grupo de drupal porque espera que le escribamos a su casilla pues...
creo que deberiamos comenzar por enviarle la factura (del amplio analisis que le hemos ofrecido) a el !
;)

oye oskar...
tu le avisarias al cliente que tambien el user/1 puede hacer otras cagadas graves como desinstalar modules y borrar sus tablas? que piensas que te diria cuando se entere?

bref, creo que ya hemos agotado este tema tan apasionante ;)

salutes

Es un tema interesante pero creo que ya poco tiene que ver con "Evitar superadministrador pueda eliminarse el mismo." seria interesante abrir otro hilo

En un tutorial que estaba viendo http://www.drupalescuela.com/node/21, la parte de escolaradmin, se estaba trabajando con un sitio web para la educacion, algo que he tenido mucha inquietud de saber como hacerlo y estos tutoriales me dieron mucha pista de ello, pero el punto que quiero poner aqui es el siguiente:

Segun el sitio, se tenia que contar con ciertos roles un site admin, secretario, profesor, alumno y padre, para no hacer el cuento mas largo el secretario debia de tener privilegios para crear cuentas y asignarlas a alumno, profesor o padre, para que posteriormente el usuario pueda acceder al sitio e interactuar con sus funciones especificas, el problema que yo le vi o la duda que me surgio y que quiero compartir con ustedes por si se ha dado el caso es:

Como evitar que un rol, pueda crear una cuenta super admin para si mismo, yo le doy privilegios a 1 personas de crear cuentas, llamese clientes, proveedores, alumnos, profesores, maestros, etc, pero evitar que pueda darles privilegios de super admin o admin.

Alguien ha tenido este problema?

Señores como el mismo Administrador se va a borrar su cuanta,un usuario si no debería tener esos privilegios pero eso es otra cosa.