-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Fix account data visibility after disabling public addressbook upload #25417
Fix account data visibility after disabling public addressbook upload #25417
Conversation
Master is Nextcloud 22 now. |
/backport to stable21 |
d543016
to
a33daca
Compare
a33daca
to
588af7a
Compare
Rebased and fixed up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't test but I trust your test writing skills
I hope we will not regret that :-P |
I pushed the backports to stable19 and stable20 before this was merged because they needed some adjustments but I will probably be on vacation when this is merged. |
588af7a
to
8d74cec
Compare
Rebased and adjusted to changes introduced in #26243. Acceptance tests failure is known and unrelated. I dropped the last commit because it was no longer needed (it handled corrupted scope values by showing them with an error icon in the UI, although that no longer applies due to them being now returned as local scope), but the rest still applies. I have also found some issues related to #26243 (it should be possible to set federated scope even if the lookup server is disabled, and contact data should be shown in contacts menu even if scope is local), but for clarity they will be addressed in other pull requests. |
Conflicts 😢 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks ok, tests very much appreciated :) I did some smoke testing, which was fine, too.
8d74cec
to
5a083fe
Compare
Rebased and resolved :-) |
Uh... wait, I spoke too soon, most tests fail, let me check :-) |
5a083fe
to
0b8248b
Compare
It seems that most of the failures were internal GitHub errors. There are some PHP CS errors, but they seem to be in master as well. The Handlebars test has failed again, but in my system build/compile-handlebars-templates.sh passes. So I do not know if it is a problem with GitHub or my system 🤷 Besides that, I noticed a small issue related to the previous conflict (in some areas of the disabled menu item the cursor was a pointer, because all items in a link element use |
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Right now it makes no difference, but this should make future tests clearer, specially in case of failure. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"AccountManager::updateUser()" wipes previous user data with whichever user data is given (except for some adjustments, like resetting the verified status when needed). As the controller overrode the properties those properties would lose some of their attributes even if they are not affected by the changes made by the controller. Now the controller only modifies the attributes set ("value" and "scope") to prevent that. Note that with this change the controller no longer removes the "verified" status, but this is not a problem because, as mentioned, "AccountManager::updateUser()" resets them when needed (for example, when the value of the website property changes). This change is a previous step to fix overwritting properties with null values, and it will prevent the controller from making unexpected changes if more attributes are added in the future. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The controller can receive an optional subset of the properties of the user settings; values not given are set to "null" by default. However, those null values overwrote the previously existing values, so in practice any value not given was deleted from the user settings. Now only non null values overwrite the previous values. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"parsePhoneNumber()" expects a string, so a TypeError would be thrown if the phone number value is null. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Depending on some settings (for example, if lookup server upload is disabled) some items can be hidden in the scope menu. However, if the user selected an scope in the past once the settings were changed the scope was no longer visible in the menu. Now the active scope will be always visible in the menu, although if it is an excluded scope it will be disabled. Selecting any other scope will then hide the excluded and no longer active one. When upload to the lookup server is disabled the scope menu was hidden for display name and email in the personal information settings; now the menu will be always shown to enable the above described behaviour. Note that the menu will be shown even if there is a single available scope so the user can read its description. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
0b8248b
to
da84ed7
Compare
After the last rebase everything is now green :-) |
When the lookup server upload was disabled the scope menu was hidden in the properties of the profile information. If any property was then changed the request did not contain any scope information, so the
UsersController
automatically set them to null. However, as the controller fully overwrote the previous properties this caused the scope of the properties to end being null. In practice, this caused that if a user changed her name from the profile information when uploading to the public address book was disabled that user could not be searched either in the local instance or from trusted servers.Moreover, the user was not able to reset the visibility from the profile information, even if uploading to the public address book was enabled again.
Although this pull request fixes the controller it does not repair any corrupted visibility, as it is not possible to know whether the user had a public, contacts or private visibility before it got corrupted. Repairing the visibility by setting by default anything above private could be seen as a privacy issue, and setting the visibility to private would hide the problem from the user if that user wants to be found by other contacts. Update: since #26243 any invalid scope is treated as local. Despite that, except for the original last commit (which is still needed and thus included in the
stable19
andstable20
backports), the rest of the commits still apply.Nevertheless, I was wondering if it would be worth adding a repair step to check if the visibility of any property is null and then create a notification to the user so she can fix it. Or adding a command to fix the visibility to some value (but this would be something to be explicitly done by the admin, so it would be her responsibility).How to test (main scenario)
Result with this pull request
The user is found.
Result without this pull request
The user is not found.
How to test (corrupted visibility subscenario) -
stable19
andstable20
Result with this pull request
Visibility of properties can be set. Visibilities with an invalid value (all of them) will show an error.
Result without this pull request
Visibility of properties can not be set. Even if Allow users to publish their data to a global and public address book is enabled again the visibility can still not be set, as the scope is null.
How to test (corrupted visibility subscenario) -
stable21
and laterResult with this pull request
Visibility of properties can be set. Even if there is only one value available it will be possible to show the menu to read its detailed description.
Result without this pull request
Visibility of properties can not be set. If Allow users to publish their data to a global and public address book is enabled again the visibility will be shown as Local (and in the database it will be
null
).How to test (public visibility when public upload is disabled subscenario)
Result with this pull request
Visibility of user name shows "Public" as selected, but disabled. Changing the visibility to a more restricted value removes the "Public" option.
Result without this pull request
No visibility is shown.