Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MDL-77353 Functions for generating and displaying user details #635

Merged
merged 1 commit into from
Dec 1, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions docs/apis/core/user/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,10 +17,50 @@ Please note that, in many cases, more specific APIs may be more appropriate, for

:::

import { Since } from '@site/src/components';

## User field display

The [User fields](https://docs.moodle.org/dev/User_fields) class is mainly used when displaying tables of data about users. It indicates which extra fields (e.g. email) should be displayed in the current context based on the permissions of the current user. It also provides ways to get the necessary data from a query, and to obtain other generally-useful fields for user names and pictures.

<Since version="4.3" issueNumber="MDL-77353" />

### `core_user::get_profile_picture`

Generate user picture.

- **`user`** - The person to get details of.
- **`context`** - The context will be used to determine the visibility of the user's picture.
- **`options`** - Display options to be overridden:
- `courseid`: course id of user profile in link
- `size`: 35 (size of image)
- `link`: true (make image clickable - the link leads to user profile)
- `popup`: false (open in popup)
- `alttext`: true (add image alt attribute)
- `class`: image class attribute (default `userpicture`)
- `visibletoscreenreaders` true (whether to be visible to screen readers)
- `includefullname`: false (whether to include the user's full name together with the user picture)
- `includetoken`: false (whether to use a token for authentication. True for current user, int value for other user id)

<Since version="4.3" issueNumber="MDL-77353" />

### `core_user::get_profile_url`

Generate profile url.

- **`user`** - The person to get details of.
- **`context`** - The context will be used to determine the visibility of the user's full name.

<Since version="4.3" issueNumber="MDL-77353" />

### `core_user::get_fullname`

Generate user full name.

- **`user`** - The person to get details of.
- **`context`** - The context will be used to determine the visibility of the user's profile url.
- **`options`** - Can include: override - if true, will not use forced firstname/lastname settings

## User fields definition

To guarantee the sanity of the data inserted into Moodle and avoid security bugs, new user fields definition methods have been created for use in Moodle 3.1 onwards. The purpose of these new methods is to create a central point of user fields data validation and guarantee all data inserted into Moodle will be cleaned against the correct parameter type. Another goal of this new API is to create consistency across Moodle core and avoid different parameter validations for the same user fields. For now on, user data must validate against the user field, not using clean_param() directly.
Expand Down
40 changes: 40 additions & 0 deletions versioned_docs/version-4.3/apis/core/user/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,10 +17,50 @@ Please note that, in many cases, more specific APIs may be more appropriate, for

:::

import { Since } from '@site/src/components';

## User field display

The [User fields](https://docs.moodle.org/dev/User_fields) class is mainly used when displaying tables of data about users. It indicates which extra fields (e.g. email) should be displayed in the current context based on the permissions of the current user. It also provides ways to get the necessary data from a query, and to obtain other generally-useful fields for user names and pictures.

<Since version="4.3" issueNumber="MDL-77353" />

### `core_user::get_profile_picture`

Generate user picture.

- **`user`** - The person to get details of.
- **`context`** - The context will be used to determine the visibility of the user's picture.
- **`options`** - Display options to be overridden:
- `courseid`: course id of user profile in link
- `size`: 35 (size of image)
- `link`: true (make image clickable - the link leads to user profile)
- `popup`: false (open in popup)
- `alttext`: true (add image alt attribute)
- `class`: image class attribute (default `userpicture`)
- `visibletoscreenreaders` true (whether to be visible to screen readers)
- `includefullname`: false (whether to include the user's full name together with the user picture)
- `includetoken`: false (whether to use a token for authentication. True for current user, int value for other user id)

<Since version="4.3" issueNumber="MDL-77353" />

### `core_user::get_profile_url`

Generate profile url.

- **`user`** - The person to get details of.
- **`context`** - The context will be used to determine the visibility of the user's full name.

<Since version="4.3" issueNumber="MDL-77353" />

### `core_user::get_fullname`

Generate user full name.

- **`user`** - The person to get details of.
- **`context`** - The context will be used to determine the visibility of the user's profile url.
- **`options`** - Can include: override - if true, will not use forced firstname/lastname settings

## User fields definition

To guarantee the sanity of the data inserted into Moodle and avoid security bugs, new user fields definition methods have been created for use in Moodle 3.1 onwards. The purpose of these new methods is to create a central point of user fields data validation and guarantee all data inserted into Moodle will be cleaned against the correct parameter type. Another goal of this new API is to create consistency across Moodle core and avoid different parameter validations for the same user fields. For now on, user data must validate against the user field, not using clean_param() directly.
Expand Down
Loading