ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

OpenID : Proposal -- Features, Use-Cases, & Screen Flow -- for Better Intuition & Guidance (Feature #985)

Added by Christopher Mann at 2012-04-13 10:47 am. Updated at 2012-04-13 11:27 am.

Status:Open Start date:
Priority:High Due date:
Assignee:- % Done:


Category:User accounts
Target version:- Estimated time:22.00 hours
Remote issue URL: Affected version:



Here are a few suggestions below that may be implemented one-by-one. My base observation is with the redmine-openid-selector installed. The proposed suggestions below come from short-comings in the coherence of the concurrent OpenID and user/login system; a concurrence necessary to maintain. but intelligently (example: the lay user should not have a moment's doubt about the password given as the Chili one or the OpenID one).


There are two scenarios:

  1. Sign in by Login / Password (SLP)
  2. Sign in by OpenID (SOID)

There is also the necessary eventuality of registration:

  1. Registration by Login / Password (RLP)
  2. Registration by OpenID (ROID) that could have the same initial screen as SOID

Proposition of Features & Ergonomics

Modified Ergonomic /login Screen that Guides

Unique /login screen proposes the following (perhaps by DIVs of which only one is visible at any time):

  • Login / Password
  • OpenID

On choosing, one of the 2 Forms is present


Offer a third choice "Both Chili Login / Password, and OpenID."

Choice of Login / Password

On the screen is shown:

  • perhaps on the left, just a login and a password window (no open ID)
  • perhaps on the right, just a link to the login page (If registration activated)

Choice of OpenID

On the screen is shown the OpenID Selector, but nothing else.

Variant on Choice of OpenID

A link can render visible a field for the login.
A link can render visible a field for the email.

If the login or the email (priority to email) are entered, then this OpenID may be associated to this existing account. Password or email verification only on successful OpenID passage. If account does not exist by email or by login, then login and/or email are pre-populated in /account/registration if registration is activated.

Variant Choice of Both Chili Login / Password, and OpenID

The current screen stands, but if the login / password are correct, the the OpenID URL is reinitialized.

Continuation of Variant

Should the email be taken, a registration screen only asks for the password associated with the username of that email to reinitialize the URL. Now the person may not, in that case, remember his or her password. The "email already used" screen should send an email allowing the continuation of the modification of the link (or at least proposition of existing password reminder).

Special Case

Multiple OpenIDs
Change of OpenID


  1. User with correct OpenID URL logs in.
  2. User with correct Login / Password logs in.
  3. User with new OpenID URL logs in and is sent to register screen without existing account.
  4. User with new OpenID URL logs in and is sent to register screen with existing account (variant: email taken from OpenID).


Updated by Christopher Mann at 2012-04-13 10:50 am

Afterthought: Abstract OpenID to allow room for Facebook login.

Updated by Christopher Mann at 2012-04-13 11:26 am

These ergonomics look easier to implement as a first stage:
Based on OSQA

Also available in: Atom PDF