Project owner become empty, unable to add new memebers

Troubleshooting
,
1

Hello,

Someone in our team changed the owner of a project and the project ended up being orphaned without an owner. The project membership indicates that new ownership has been established, but the owner field on the projects page remains empty for the affected project. (See attached screenshot)

proj-no-owner1a
proj-no-owner1a1385×759 64.5 KB

proj-no-owner2a
proj-no-owner2a1442×204 10.2 KB

Also, we haven’t been able to add any new members to the project ever since the project become orphaned.

Can you suggest a way to resolve the issue? We need a way to fix up the project ownership and restore the ability to add new members to the project.

We’re running Tiga version 6.6.0

Thanks!

Simon

1 Like
2

Hi there, Simon,

If you click on that project, can you confirm that, in the privacy section, the owner is set?

image
image1570×115 3.48 KB

Right where the anonymized section is there should be a drop-down allowing you to choose another member of the project to be the owner. Make sure that user has admin status.

Regards!

3

Hi Charlie,

I went into the privacy section under the project detail and noticed that the owner field is empty:

null-owner-1
null-owner-11107×563 17.3 KB

Then I selected “Alex” from the drop down list. I’ve already confirmed that Alex is in fact a product owner, and “Is Admin” is set to true.

null-owner-2
null-owner-21069×559 17 KB

null-owner-3
null-owner-31092×207 8.83 KB

Then I click the save button at the bottom of the project detail screen, and received a 400 Bad Request error on the “admin/projects/project/8/change/” page
null-owner-4

And when I go back to the project list, the project owner is still empty

null-owner-5
null-owner-5811×57 1.54 KB

Can you please advise? Thanks!

Simon

4

Thanks for the screenshots!

Could you also provide the logs from the backend?

Regards!

5

Hi Charlie,

Here are the logs extracted:

docker logs --follow taiga-docker-taiga-gateway-1

2024/04/23 03:04:29 [warn] 22#22: *2472 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000022, client: {…}, server: , request: “POST /admin/projects/project/8/change/ HTTP/1.1”, host: “{…}”, referrer: “https://{…}/admin/projects/project/8/change/”
{…} - - [23/Apr/2024:03:04:30 +0000] “POST /admin/projects/project/8/change/ HTTP/1.1” 400 143 “https://{…}/admin/projects/project/8/change/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36” “{…}”
{…} - - [23/Apr/2024:03:04:30 +0000] “GET /favicon.ico HTTP/1.1” 200 140629 “https://{…}/admin/projects/project/8/change/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36” “{…}”

No info related to the error on the taiga-back log:

docker logs --follow taiga-docker-taiga-back-1

Executing pending migrations
Operations to perform:
Apply all migrations: admin, attachments, auth, bitbucket, contact, contenttypes, custom_attributes, djmail, easy_thumbnails, epics, external_apps, feedback, github, gitlab, gogs, history, issues, likes, milestones, notifications, projects, references, sessions, settings, tasks, telemetry, timeline, token_denylist, users, userstorage, userstories, votes, webhooks, wiki
Running migrations:
No migrations to apply.
[2024-04-23 02:50:55 +0000] [1] [INFO] Starting gunicorn 20.1.0
[2024-04-23 02:50:55 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2024-04-23 02:50:55 +0000] [1] [INFO] Using worker: sync
[2024-04-23 02:50:55 +0000] [32] [INFO] Booting worker with pid: 32
[2024-04-23 02:50:55 +0000] [33] [INFO] Booting worker with pid: 33
[2024-04-23 02:50:55 +0000] [34] [INFO] Booting worker with pid: 34

docker logs --follow taiga-docker-taiga-async-1

[2024-04-23 03:30:54,671: INFO/MainProcess] Task taiga.projects.notifications.tasks.send_bulk_email[aee2836e-6ba1-465b-bb9c-6fb95c974323] received
[2024-04-23 03:32:14,547: INFO/MainProcess] Task taiga.timeline.service.push_to_timelines[ad3a414f-9866-4f95-a5a7-dec890d22bf6] received
[2024-04-23 03:32:54,668: INFO/Beat] Scheduler: Sending due task send-bulk-emails (taiga.projects.notifications.tasks.send_bulk_email)
[2024-04-23 03:32:54,670: INFO/MainProcess] Task taiga.projects.notifications.tasks.send_bulk_email[9733ae09-68b5-4b5b-862c-911332317a3c] received

By the way, I notice the logs is flooded with entry similar to this. Not sure if this is related to the 400 error we’re seeing here.

2024/04/23 03:04:32 [error] 22#22: *2526 connect() failed (113: Host is unreachable) while connecting to upstream, client: {…}, server: , request: “GET //events HTTP/1.1”, upstream: “http://{…}:8888/events”, host: “{…}”

Thanks!

6

Hi, Simon!

Could you share your nginx, or whichever proxy you are using, configuration for Taiga?

Also, any console errors on the browser when the error happens.

If you could enable DEBUG=True on the settings temporarily and show us the extra error info you get when triggering the error, it would be great (make sure to disable it afterward).

Regards!

7

Hi Charlie,

The only console error I received on the browser is the Bad Request (400) message from the “admin/project/{proj_id}/change” endpoint.

I started Taiga with docker-compose. Will I be able to set DEBUG = True in the docker-compose.yml? Can you suggest where to set it?

Thanks!

Simon

8

Hi again!

You should be able to set it in the x-environment. Add an entry there like this:

x-environment:
  &default-back-environment
  # rest of the variables here, no need to touch those now
  DEBUG: "True"

Regards!

9

Hi Charlie,

I added the DEBUG entry to the x-environment section as you suggested but the debug logs are not showing up.

For your information … I’ve wrapped the Taiga start / stop commands into a systemd service, and this is how the ExecStart and ExecStop entries looks like in the service file:

ExecStart=/usr/bin/env /usr/bin/docker-compose -f /opt/taiga-docker/docker-compose.yml up -d
ExecStop=/usr/bin/env /usr/bin/docker-compose -f /opt/taiga-docker/docker-compose.yml stop

Would restarting Taiga this way properly load the DEBUG environment variable?

Is there a way to confirm that the DEBUG variable has in fact been correctly set?

Thanks!

Simon

10

Hi there, Simon,

That variable is not for setting DEBUG log level, but for setting DEBUG mode for Django (and it should never be on production, at least for long). What it should do is give you more information when you reach that 400 Bad Request page.

It should look like a yellow and gray page now with more info than before.

Regards!

11

Hi Charlie,

Setting the DEBUG variable like you suggested returns the same barebone Bad Request (400) message that I reported earlier. There’s no yellow and gray debug details page showing up.

Can you suggest how to proceed from here? Thanks!

Simon

12

Facing Same issue for me, please any one help me this issue