-
Notifications
You must be signed in to change notification settings - Fork 17
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
0.11.0 release checklist #174
Comments
Pre-release tarball available at https://cloud.owncloud.com/index.php/s/Iuu1tBK997GxqLE NOTE: this tarball is not signed as it is pre-release |
Working:
|
#142 is untesteable. According to http://ldapwiki.com/wiki/EntryUUID the entryUUID value is automatically generated by the server and can't be modified by the user. |
#185 looks fine, although with multiple ldap configuration it returns multiple jsons. I'd rather show only one json with multiple entries such as
Same format for just one configuration. |
@jvillafanez you were testing with AD? and objectguid was in the additional search attributes? |
It was openLDAP with the default configuration, just added the attributes for the quota and mail (group membership also changed to "member"). No additional search attributes were set. |
Testing against samba4 as AD DC:
@jvillafanez for openldap add entryuuid to the search attributes. |
My point is that it's unlikely that people will include that attribute unless told, and there is no warning message that tell the user that he need to include the attribute. This implies that normal users will open tickets feeling that the behaviour is buggy because the command doesn't do what they expect. I'm not sure if it's easy to include the attribute automatically or transparently without user intervention, but it's something we have to try. |
We could just include the configured uuid attribute in the user search. But what we really need is more control over how we want to search. For user sync the uuid attribute alone should be used. there are cases when all uuids change (export, mass change, re import). Then an admin might want to sync based on samaccountname. For that we first need to agree what username, login, id, userid, uuid and email mean when talking about users. If we can agree that
see owncloud/core#30617 and #223 then to REALLY fix this:
actually it is more complicated. we need to introduce a new API in core that apps can implement, because the existing API cannot be changed. If we sent an array or a weird string in the getUsers($pattern) argument old apps would choke, because they expect a string. maybe we can implement a search object that implements __toString() as a fallback? |
Reasons
Full list of PRs is here https://github.com/owncloud/user_ldap/milestone/11?closed=1 but summarised below.
QA
Marketing
Check/adapt info.xml stuffCheck/adapt screenshotBlog post or other communication if applicableDocumentation
Build & Marketplace release
master
@patrickjahnsThe text was updated successfully, but these errors were encountered: