Add user and better structure to session json

[nagmat84]

This PR fixes some TODO which I left behind in the source during my many refactorings.

It adds the complete user object to the JSON returned by SessionController::init (not only some selected attributes). It gives more structure to the booleans for the various rights we have and removes the unfortunate login attribute.

This PR should be merged before @qwerty287's #1368, because #1368 needs the user object.

[codecov]

Codecov Report

Merging #1443 (4ffcc01) into master (3ec71f1) will decrease coverage by 0.74%.
The diff coverage is 79.31%.

[ildyria]

Wouldn't we want this to be a proper DTO directly ?

[nagmat84]

Wouldn't we want this to be a proper DTO directly ?

In theory yes. But I already left that one out on purpose when I introduced the DTOs. The structure of this JSON is completely wry. Some attributes are always there, some attributes are nullable other ones might be even be left out completely, etc. Converting this into a DTO would be much more work than this PR. Moreover, a lot of the things there (like the case of the non-existing admin) will be gone hopefully soon. Hence, I do not feel like doing it now.

[ildyria]

Untested, LGTM.
I guess the DTO will wait a proper refactoring on that part (I read your mind :D).

[nagmat84]

Untested, LGTM. I guess the DTO will wait a proper refactoring on that part (I read your mind :D).

Exactly. This is only a quick fix, so that we can go on with @qwerty287's #1368.

[ildyria]

I reviewed the front end, feel free to merge. :)

[nagmat84]

The question is whether we should wait until #1403.

[ildyria]

The question is whether we should wait until #1403.

#1403 only waits for you, if I am not wrong. 😄

[ildyria]

Needs Lychee-Front modification.
Suggested v4.6.1

[nagmat84]

After #1403 has been merged into the backend, this PR needed to adopt. So I think it should be re-reviewed. The following aspects have been changed (also see LycheeOrg/Lychee-front#310):

1. SettingsController::setLogin returns the updated user object to the frontent
2. SettingsController::updateLogin returns the updated user object to the frontent
3. Adding/resetting the admin user ensures that mayUpload is set to true and not to the implicit default false

This has been necessary, because #1403 now updates the session of the backend after a user has been changed, and I want to keep the frontend synced.

Technically, the first two points are not necessary now, because there is currently no code which relies on condition that the backend and frontend user are the same, but I want to avoid future surprises.

The third point three has actually been a lurking, old bug which I just noticed when I reviewed the JS code of the frontend in the step debugger. It has no effect, because any permission checking is by-passed for the admin anyway, but I wanted to have it cleaned up.

[ildyria]

LGTM.

I was looking at the return on Session::init():

rights: {is_admin: true, is_locked: false, may_upload: true}
user: {id: 0, username: "admin", email: "test@test.com", may_upload: true, is_locked: false}

I am wondering if we want this duplication of rights, or if we just don't care in this specific case. :)

I would say that the serialization in toArray() is needed because of the user administration page.

[nagmat84]

LGTM. [...]

I am wondering if we want this duplication of rights, or if we just don't care in this specific case. :)

Because they only happen to use the same names for attributes (which is unfortunate), but they are not semantically identical.

I will start another issue about that, because I have been thinking about renaming some of the attributes a long time to make the difference more obvious. It is this unfortunate re-use of names and overloading of meaning which has frequently caused troubles when it has come to permission and accidental leakage of photos.

[qwerty287]

Tested, seems working.