A user with "admin" role should be able to manage users

[cbleek]

If you login to the demo, you'll get a list of users http://yawik.org/demo/de/user/list

The List is generated via the UserController

https://github.com/cross-solution/YAWIK/blob/develop/module/Auth/src/Auth/Controller/UsersController.php

The following Features are missing and should be implemented.

1) detail views of a user. Users Details should be editable by the admin.

2) User account should be able to deactivate.

Details follow.

[cbleek]

The list of Users should have an additional column with links to edit the Users Data. They can be simply added to the view

https://github.com/cross-solution/YAWIK/blob/develop/module/Auth/view/auth/users/list.ajax.phtml

The detail view of a User should look like .

It should be possible to reuse the Code for the Formular

https://github.com/cross-solution/YAWIK/blob/develop/module/Auth/src/Auth/Form/UserInfoContainer.php

In addition the admin should be able to deactivate a User. This means, we have to add an additional attribute to the user entity.

 /**
     * Status of the user
     *
     * @var Status
     * @ODM\EmbedOne(targetDocument="Status")
     * @ODM\Index
     */
    protected $status;

The status entity should look like our status entities for job and applications, but with the following states:

protected static $orderMap = array(
        self::ACTIVE => 50,
        self::INACTIVE => 60,
      );

https://github.com/cross-solution/YAWIK/blob/develop/module/Jobs/src/Jobs/Entity/Status.php

The findByLogin, findByProfileIdentifier, findByEmail and findByLoginOrEmail functions have to check for the Users status 'ACTIVE'.

To make it backward compatible we have to update all users and set status to "ACTIVE" where status does not exists.

https://github.com/cross-solution/YAWIK/blob/develop/module/Auth/src/Auth/Repository/User.php

On the detail page of a User an additional form container should allow the admin to change the status of a user.

@TiSiE , can you review please?

[TiSiE]

@fedys

We discussed yesterday about your feedback and came to the following conclusion about the handling of deactivated users:

• The user repository will throw an exception (You already implemented a UserDeactivatedException) if find() or findOneBy() would return a deactivated user UNLESS a flag is provided, which explicitly allow such an entity to be returned.
• The user repository will skip deactivated user entities on findBy(), unless the query provided explicitly sets the status field to be queried against. (analogically to the handling of drafts)
• A listener (analogically to the UnauthorizedAccessListener will catch any UserDeactivatedExcpetion and sets an dedicated error template for that case. (With meaningful message such as "This user account has been disabled. Please contact the system adminstrator...")
• The UserDeactivatedException should be moved to the \Auth\Exception namespace. (and following ZF practice implement the \Auth\Excpetion\ExceptionInterface)

By taking this approach we still allow code to handle deactivated users (by catching exceptions or explicitly query for) but at the same time have one central point (the Listener) to handle all other cases.

[fedys]

@TiSiE ok, this sounds good. I am going to implement it.

[cbleek]

this was completed by @fedys in https://github.com/cross-solution/YAWIK/commit/77b219c722cd3cf5cbb56cce557c281b86bac94f