Access to TEAM item crashes

[mestia]

Detailed description of the problem

TEAM element crashes after adding an ldap user to multiple teams and groups.

Expected Behavior

not crash

Steps to reproduce the behavior

Steps to reproduce a problem:

eLabFTW instance version 5.0.4 installed as a docker container.

Enabled LDAP:

• TLS yes
• anonymous binding
• user attribute: mail
• attr to look for the team name: empty
• Create team sent by the server if it doesn't exist: disabled
• if no team attr is found: INSTITUTE_USERS
• if the user doesn't exist: Create on the fly
• email attr: mail
• firstname: givenname
• lastname: cn

By default users who login via LDAP are assigned to a "specific group" called for example INSTITUTE_USERS

After adding a new LDAP user to a different Team ( Default Team in this case) and adding this new user to a new group within the Default Team access to TEAM element in sysadmin/admin context is broken.

Removing group with external user solves the problem and TEAM is working again.

Do you have any idea what may have caused this?

No response

Do you have an idea how to solve the issue?

No response

What is your docker-compose configuration?

services:
  web:
    image: elabftw/elabimg:5.0.4
    restart: always
    container_name: elabftw
    cap_drop:
        - SYS_ADMIN
        - AUDIT_WRITE
        - MKNOD
        - SYS_CHROOT
        - SETFCAP
        - NET_RAW
        - SYS_PTRACE
    environment:
        - DB_HOST=mysql
        - DB_PORT=3306
        - DB_NAME=elabftw
        - DB_USER=elabftw
        - SERVER_NAME=testlen.mydomian.com
        - DISABLE_HTTPS=false
        - ENABLE_LETSENCRYPT=true
        - MAX_PHP_MEMORY=512M
        - MAX_UPLOAD_SIZE=200M
        - PHP_TIMEZONE=Europe/Paris
        - TZ=Europe/Paris
        - SET_REAL_IP=false
        - SET_REAL_IP_FROM=192.168.31.48, 192.168.0.42, 10.10.13.37
        - PHP_MAX_CHILDREN=50
        - PHP_MAX_EXECUTION_TIME=250
        - USE_REDIS=false
        - REDIS_HOST=redis
        - REDIS_PORT=6379
        - ENABLE_IPV6=false
        - SITE_URL=https://testlen.mydomian.com
        - LDAP_TLS_REQCERT=never
    ports:
        - '443:443'
    volumes:
        - /elabftw/elabftw/web:/elabftw/uploads
        - /etc/letsencrypt:/ssl
    networks:
      - elabftw-net
  mysql:
    image: mysql:8.0
    restart: always
    container_name: mysql
    cap_drop:
        - AUDIT_WRITE
        - MKNOD
        - SYS_CHROOT
        - SETFCAP
        - NET_RAW
    environment:
        - MYSQL_DATABASE=elabftw
        - MYSQL_USER=elabftw
        - TZ=Europe/Berlin
        - LANG=C.UTF_8
        - command=['mysqld', '--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci']
    volumes:
        - /elabftw/elabftw/mysql:/var/lib/mysql
    ports:
      - '3306:3306'
    networks:
      - elabftw-net
networks:
  elabftw-net:

Output of uname -a

included in docker info

Output of cat /etc/os-release

included in docker info

Output of docker info

docker info
Client: Docker Engine - Community
 Version:    26.1.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.26.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 3
  Running: 2
  Paused: 0
  Stopped: 1
 Images: 25
 Server Version: 26.1.0
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
 Kernel Version: 5.4.0-177-generic
 Operating System: Ubuntu 20.04.6 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.809GiB
 Name: testeln
 ID: STPO:J2OG:ZO7S:VKBW:AZSO:ABRR:SHJS:SJLH:WTE6:PR57:PVDN:KTLG
 Docker Root Dir: /elabftw/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Relevant php error log entry

2024/04/26 10:55:47 [error] 158#158: *248 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught TypeError: Elabftw\Models\TeamGroups::Elabftw\Models\{closure}(): Argument #1 ($userid) must be of type string, null given in /elabftw/src/models/TeamGroups.php:82
Stack trace:
#0 [internal function]: Elabftw\Models\TeamGroups->Elabftw\Models\{closure}()
#1 /elabftw/src/models/TeamGroups.php(89): array_map()
#2 /elabftw/web/admin.php(66): Elabftw\Models\TeamGroups->readAll()
#3 {main}

Next TypeError: Elabftw\Elabftw\TwigFilters::displayMessage(): Argument #1 ($message) must be of type string, null given, called in /elabftw/cache/twig/e8/e879042947e3fd2d62f5808ff9b6b0ab.php on line 53 and defined in /elabftw/src/classes/TwigFilters.php:36
Stack trace:
#0 /elabftw/cache/twig/e8/e879042947e3fd2d62f5808ff9b6b0ab.php(53): Elabftw\Elabftw\TwigFilters::displayMessage()
#1 /elabftw/vendor/twig/twig/src/Template.php(171): __TwigTemplate_b7b5e11ac17b665df6eb40a9b9fbe7f5->block_body()
#2 /elabftw/cache/twig/79/79692facd648ff8eb0e81af6139e3848.php(90): Twig\Template->d" while reading response header from upstream, client: 192.168.194.236, server: testlen.mydomian.com, request: "GET /admin.php?tab=2 HTTP/2.0", upstream: "fastcgi://unix:/run/php-fpm.sock:", host: "testlen.mydomian.com"
2024/04/26 10:55:56 [error] 158#158: *248 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught TypeError: Elabftw\Models\TeamGroups::Elabftw\Models\{closure}(): Argument #1 ($userid) must be of type string, null given in /elabftw/src/models/TeamGroups.php:82
Stack trace:
#0 [internal function]: Elabftw\Models\TeamGroups->Elabftw\Models\{closure}()
#1 /elabftw/src/models/TeamGroups.php(89): array_map()
#2 /elabftw/web/admin.php(66): Elabftw\Models\TeamGroups->readAll()
#3 {main}

### Additional information

_No response_

[NicolasCARPi]

Hello,

Thank you for opening this issue. I tried following your description of the issue to reproduce, but didn't manage. I might be missing something. Could you please try and explain again the following part, making sure to use the correct terminology: Team for Teams created by Sysadmin, and Groups for the team groups created by Admin.

For instance:

By default users who login via LDAP are assigned to a "specific group" called for example INSTITUTE_USERS

Do you mean Team here? When created on the fly, users are added to a Team, not a Group.

After adding a new LDAP user to a different Team ( Default Team in this case) and adding this new user to a new group within the Default Team access to TEAM element in sysadmin/admin context is broken.

Could you please try and dumb it down so I can reproduce it. Make very clear step by step of what user needs to be in which team and which group to trigger the issue.

It seems you have a reproducible error, with a clear error log, so it shouldn't be hard to fix this once I manage to understand and reproduce the issue at play here.

[mestia]

Do you mean Team here? When created on the fly, users are added to a Team, not a Group.

Sorry, yes, I mean a Team not a Group.

I've just tried with an empty eLabFTW instance and couldn't reproduce the problem. I will need some more time to test that.
The affected instance had already data and scheduler. I guess this is an important difference.

[NicolasCARPi]

Yeah, it has to be some sort of difficult to trigger bug, with pre-conditions. But for sure it has to do with Team Groups.