Make NC31 compatible.

[beanjammin]

Fixes #264

Changes proposed in this pull request:
Bump the compatibility to NC31 and the version number to 3.6.0.

[Chrisi-Bavaria]

Review is missing here!

[sokai]

@ChristophWurst / @brknkfr / @tflidd – may I ask you gently to assist in approving (and releasing, well ;)) this PR, plz?

You all were involved in #261 (Make NC30 compatible) and @violoncelloCH seems not available (anymore?) … So here we are, like in 2024 … :/

#ty + BR

[ChristophWurst]

Approval is the one thing, we also need someone to release and maintain the app.

[brknkfr]

A simple change of the version is not sufficient. The logging changed, for example ... (see #271 or #272).

[Chrisi-Bavaria]

It's really a pitty: NC 29.0.16 is out of support and I cannot upgrade 30.0.15 because this app is not compatible. Without user_external, we're offline... This functionality should be part of the core of maintained by the project directly.

[VVD]

--- lib/IMAP.php.orig
+++ lib/IMAP.php
@@ -8,6 +8,7 @@ namespace OCA\UserExternal;
  * See the COPYING-README file.
  */
 namespace OCA\UserExternal;
+use Psr\Log\LoggerInterface;

 /**
  * User authentication against an IMAP mail server
@@ -71,7 +72,7 @@ class IMAP extends Base {
                                        $uid = $pieces[0];
                                }
                        } else {
-                               \OC::$server->getLogger()->error(
+                               \OC::$server->get(LoggerInterface::class)->error(
                                        'ERROR: User has a wrong domain! Expecting: '.$this->domain,
                                        ['app' => 'user_external']
                                );
@@ -111,7 +112,7 @@ class IMAP extends Base {
                           $errorcode === 28) {
                        # This is not defined in PHP-8.x
                        # 28: CURLE_OPERATION_TIMEDOUT
-                       \OC::$server->getLogger()->error(
+                       \OC::$server->get(LoggerInterface::class)->error(
                                'ERROR: Could not connect to imap server via curl: ' .  curl_strerror($errorcode),
                                ['app' => 'user_external']
                        );
@@ -122,12 +123,12 @@ class IMAP extends Base {
                        # 9: CURLE_REMOTE_ACCESS_DENIED
                        # 67: CURLE_LOGIN_DENIED
                        # 94: CURLE_AUTH_ERROR)
-                       \OC::$server->getLogger()->error(
+                       \OC::$server->get(LoggerInterface::class)->error(
                                'ERROR: IMAP Login failed via curl: ' .  curl_strerror($errorcode),
                                ['app' => 'user_external']
                        );
                } else {
-                       \OC::$server->getLogger()->error(
+                       \OC::$server->get(LoggerInterface::class)->error(
                        'ERROR: IMAP server returned an error: ' . $errorcode . ' / ' . curl_strerror($errorcode),
                                ['app' => 'user_external']
                        );

[jbsky]

Even if the code is there, your history is not clean. Please correct it so that I can give you an OK review.

[VVD]

Even if the code is there, your history is not clean. Please correct it so that I can give you an OK review.

Are you talking to me or to the author of the pull request?

[beanjammin]

I have moved to using the OpenID Connect app with keycloak for authentication after looking into #266 and considering potential future issues.

[andrewhotlab]

Unbelievable that such an important app is not kept up to date with the supported versions of Nextcloud... maximum respect to them, but maybe Nextcloud GmbH's developers are so much busy integrating generative AI into NC that they've forgotten that a user needs at first log in in order to use all those fancy stuffs? :S

[AndyScherzinger]

Hi @andrewhotlab

user_external is a community app, that is built and maintained by the community and not associated with any employee at Nextcloud GmbH. The repository simply lives inside the Nextcloud Github organization since this makes developers' lifes easier but doesn't make it an officially, company-supported app.

Not the news or feedback you wanted to hear I am sure but this is me stating the facts and current situation. I get the frustration triggering the AI bashing but the AI or any other GmbH work has no link to this app hence no matter what the company would be working on it wouldn't be this app for the moment.

We did try to reach out to @violoncelloCH the maintainer of this app in the distant and recent past without any success so far.

[andrewhotlab]

Thank for your polite reply @AndyScherzinger , and sorry for my rant... but you'll agree with me that such and important feature shouldn't deserve to be left with such a poor support. Obviously it's not Nextcloud GmbH's fault, but if the original maintainer is no longer able to go on with it, which procedure can be activated to solve this impasse? I guess that not anyone can bring the ownership of this repo, right? And forking would fragment the efforts and confuse usera, I guess (but I'm not a dev, so please excuse me if I write nonsense here).

[AndyScherzinger]

Hi @andrewhotlab,

yes I agree, but would do so for basically any app. Somebody or several people spent time on building something useful for themselves and others. So in any case it would be sad to see it vanish or degrade.

Since the repository lives inside the Nextcloud Github organization the admins here can grant further developers access, so they could do changes to the code and potentially release a new version. This way no fork is needed and this would be the good case scenario since it prevents fragmentation and confusion.
The apps get signed by the developer for security reasons (so you are somewhat sure about the origin/authenticity). So what would happen then is that the new maintainer gets a new key to sign and requested via the app store takes over the ownership of the app in the app store to be able to do new releases of the app.

So in short it would be a 3 step process:

1. Find people willing and wanting to maintain the app and take over the ownership here on Github
2. Provide the new maintainer with a key
3. Transfer the app ownership on the app store to the new maintainers

So the above would be the high-level steps. The reasons we are typically very, very conservative with this is that for good reasons people take pride in their work and have a strong sense of ownership. So "taking away" ones ownership at least for the app-store/publishing part is quite an impactful action and has the potential for a lot of conflict with the original maintainers, should they ever come back and feel left out of the decision.

I only know of 2 incidents where ownership got transferred and in both cases it took more than a year to get there. So yes, there is a way to resolve it, it is rarely used, hence relatively unknown. Something to get better at for sure while I still hope it isn't needed that often (hasn't been in the past) because I rather have a thriving community and ecosystem where this isn't needed.

---

So I'll try again to get in touch with @violoncelloCH one more time. In any case since availability might still be an issue in terms of time that can be spent, looking for further community people to join the development and maintenance of the app makes sense I think. So I'll see to have a call to action on the forum anyways.