RSS or Atom

The aim is to have a general Data Access Object (DAO) for LDAP.

My proposition is to use a CRUD architecture with the same functions for user, group and member group manipulations.

public void create (String type, Hashtable<String, String> ldapEnv, Attributes attributes)
{
}

public Attributes retrieve (String type, Hashtable ldapEnv, String id)
{
}

public void update (String type, Hashtable ldapEnv, String id, String attributeName, String value,)
{
}

public void delete (String type, Hashtable ldapEnv, String id, ArrayList members)
{
}

type would be equal to "user", "group" or "memberGroup" to make the difference between an action on a user, or a group.
Thoses methods are quite general and are taking advantages of the similarities between the different actions to refactor the code.

The differents informations mandatory to add a user, a group or a group member will be grouped in an Attributes object.

For the Delete method, the "ArrayList members" would be "null" for a user or a group since we don't need this to delete them.
(I'm not sure if this is possible in Java, an other solution would be to create 2 methods Delete, one with one more parameters than the other : "ArrayList members")

This structure would change the definition of the object attributes which would have to be done in the LdapUser and LdapGroup classes instead of Ldap.

On registration, the user should be added to the LDAP group corresponding to the community.

Firstnames and/or surnames with diacritics caused an improper "bad signature" exception.

Code fixed by 89d4026.
Test needed.

Alice has the account "alice.dodgson" with the following e-mail: "[email protected]".
Malory has also an account and want to steal Alice's.
He sends an invitation to alice.dodgson but to his own e-mail "[email protected]".

A functional test will have to be created to check if this scenario is prevented.
If not, the code will have to be fixed.

The user must be able to see profiles of other.

... so that they can reset their password from the new invitation.

Key: login
Value: firstname, surname, groups

The user interface should emphasize that, once the user is registered, he (she) should click the link and open the application.

The user must be able to modify and complete his personal data.

The user name is currently notified only once to the user : on the webpage, when he choose his/her password. Unfortunately, many users hit the button without reading the username. They worry about their username so sooner than when requested by our platform.

I suggest that the user name will be notified in the invitation mail so that the user can keep it in the future.

The error messages such a the messages in the app/controllers/inscription.java @required(message="The first password is required") should not be set directly in the source code but should refer to a message in the message.en and message.fr file.

However, the @required annotation only allow the use of constants (It's not possible to call the Message class). An idea could be to handle the error messages directly in the body of the methods, it is less easier than with annotations but would allow the use of multi-languages

The user wants to be able to see which users logged in a specific application and how many times.

... in the member's profile (in LDAP).

Depending on the training session, the homepage of the community is different. Either we create a new community for each training session or we change the homepage on each invitation. The latter need a new feature, but is perhaps easier to manage in the long term.

I have invited all students attending my last class on Hypertopic suite. On month later, people claims not having received any invitation. In fact, mails were considered as junk because mail sender was unidentified.

Perhaps sender address could be replace by sponsor mail or by leader of the community...

Some users with multiple first names or surnames could not login in Mediawiki with accounts created in Dolomite.
Check if this could be due to a bug in Dolomite.

Sometimes, a sponsor need to invite multiple users at once. This is for instance the case while you are giving training sessions.

The invitation form could allow to encode name, surname and email from several persons at once.

... both in the "reply-to" header (Firstname Surname ) and in the content (Firstname Surname).

On the creation or update of an LDAP group, members could change the name and URL of the corresponding community.
It would be stored in the LDAP database rather than in the configuration file.

To invite someone to a community, the user should be a member of the LDAP group corresponding to this community.