Skip to content
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

[stable24] [LDAP] always create instance of own user manager #35131

Merged
merged 1 commit into from
Nov 14, 2022

Conversation

backportbot-nextcloud[bot]
Copy link

backport of #35070

- it is config specific and cannot be shared
- because the Access instance is bound later, it is not obvious from the
  constructor

Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
@szaimen szaimen merged commit 75568b8 into stable24 Nov 14, 2022
@szaimen szaimen deleted the backport/35070/stable24 branch November 14, 2022 09:42
@blizzz blizzz mentioned this pull request Nov 21, 2022
9 tasks
@michel-nicol
Copy link

michel-nicol commented Nov 22, 2022

For your information, I just upgraded a server from 24.0.7 to 25.0.1 to have the same issue again. Apparently, this has not been merged into 25.0.1 ?
On a positive note I can confirm that it fix the bug in 25.0.1 too, now...

@come-nc
Copy link
Contributor

come-nc commented Nov 22, 2022

For your information, I just upgraded a server from 24.0.7 to 25.0.1 to have the same issue again. Apparently, this has not been merged into 25.0.1 ? On a positive note I can confirm that it fix the bug in 25.0.1 too, now...

No, it will be fixed in both 24.0.8 and 25.0.2 (and 26.0.0)

@michel-nicol
Copy link

Well, This may upset some users as Nextcloud becomes totally unusable if you have more than one LDAP directory... I am no-one to tell you what to do, of course, but this is a major bug. And not all users or administrators are confortable with manually patching a software.

@come-nc
Copy link
Contributor

come-nc commented Nov 22, 2022

Well, This may upset some users as Nextcloud becomes totally unusable if you have more than one LDAP directory... I am no-one to tell you what to do, of course, but this is a major bug. And not all users or administrators are confortable with manually patching a software.

This is why we fixed the bug for the next version.
The bug was discovered once 25.0.1 was already out, how could we have fixed it in 25.0.1?
(Bug was openend 18 days ago, 25.0.1 was released 19 days ago)

@michel-nicol
Copy link

Okay. I knew about the release date and the bug discovery date as I am using the stable channel and only update after the release, confident that it IS stable. But still, I thought it would be possible either to backport the fix into 24.0.7/25.0.1 or warn users that this update has a major bug that can broke their installation, or even block this update if several ldap confs were active ?
Don't get me wrong, I love Nextcloud, and I think you did a great job correcting this bug in only a couple of days. But the principle of leaving a buggy release which can potentialy break a running installation available for users just amazes me...
Well, I'll just change my update policy to wait for a few days after a release is out and check in github beforehand if there is any bug...
(and for the record, if it has been possible, I would have rather written that to you in a private message... )

@come-nc
Copy link
Contributor

come-nc commented Nov 24, 2022

Okay. I knew about the release date and the bug discovery date as I am using the stable channel and only update after the release, confident that it IS stable. But still, I thought it would be possible either to backport the fix into 24.0.7/25.0.1 or warn users that this update has a major bug that can broke their installation, or even block this update if several ldap confs were active ? Don't get me wrong, I love Nextcloud, and I think you did a great job correcting this bug in only a couple of days. But the principle of leaving a buggy release which can potentialy break a running installation available for users just amazes me... Well, I'll just change my update policy to wait for a few days after a release is out and check in github beforehand if there is any bug... (and for the record, if it has been possible, I would have rather written that to you in a private message... )

We follow a strict process for each release to avoid as many bugs as possible. Releasing a new release too fast to fix this one might have introduced a more serious bug, which is why we prefered to go through the normal RC process.
Blocking update to 24.0.7/25.0.1 only on some conditions was not possible as that would require to change the updater code on user servers, which we obviously cannot do.
Blocking update to these versions for everyone would have been possible but on the other hand these versions do fix other bugs that may affect people that do not have multiple LDAPs (which is not that common out there I expect. Most likely users with several LDAPs are big organizations which either have a support contract or at least a rollback procedure, even test instances sometimes).

So yeah communication could have been better, and clearly it was a shame that such a bug passed through testing, but we can’t always catch all of them, and it will be fixed December first with the new releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants