Core_user moodle

API de manipulación de datos de Moodle

Tenga en cuenta que si los usuarios no tienen forma de rellenar un campo obligatorio a través de la edición de sus perfiles (por ejemplo, el campo no es visible o está bloqueado), seguimos devolviendo true. Así que esto es en realidad comprobar si debemos redirigir al usuario a editar su perfil, en lugar de si hay un valor en la base de datos.

Esta función soporta dos modos: Si se omite el parámetro opcional $curso, entonces esta función encuentra todos los cursos compartidos y comprueba si el usuario actual tiene permiso en alguno de ellos, devolviendo true en caso afirmativo. Si se proporciona el parámetro $curso, entonces esta función comprueba los permisos SÓLO en ese curso.

Sólo las preferencias que pueden ser actualizadas directamente serán actualizadas aquí. Este método es llamado desde varios WS actualizando usuarios y debería ser usado cuando se actualizan detalles de usuario. Los plugins pueden poner en una lista blanca las preferencias que pueden ser actualizadas definiendo el callback 'user_preferences', {Ver tambiénocore_user::fill_preferences_cache()}

Campos de la lista de usuarios de Moodle

En cada uno de ellos tendrá que realizar las mismas acciones que antes (por ejemplo, asegurarse de que el usuario ha iniciado sesión y tiene los derechos adecuados para realizar la acción). Por un lado, lleva a duplicar código fácilmente. Por otro lado, hace que la comprensión del script sea muy sencilla.

Moodle buscará la clase a cargar en todos sus subsistemas, en el subdirectorio "classes". Esto incluye todos los directorios de plugins, las clases del núcleo en lib/classes y algunas ubicaciones más. Para encontrar todas las ubicaciones puede simplemente buscar el directorio "classes" en su código Moodle:

Moodle crear usuario api

También vale la pena señalar que la definición lib/classes/user.php utiliza PARAM_USERNAME (no PARAM_RAW) en versiones recientes de moodle. Esto se utiliza para cosas como el núcleo de los servicios web de usuario. Así que te encontrarás con excepciones de parámetros inválidos si especificas un nombre de usuario en formato mixto o con caracteres extendidos (y el parámetro extendedusernamechars está desactivado).

Esto puede ser confuso, parece que has especificado los parámetros incorrectos, pero lo que ocurre es que tu parámetro no cumple los requisitos de PARAM_USERNAME. Para ver el código utilizado para comprobar PARAM_USERNAME echa un vistazo en lib/moodlelib.php :: clean_param().

Api de usuario de Moodle

Esta clase soporta dos tipos de campos: campos de usuario básicos (en la tabla user) y campos de perfil personalizados (en la tabla user_info_data). Debido a que las consultas son más complejas cuando se obtienen campos de perfil personalizados, puede haber algún código que no soporte campos de perfil personalizados.

Cuando se enumeran los campos, un campo estándar de la tabla de usuarios, como el correo electrónico, se denomina correo electrónico. Un campo de perfil personalizado, como uno con el nombre corto rana, lleva un prefijo para que se denomine campo_de_perfil_rana.

Cuando se muestra una tabla de usuarios, siempre se incluye el nombre (y a veces una imagen), como en el caso anterior. Otros 'campos de identidad' son configurables usando el ajuste de administración showuseridentity, y sólo se muestran a los usuarios que tienen permiso para verlos. Por ejemplo, podría configurarse para que se muestren las direcciones de correo electrónico, o los nombres de usuario, o el departamento, o un campo personalizado. Estos campos suelen mostrarse en columnas separadas de la tabla.

La lista de campos de esta función podría incluir campos de perfil personalizados, por ejemplo 'profile_field_frog'. En el código heredado que sólo admite campos en la tabla de usuarios, puede pasar false al segundo parámetro 'allow custom fields' de la función: