You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/apis/core/user/index.md
+40
Original file line number
Diff line number
Diff line change
@@ -17,10 +17,50 @@ Please note that, in many cases, more specific APIs may be more appropriate, for
17
17
18
18
:::
19
19
20
+
import { Since } from '@site/src/components';
21
+
20
22
## User field display
21
23
22
24
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.
23
25
26
+
<Sinceversion="4.3"issueNumber="MDL-77353" />
27
+
28
+
### `core_user::get_profile_picture`
29
+
30
+
Generate user picture.
31
+
32
+
-**`user`** - The person to get details of.
33
+
-**`context`** - The context will be used to determine the visibility of the user's picture.
34
+
-**`options`** - Display options to be overridden:
35
+
-`courseid`: course id of user profile in link
36
+
-`size`: 35 (size of image)
37
+
-`link`: true (make image clickable - the link leads to user profile)
38
+
-`popup`: false (open in popup)
39
+
-`alttext`: true (add image alt attribute)
40
+
-`class`: image class attribute (default `userpicture`)
41
+
-`visibletoscreenreaders` true (whether to be visible to screen readers)
42
+
-`includefullname`: false (whether to include the user's full name together with the user picture)
43
+
-`includetoken`: false (whether to use a token for authentication. True for current user, int value for other user id)
44
+
45
+
<Sinceversion="4.3"issueNumber="MDL-77353" />
46
+
47
+
### `core_user::get_profile_url`
48
+
49
+
Generate profile url.
50
+
51
+
-**`user`** - The person to get details of.
52
+
-**`context`** - The context will be used to determine the visibility of the user's full name.
53
+
54
+
<Sinceversion="4.3"issueNumber="MDL-77353" />
55
+
56
+
### `core_user::get_fullname`
57
+
58
+
Generate user full name.
59
+
60
+
-**`user`** - The person to get details of.
61
+
-**`context`** - The context will be used to determine the visibility of the user's profile url.
62
+
-**`options`** - Can include: override - if true, will not use forced firstname/lastname settings
63
+
24
64
## User fields definition
25
65
26
66
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.
Copy file name to clipboardexpand all lines: versioned_docs/version-4.3/apis/core/user/index.md
+40
Original file line number
Diff line number
Diff line change
@@ -17,10 +17,50 @@ Please note that, in many cases, more specific APIs may be more appropriate, for
17
17
18
18
:::
19
19
20
+
import { Since } from '@site/src/components';
21
+
20
22
## User field display
21
23
22
24
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.
23
25
26
+
<Sinceversion="4.3"issueNumber="MDL-77353" />
27
+
28
+
### `core_user::get_profile_picture`
29
+
30
+
Generate user picture.
31
+
32
+
-**`user`** - The person to get details of.
33
+
-**`context`** - The context will be used to determine the visibility of the user's picture.
34
+
-**`options`** - Display options to be overridden:
35
+
-`courseid`: course id of user profile in link
36
+
-`size`: 35 (size of image)
37
+
-`link`: true (make image clickable - the link leads to user profile)
38
+
-`popup`: false (open in popup)
39
+
-`alttext`: true (add image alt attribute)
40
+
-`class`: image class attribute (default `userpicture`)
41
+
-`visibletoscreenreaders` true (whether to be visible to screen readers)
42
+
-`includefullname`: false (whether to include the user's full name together with the user picture)
43
+
-`includetoken`: false (whether to use a token for authentication. True for current user, int value for other user id)
44
+
45
+
<Sinceversion="4.3"issueNumber="MDL-77353" />
46
+
47
+
### `core_user::get_profile_url`
48
+
49
+
Generate profile url.
50
+
51
+
-**`user`** - The person to get details of.
52
+
-**`context`** - The context will be used to determine the visibility of the user's full name.
53
+
54
+
<Sinceversion="4.3"issueNumber="MDL-77353" />
55
+
56
+
### `core_user::get_fullname`
57
+
58
+
Generate user full name.
59
+
60
+
-**`user`** - The person to get details of.
61
+
-**`context`** - The context will be used to determine the visibility of the user's profile url.
62
+
-**`options`** - Can include: override - if true, will not use forced firstname/lastname settings
63
+
24
64
## User fields definition
25
65
26
66
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.
0 commit comments