Fixes 5603
- Calling POST /graph/v1.0/users with userType not set will create a user as "Member"
- Calling POST /graph/v1.0/users with userType set as "Member" or "Guest" will create a user as "Member" or "Guest"
- Calling POST /graph/v1.0/users with userType set as anything but "Member" or "Guest" returns error
- Calling POST /graph/v1.0/education/users with userType not set will create a user as "Member"
- Calling POST /graph/v1.0/education/users with userType set as "Member" will create a user as "Member" and primary role as parameter specifies
- Calling POST /graph/v1.0/education/users with userType set as "Guest" will create a user as "Guest" and primary role as parameter specifies
- Calling POST /graph/v1.0/education/users with userType not set as anything but "Member" or "Guest" returns error
- Calling PATCH on /users or /education/users will update attribute in the same way as for POST
* graph: Allow updating "surname" and "givenName" of users
Also use attribute getters to lookup the attribute Values instead of fiddling around
with pointers.
* graph: Allow updating education users
Update suppport for education users was still missing.
* A new config option for disabling users with the options "none", "attribute" and "group".
* When set to "none", there will be no enabledAttribute returned in user info and trying to change enabledAttribute will return an error
* Disable/enable group name DN as config parameter
* Adding/removing users to specified group on user update
* Changing log level for service initialization failure to error
* Adding helper methods to check if user is enabled/disabled + tests
Fixes#5554
When refint is enabled on an LDAP server, it will rename all references
to an entity if its DN is modified. If this happens, the member
renames will not be needed, and will also return an error.
This PR does the following:
* Detects the attribute error, and don't return an error.
* Log that the server has been misconfigured.
* Add config value that skips renaming if set.
This is an incomplete implementation of username changing code.
The things still needed to be finished:
* The method that changes the member attribute has to be filled in.
* The functionality needs to be tested.
* Unit tests need to be added.
This adds some initial support for using $filter (as defined in the
odata spec) on the /users endpoint. Currently the following filters are
supported:
A single filter on `id` property of the `memberOf` relation of users.
To list all users that are members of a specific group:
```
curl 'https://localhost:9200/graph/v1.0/users?$filter=memberOf/any(m:m/id eq '262982c1-2362-4afa-bfdf-8cbfef64a06e')
```
A logical AND filteri on the `id` property of the `memberOf` relation of users.
`$filter=memberOf/any(m:m/id eq 262982c1-2362-4afa-bfdf-8cbfef64a06e) and memberOf/any(m:m/id eq 6040aa17-9c64-4fef-9bd0-77234d71bad0)`
This will cause at least two queries on the identity backend. The `and`
operation is performed locally.
Closes: #5487
In preparation for some more advanced queries pass the parse odata request
tVo the identity backend methods instead of the raw url.Values{}. This also
add some helpers for validating $expand and $search queries to reject
some unsupported queries.
Also remove support for `$select=memberOf` and `$select=drive|drives` queries
and stick to the technically correct `$expand=...`.
We don't need to support any complex queries on /education (yet?). And if we would need
to add support for $search, $filter, $expand or $select we should pass the parsed odata Query
instead of the raw url.Values struct.
As described in #5410: add support for updating educationClass properties.
This adds the `UpdateEducationClass` to the `EducationBackend` interface,
and implements it on the `ErrEducationBackend` and `LDAP` backends.
It also alters `PatchEducationClass` to call the `UpdateEducationClass` method.
Closes#5410
GET /education/schools/{school-id}/users
POST /education/schools/{school-id}/users/$ref
and
DELETE /education/schools/{school-id}/users/$ref
are supposed to also work when using the schoolNumber as the
'{school-id}' parameter. This fix that functionality. This also makes the
the mocks for the LDAP Modify operations more specific to avoid using
the generic mock.Anything
To make the `CreateUser` flow easier to test, the attributes of the
LDAP add request need to be added consistently. This way we can
expect that argument with the mock.
This PR does the following:
* Add a method `getUserAttrTypes` that returns a static list of attr names.
* Alter `userToAddRequest` to iterate over the static list, and add the attr
if it exists in the `attrMap`.
Closes#5390
* Renamed files for consistency reasons
err_school.go implements the full education interface not just schools.
ldap_school.go renamed to ldap_education_school.go for making it
consistent with ldap_education_user.go
* graph: Add stubs for education/classes endpoints
The acutal backend implementations are still empty.