Fixes xoa-support#3333
Introduced by 8cfaabedeb
`synchronizeGroups` (called without a user) tries to find XO users that belong
to LDAP groups and add them to those groups. In order to find those users, it
was using the `userIdAttribute` attribute instead of the
`membersMapping.userAttribute` attribute from the configuration.
Fixes#4922
Fixes xoa-support#3216
- xo-server: get error message from updater.py plugin's message and throw it
- xo-web: when counting missing patches, ignore hosts that failed
Fixes xoa-support#3227
Fixes#4546
- Fix already attached SRs not being displayed and show their names
- Refresh SR list after SR has been reattached
- Properly reattach SR:
- Introduce SR (already done)
- Compute device config from form data
- Create PBDs for each host
- Plug in PBDs
- Fix SR list key props to fix loading feedback inconsistencies
- Always show form summary once the SR location has been selected
The "Check certificate" option's default value was incorrectly set in the UI. So if it was left untouched by the user (showing as OFF since `undefined`), it would be saved as `undefined`, and then fallback to the actual default value (`true`) when used in the code. So it would try to check the certificate even though the user didn't want to.
See #1884
When the auth-ldap plugin is configured to synchronize LDAP groups, a group will
only be created in XO when a user that belongs to that group logs into XO. This
commit adds a button that allows an admin to force the synchronization of all
LDAP groups.
This can be useful if an admin wants to configure ACLs for those groups without
having to wait for a user of each group to log into XO at least once.
See #1884
When a user logs into XO using LDAP:
- Create a XO user if it doesn't already exist
- Mark it as being provided by LDAP and bind it to the LDAP user with an ID
- If group synchronization is enabled:
- Fetch all the LDAP groups based on the Base and Filter (plugin config)
- Create and delete the corresponding XO groups based on the LDAP groups that
were found
- Add and remove the XO users from the XO groups based on the LDAP data
Prior to this change, adding a value to an existing set that already contains
that value would replace the whole set with a new one containing only that
value.
This didn't break anything because we usually don't assign `groups` and/or
`preferences` (which are the only 2 properties that need serialization) on user
creation.
This also prepares a minimal change to add a `authProviders` object property on
users.
Fixes xoa-support#2773
The modal uses the type to find the objects (either VMs or snapshots) and use
them to generate the names. The missing type caused the VM clones to be named
`undefined_clone`.
Introduced by 1c042778b6
See xoa-support#2663
It was due to a race condition between the fetch of the default excluded tags
and the fetch of the job (and its schedules) which made the component populate
the form with the job's information.
Changes:
- `Edit` waits for the `job` and the `schedules` before rendering its child
- `New`'s wrapper waits for the `remotes` and the `suggestedExcludedTags` before
rendering `New`
- `New`: `updateParams` is now called in `initialize` because we don't need to
wait for the job and the schedules any more to be able to populate the form
See xoa#55
Requires xoa#58
When an XOA license is bound to another XOA, allow the user to move it to the
current XOA (thus unbinding it from the other one).
See xoa-support#2469
When the user clicks outside of a form modal or presses escape, don't close the
modal as all the information they entered so far will be lost.
We already filter out XSxx patches from normal patches (XSxxExxx) since they're special patches that are meant to upgrade the host to the next version.
Since XenServer has been renamed Citrix Hypervisor, patches names now start with the letters "CH" so we also need to filter out CHxx patches.
From xo-server's API's point of view, it makes more sense for the "snapshot before" feature to be implemented in xo-web since snapshotting a VM is a whole independent process on its own that requires its own API permissions.
Making this change will be especially useful to not over-complicate the permissions checks for the incoming "Self Service snapshots" feature.
See #3693
Pierre Donias