you're welcome, I'm closing this...

hey, so you were right . when I set the field "User active" to "Block" and "Invert active values" , it works now. Thank you.

By the way: If you go through the Joomla docs you'll notice that the column "activation" is meant for a completely different thing: It controls whether activation emails are to be sent!
You want the column "block" and, of course, need to check the "invert active value" box.

I went over your screenshot of the app configuration again and I think I found your problem: You must activate "Invert Active Value" (I did not bother entering the table for "User Active Column" in the first place)

But my MySql Server ist configured by Plesk. Maybe here are another settings adjusted.

I did not change the configuration of the sql server. I just created a new local user and selcted "Create database with same name and grant all permissions" in phpMyAdmin.

okay, that's strange. maybe its a misconfiguration of my mysql server? can you give me the config of your mysql server? so I can compare it

I just did a fresh installation of Debian Jessie, ownCloud 9.1.0, user_sql 2.3 and Joomla 3.6.2. Everything went without problems, my Joomla user is in the list and is able to login.

Okay, Thanks for your time!

That's really strange. The log doesn't even include information about ownCloud trying to list the users from the user_sql backend.

Yes this is only the one server. i have duplicate the login information's to "default" and now without errors, but its no synchronizing (i cant see the Users of the another Database)

Hm, looks quite fine to me.
Is this the only domain you serve ownCloud on? If yes, what happens if you duplicate your settings for domain "default"?

Hi Andreas, yes i click on "Save" after Verify Settings :)

It seems that either saving or loading of the settings fails (you did click on "Save", right?).
Could you give some more info, please:

i have now noticed that the users got copied from the external sql database to the oc_users table (probably by some broken owncloud upgrade in the past). the principal admin acount never was on user_sql and could always log in. with this admin account in "users" i activated "show user backend" — all relevant accounts had "database" written there, instead of SQL.

Thanks for the logs. Could you try clearing your browser cache and cookies and logging in again? Did you check from a different computer?

i'm not running any extra authentication plugins. the i'm using postgresql as the database backend.

That's strange, I'm running on NextCloud 9 for quite some time now (actually, since its release).
I tested it on ownCloud 9.1 just yesterday and I did not notice any problems.

OK, I found the problem: It's the PHP7 update and an incompatibility with the version of Sabre/DAV I'm using for davcal. See the problem for ownCloud, I applied their patch: https://github.com/owncloudarchive/calendar/issues/1002

I'm currently testing a few things, it seems that OutlookCalDavSynchronizer requests only events within a certain time span. davcal does not report any events back, so it looks like a problem somewhere within davcal.

Your link is correct.

Did you use this one: https://sourceforge.net/projects/outlookcaldavsynchronizer/?

It seems that the previous commit accidentally broke the creation of new events by not defining a necessary variable in the client side JavaScript.

Problem fixed !

Sorry, something went wrong during branch merge (one function in helper.php appeared twice) and I didn't test it thoroughly enough. Should be fixed now.

Hm, I don't think this can be achieved easily. All rendering is done using jorgchart, I just created a wrapper for DokuWiki.

field column in a database - user and secret. but i don't know what kind of encrypt used.

You need to know the name of the table as well as the columns that vBulletin uses to store its information. Unfortunately, vBulletin is not Open Source, thus I am not able to help you here.

In T26#360, @andreas wrote:

Thanks for the report. Both are warnings, not errors.
I just fixed the Doku_Event_Handler in b80ed4c2e184.

I cannot reproduce the second warning regarding the header information, but you are using a different template. Could you try switching the template to the Dokuwiki default and check if the message still appears?

Thanks for the report. Both are warnings, not errors.
I just fixed the Doku_Event_Handler in b80ed4c2e184.