Added implementation progress and some test scenarios for issue 252

notes/study_for_issue_252.md

@@ -56,5 +56,24 @@ Application boundaries:
 To implement the case "insensitive comparison", all the retrieval points should be modified to get the user by login in a case insensitive way (this should be all the code places listed in paragraph [User retrieval](#user-retrieval), it can also be seen by looking at all the calls to `User.query.filter`).
 Look all `User.query.filter`, transform `User.user ==` into `User.user.ilike`). Should also group calls to `User.query.filter` in `app.datamgmt.manage.manage_users_db`.
 
+Implementation tasks perform:
+* in `app.datamgmt.manage.manage_users_db` split method `get_user(user_id, key)` in to `get_user and get_user_by_mail(user_email)`
+* grouped most calls to `User.query.filter*` into `app.datamgmt.manage.manage_users_db`
+
+Implementation questions:
+* ask why the `User.query.filter` with_entites [here](https://github.com/dfir-iris/iris-web/blob/v2.3.2/source/app/blueprints/case/case_timeline_routes.py#L752) couldn't simply be replaced by a call to `get_user` followed by an access to field `name` of the result.
+
 # Test scenarios
 
+## Log in with different case
+* create a user with `Toto` as login
+* login with `toto` should work
+
+## Do not create two users with same login by different cases
+* create a user with `Toto` as login
+* creation of a user with `toto` as login should not work
+
+## REST API to retrieve user by login
+* create a user with `Toto` as login
+* querying `GET` on `/manage/users/lookup/login/toto` should return the user's information
+