Should the default admin be seen via the user management page?

[dodo920306]

Expected Behavior

I'm here to figure out what is truly wanted.

Current Behavior

Currently we have a filter for this in src/api-engine/api/routes/user/views.py

            users = UserProfile.objects.filter(**query_params).exclude(
                username=ADMIN_USERNAME
            )

However, this only applies if the env ADMIN_USERNAME while the current default admin is created via API_ENGINE_ADMIN_USERNAME

  python manage.py create_user \
    --username ${API_ENGINE_ADMIN_USERNAME:-admin} \
    --password ${API_ENGINE_ADMIN_PASSWORD:-pass} \
    --email ${API_ENGINE_ADMIN_EMAIL:[email protected]} \
    --is_superuser \
    --role admin

Therefore, unless ADMIN_USERNAME is set to the same as API_ENGINE_ADMIN_USERNAME, the users will always see an admin in the user management page. Is this intentional? Moreover, they may naturally want to login the admin via the username shown before they realize that users can only login via email.

Possible Solution

Thus, I suggest either synchornize the email of the default admin with the username of it or unify ADMIN_USERNAME with API_ENGINE_ADMIN_USERNAME to prevent this confusing behavior.

Steps to Reproduce

1. Set up a Cello instance without ADMIN_USERNAME.
2. Enter the user management page
3. See the default admin

Context (Environment)

• OS: Ubuntu 25.04
• Architecture: amd64
• Docker version: 28.2.2
• Docker compose version: 2.36.2

Detailed Description and log

Possible Implementation

[yeasy]

I think it is only for the default admin user. So we can use ADMIN_USERNAME (instead of API_ENGINE_ADMIN_USERNAME) to create the default admin user.

[dodo920306]

So should it be included in the user management page?

[yeasy]

So should it be included in the user management page?

It's OK to include the default user.

[dodo920306]

So should it be included in the user management page?

It's OK to include the default user.

But it's weird, nobody can actually login by the username shown because it's not an email (unless one finds the true email of the user by configurations), and it doesn't belong to any organization which makes every operation it does fails.

[dodo920306]

So should it be included in the user management page?

It's OK to include the default user.

And if so, shouldn't we remove the lines of code that intentionally wants to ignore the default user form the list but usually fails to do so because of the wrong env name?

...
    def list(self, request, *args, **kwargs):
        """
        List Users

        List user through query parameter
        """
...
            users = UserProfile.objects.filter(**query_params).exclude(
                username=ADMIN_USERNAME
            )
...

Or maybe we can replace all API_ENGINE_ADMIN_USERNAME with ADMIN_USERNAME?

[yeasy]

It's Ok to remove the code lines.

[dodo920306]

It's Ok to remove the code lines.

What about the un-login-able problem? Currently we have

...
  python manage.py create_user \
    --username ${API_ENGINE_ADMIN_USERNAME:-admin} \
    --password ${API_ENGINE_ADMIN_PASSWORD:-pass} \
    --email ${API_ENGINE_ADMIN_EMAIL:[email protected]} \
    --is_superuser \
    --role admin
...

in our container entrypoints. Maybe we can replace all API_ENGINE_ADMIN_USERNAME, API_ENGINE_ADMIN_EMAIL, and ADMIN_USERNAME occurrences with ADMIN_EMAIL?

[yeasy]

It's Ok to remove the code lines.

What about the un-login-able problem? Currently we have

... python manage.py create_user
--username ${API_ENGINE_ADMIN_USERNAME:-admin}
--password ${API_ENGINE_ADMIN_PASSWORD:-pass}
--email ${API_ENGINE_ADMIN_EMAIL:[email protected]}
--is_superuser
--role admin ... in our container entrypoints. Maybe we can replace all API_ENGINE_ADMIN_USERNAME, API_ENGINE_ADMIN_EMAIL, and ADMIN_USERNAME occurrences with ADMIN_EMAIL?

I'm fine. @YoungHypo thoughts?

[YoungHypo]

It's Ok to remove the code lines.

What about the un-login-able problem? Currently we have ... python manage.py create_user --username ${API_ENGINE_ADMIN_USERNAME:-admin} --password ${API_ENGINE_ADMIN_PASSWORD:-pass} --email ${API_ENGINE_ADMIN_EMAIL:[email protected]} --is_superuser --role admin ... in our container entrypoints. Maybe we can replace all API_ENGINE_ADMIN_USERNAME, API_ENGINE_ADMIN_EMAIL, and ADMIN_USERNAME occurrences with ADMIN_EMAIL?

I'm fine. @YoungHypo thoughts?

That is good to me, too.

[dodo920306]

What about the un-login-able problem? Currently we have ... python manage.py create_user --username ${API_ENGINE_ADMIN_USERNAME:-admin} --password ${API_ENGINE_ADMIN_PASSWORD:-pass} --email ${API_ENGINE_ADMIN_EMAIL:[email protected]} --is_superuser --role admin ... in our container entrypoints. Maybe we can replace all API_ENGINE_ADMIN_USERNAME, API_ENGINE_ADMIN_EMAIL, and ADMIN_USERNAME occurrences with ADMIN_EMAIL?

I'm fine. @YoungHypo thoughts?

That is good to me, too.

If so, I may work on a PR to fix this issue by this conclusion a few days later. I want to make sure that, should this default user be able to see all the nodes, networks, and channels or it shall see none? Currently this user can't see anything because every page it accesses responses errors because this user has no organization. If it shall see none for organizational privacy, I may implement a method to silent these annoying errors and give it an empty list for everything. Otherwise, I should make these APIs return all the modals they got when the requesting user has no organization (which is impossible for normal users registered later). @yeasy @YoungHypo

[yeasy]

What about the un-login-able problem? Currently we have ... python manage.py create_user --username ${API_ENGINE_ADMIN_USERNAME:-admin} --password ${API_ENGINE_ADMIN_PASSWORD:-pass} --email ${API_ENGINE_ADMIN_EMAIL:[email protected]} --is_superuser --role admin ... in our container entrypoints. Maybe we can replace all API_ENGINE_ADMIN_USERNAME, API_ENGINE_ADMIN_EMAIL, and ADMIN_USERNAME occurrences with ADMIN_EMAIL?

I'm fine. @YoungHypo thoughts?

That is good to me, too.

If so, I may work on a PR to fix this issue by this conclusion a few days later. I want to make sure that, should this default user be able to see all the nodes, networks, and channels or it shall see none? Currently this user can't see anything because every page it accesses responses errors because this user has no organization. If it shall see none for organizational privacy, I may implement a method to silent these annoying errors and give it an empty list for everything. Otherwise, I should make these APIs return all the modals they got when the requesting user has no organization (which is impossible for normal users registered later). @yeasy @YoungHypo

LGTM!

[dodo920306]

If so, I may work on a PR to fix this issue by this conclusion a few days later. I want to make sure that, should this default user be able to see all the nodes, networks, and channels or it shall see none? Currently this user can't see anything because every page it accesses responses errors because this user has no organization. If it shall see none for organizational privacy, I may implement a method to silent these annoying errors and give it an empty list for everything. Otherwise, I should make these APIs return all the modals they got when the requesting user has no organization (which is impossible for normal users registered later). @yeasy @YoungHypo

LGTM!

That doesn't answer my question...

[yeasy]

If so, I may work on a PR to fix this issue by this conclusion a few days later. I want to make sure that, should this default user be able to see all the nodes, networks, and channels or it shall see none? Currently this user can't see anything because every page it accesses responses errors because this user has no organization. If it shall see none for organizational privacy, I may implement a method to silent these annoying errors and give it an empty list for everything. Otherwise, I should make these APIs return all the modals they got when the requesting user has no organization (which is impossible for normal users registered later). @yeasy @YoungHypo

LGTM!

That doesn't answer my question...

silent these annoying errors and give it an empty list for everything.

[dodo920306]

silent these annoying errors and give it an empty list for everything.

OK! Thanks for the clarification.