(I edited your post to remove the plain text email address that was in there)

Do you have any plugins installed? What versions of ruby and sqlite are you using? Could you paste the output of RAILS_ENV=production script/about here, it should contain all this information.

Here is the output:

About your application's environment
Ruby version 1.8.7 (i686-linux)
RubyGems version 1.7.2
Rack version 1.1.3
Rails version 2.3.14
Active Record version 2.3.14
Active Resource version 2.3.14
Action Mailer version 2.3.14
Active Support version 2.3.14
Application root /var/www/chiliproject3
Environment production
Database adapter sqlite3
Database schema version 20111125191432

About your Redmine plugins
Mylyn Connector plugin 2.7.5.stable

Mmh, that looks all good. I also just tried locally on a pristine database and I had no problem creating a user.

Could you see what version of sqlite you have installed (sqlite3 -version) and see what version of the sqlite3-ruby gem you are using (look for it in bundle show)?

I also had a look at the changelog from 3.0 to 3.1 and can't see anything sqlite-related, so I'm a little at a loss here. I assume you ran the database migrations (rake db:migrate) and bundle installation (bundle install) procedures after the update?

Thanks,

sqlite3 version 3.7.7 2011-06-23 19:49:22 4374b7e83ea0a3fbc3691f9c0c936272862f32f2

Gems included by the bundle:
  * actionmailer (2.3.14)
  * actionpack (2.3.14)
  * activerecord (2.3.14)
  * activeresource (2.3.14)
  * activesupport (2.3.14)
  * acts-as-taggable-on (2.1.0)
  * bundler (1.0.21)
  * capybara (1.1.2)
  * childprocess (0.3.0)
  * coderay (1.0.5)
  * edavis10-object_daddy (0.4.3)
  * fastercsv (1.5.4)
  * ffi (1.0.11)
  * i18n (0.4.2)
  * json (1.6.5)
  * liquid (2.3.0)
  * metaclass (0.0.1)
  * mime-types (1.17.2)
  * mocha (0.10.3)
  * multi_json (1.0.4)
  * net-ldap (0.2.2)
  * nokogiri (1.5.0)
  * rack (1.1.3)
  * rack-test (0.6.1)
  * rails (2.3.14)
  * rake (0.9.2.2)
  * rdoc (3.12)
  * rmagick (2.13.1)
  * ruby-openid (2.1.8)
  * rubytree (0.5.3)
  * rubyzip (0.9.5)
  * selenium-webdriver (2.17.0)
  * shoulda (2.10.3)
  * sqlite3-ruby (1.2.5)
  * tzinfo (0.3.33)
  * xpath (0.1.4)

and yes the database migration and bundle installation were done as sugested at https://www.chiliproject.org/projects/chiliproject/wiki/Upgrade

Could it be problems with read or excecution rights? The update was performed as root while the executing user is called chiliproject.

I have sqlite 3.7.13, but that shouldn't be a problem, the rest all looks good.

Jan Hülß wrote:

Could it be problems with read or excecution rights? The update was performed as root while the executing user is called chiliproject.

It shouldn't except if the user running chiliproject can't write to the db file anymore, but that should already show at other places.

Honestly I'm out of ideas other than that you should check if the update really went through for you, to check on the latest version of ChiliProject and to check with a clean install if the problem is with your current db or somewhere in your setup.

Thanks,

Is there a way to check whether the update was completed?
The db seems to be fine. I had a look at it with SQlite Manager for Firefox. No obvius problems.

Again, thanks for your help

Jan Hülß wrote:

Is there a way to check whether the update was completed?

You could check if the newest date in the table schema_migrations (I think) matches the newest date in the names of the files in db/migrate, if you want to be super-thourogh you can check if all dates are in there (theoretically the numbers don't need to be dates nor ordered, just unique, so as unlikely as that is there is a slight chance of having the latest migration applied but not one with a "smaller" date). In any case you can just re-run RAILS_ENV=production rake db:migrate to make sure everything was applied as the migration task checks the numbers in the above table against the files in db/migrate and will just do nothing if there's no file there it doesn't think was already applied.

The db seems to be fine. I had a look at it with SQlite Manager for Firefox. No obvius problems.

Well, judging from your error the only thing that I see in the around code that could explain a false not being cast to a string is the admin flag, but that should be a boolean and not a string. The users table of my newly-created sqlite DB looks like that, is there a difference to yours?

sqlite> .schema users
CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "login" varchar(255) DEFAULT '' NOT NULL, "hashed_password" varchar(40) DEFAULT '' NOT NULL, "firstname" varchar(255) DEFAULT '' NOT NULL, "lastname" varchar(255) DEFAULT '' NOT NULL, "mail" varchar(255) DEFAULT '' NOT NULL, "admin" boolean DEFAULT 'f' NOT NULL, "status" integer DEFAULT 1 NOT NULL, "last_login_on" datetime, "language" varchar(5) DEFAULT '', "auth_source_id" integer, "created_on" datetime, "updated_on" datetime, "type" varchar(255), "identity_url" varchar(255), "mail_notification" varchar(255) DEFAULT '' NOT NULL, "salt" varchar(64));
CREATE INDEX "index_users_on_auth_source_id" ON "users" ("auth_source_id");
CREATE INDEX "index_users_on_id_and_type" ON "users" ("id", "type");
CREATE INDEX "index_users_on_type" ON "users" ("type");

I found some difference between the schema_migrations and the content of the db/migrate folder
Rerunning db:migrate does not help, the problem remained the same
Now, schema_migrations and db/migrate folder fit each other.

With no other options left, I made a clean install of version 3.3.0
Everything is fine now!

Thanks for the fast and helpful support

Jan Hülß wrote:

I found some difference between the schema_migrations and the content of the db/migrate folder
Rerunning db:migrate does not help, the problem remained the same

That's very very odd :-(

Now, schema_migrations and db/migrate folder fit each other.

I hope you didn't just add the missing numbers to the table ^_^"

With no other options left, I made a clean install of version 3.3.0
Everything is fine now!

Thanks for the fast and helpful support

Good to hear, you're welcome.

Hi,

once more. Acctually, further use showed, that not everything is fine.

Creating a new user from within ChiliProject is works now, with and without LDAP authentication.
But the on-the-fly user creation for LDAP still fails with the message from my first post.

Any idea?

I can't really see what's going awry there, sorry. Could you try updating to the current stable version, it has a newer version of the ldap version.

Otherwise, we'll have to go through it with the console.

I installed version 3.3.0 via git clone -b stable git://github.com/chiliproject/chiliproject.git
Guess this is the lates stable:

commit 080c5b63ca5acf8de231e63f4ec7fb0a0f032a3a
Merge: 22204d5 19dd488
Author: Holger Just <hjust@meine-er.de>
Date:   Sun Jul 15 20:26:01 2012 +0200

    Merge branch 'release-v3.3.0' into stable

If it is the lates stable, I'm using it already and the problem is still there.

That is the latest stable. You can also check that the correct ldap lib was installed by checking that net-ldap in the output of bundle show is version 0.3.1 or above.

Anyway, let's go down the console path then. I don't know how familiar you are with Ruby and/or Rails so I'll try to take it a step at a time, if you feel it's too fast or too slow do tell me. Rails basically has a console that lets you access a Ruby prompt with the ChiliProject environment (objects, database connection, SMTP config and so on) loaded. The command to access that is script/console. We don't want to mess stuff up or make lasting changes to the DB, so we add the -s (for sandbox) option which will basically wrap that console session in a transaction so that it can roll back any changes we might have done when you exit (bear in mind though: I'm not sure how transactions work for sqlite but based on what I know from its internals the transaction might place a blocking lock on the DB, so you should rather do anything in the console while no one else wants to work with you ChiliProject). Finally we want to work on the production DB (the one your LDAP connection is configured in) so we add production at the end. The end result:

script/console -s production

That should get you a >> prompt.

Next, please tell me the output of Setting.default_notification_option (just a hunch I had while looking at the user class).

And lastly, please try AuthSource.authenticate("joe", "example123").inspect replacing the first parameter with a username and the last parameter by the corresponding password. For completeness, please try it with (if present) an LDAP user that already has a ChiliProject account, an LDAP user without a ChiliProject account and credentials that correspond to no ChiliProject or LDAP user. No worries, at this point it won't create a user or anything, it will just print the info it's getting from the LDAP.

Thanks, for the detailed description. I'm not familiar with Ruby and Rails. The step by step description is just perfect.

The result of bundle show is:

Gems included by the bundle:
  * actionmailer (2.3.14)
  * actionpack (2.3.14)
  * activerecord (2.3.14)
  * activeresource (2.3.14)
  * activesupport (2.3.14)
  * acts-as-taggable-on (2.1.0)
  * bundler (1.0.21)
  * coderay (1.0.7)
  * fastercsv (1.5.5)
  * gravatarify (3.0.0)
  * i18n (0.4.2)
  * json (1.7.3)
  * liquid (2.3.0)
  * net-ldap (0.3.1)
  * rack (1.1.3)
  * rails (2.3.14)
  * rake (0.9.2.2)
  * rdoc (3.12)
  * ruby-openid (2.1.8)
  * rubytree (0.5.3)
  * sqlite3-ruby (1.2.5)
  * tzinfo (0.3.33)

Thus, the net-ldap version is fine.

The result of Setting.default_notification_option is "only_my_events"

I tested AuthSource.authenticate("joe", "example123").inspect five times:

==== Existing LDAP user, already inside ChiliProject using the correct password
>> AuthSource.authenticate("existingLDAP", "correctPWD").inspect
=> "{:lastname=>\"Hülß\", :auth_source_id=>1, :mail=>\"xxx@xxx.xx\", :firstname=>\"Jan-Patrick\"}" 

==== Existing LDAP user, already inside ChiliProject using a wrong password
>> AuthSource.authenticate("existingLDAP", "wrongPWD").inspect
=> "nil" 

==== Not existing user, no LDAP, not in ChiliProject
>> AuthSource.authenticate("unknownUSER", "testpwd").inspect
=> "nil" 

==== Existing LDAP user, without ChiliProject user using the correct password
>> AuthSource.authenticate("notExistingLDAP", "correctPWD").inspect
=> "{:lastname=>\"TestTest\", :auth_source_id=>1, :mail=>nil, :firstname=>\"Test\"}" 

==== Existing LDAP user, without ChiliProject user using a wrong password
>> AuthSource.authenticate("notExistingLDAP", "wrongPWD").inspect
=> "nil" 

The only difference I see here is that the mail filed is "nil" for the LDAP user not yet in the ChiliProject. Guess this could cause the error message.

I crosschecked the LDAP settings. The Email atribute is set, to the correct value "mail". The same setting work with other tools relying on the LDAP authentification.

Mmh, can the mail attribute be read from LDAP by the LDAP user ChiliProject is accessing the LDAP server as? IIRC everything LDAP is done via the ChiliProject LDAP user, ChiliProject doesn't drop privileges to the "user's" LDAP user.

Ok, I checked all the LDAP stuff on permissions, users, fields, etc.

The final solution are missing mail adresses for the newer LDAP users.
By coincidence the mail adresses are missing only for the LDAP users created after the update of the ChiliProject to version 3.1.0.

Thus, the bug was on my sinde and not in the ChiliProject.

Anyway, a more conclusive error message at leased in the log-file would be nice.

Once more, many thanks for the realy helpful support!!!

To be honest, I would have thought that ChiliProject would try to gather what it can from LDAP and prompt the user for information it didn't get from there. Could you please open a bug nonetheless? I'd like to investigate if this is sqlite-specific or if the behavior I just described really is missing.

Cerated bug: https://www.chiliproject.org/issues/1106

Closing this thread as there's an increasing number of spam happening here.