[GH-ISSUE #2193] New DomainAdmin has no rights #1539

New issue

Closed

opened 2026-02-27 11:17:39 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 11:17:39 +03:00

Owner

Originally created by @reesing322 on GitHub (Mar 2, 2021).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/2193

Impacted versions

OS Type: Ubuntu server
OS Version: 20.10
Database Type: PostgreSQL
Database version: latest modoboa installer
Modoboa: latest modoboa installer
installer used: Yes
Webserver: Nginx

Steps to reproduce

log in with server/site admin
create new domain: x.net with domain admin account postmaster@x.net
log out
log in with postmaster@x.net
click domains in top menu
=> you will see the domain x.net, as expected
create account test1@x.net (simple user)
create account test2@x.net (domain admin)
log out
log in with test2@x.net (also domain admin)

issue: click on domains in top menu
expected: you will see the domain x.net
actual: No more domain to show

issue: click on identities in top menu
expected: you will see all identities under x.net, also postmaster@x.net and test1@x.net
actual: Only test2@x.net is shown

issue: click on add-account
try to create test3@x.net (simple user)
expected: this works
actual: after pressing submit: Permission denied

I also tried 'upgrading' a simple user to a domain admin (with the site admin account),
this also results in a domainadmin with no rights.

Then I also tried importing an account as DomainAdmins via
python manage.py modo import account.csv
Again, that account does not have sufficient rights.

To me, this does not like like wanted behavior for a domain admin account?

Originally created by @reesing322 on GitHub (Mar 2, 2021). Original GitHub issue: https://github.com/modoboa/modoboa/issues/2193 # Impacted versions * OS Type: Ubuntu server * OS Version: 20.10 * Database Type: PostgreSQL * Database version: latest modoboa installer * Modoboa: latest modoboa installer * installer used: Yes * Webserver: Nginx # Steps to reproduce log in with server/site admin create new domain: x.net with domain admin account postmaster@x.net log out log in with postmaster@x.net click domains in top menu => you will see the domain x.net, as expected create account test1@x.net (simple user) create account test2@x.net (domain admin) log out log in with test2@x.net (also domain admin) issue: click on domains in top menu expected: you will see the domain x.net actual: No more domain to show issue: click on identities in top menu expected: you will see all identities under x.net, also postmaster@x.net and test1@x.net actual: Only test2@x.net is shown issue: click on add-account try to create test3@x.net (simple user) expected: this works actual: after pressing submit: Permission denied I also tried 'upgrading' a simple user to a domain admin (with the site admin account), this also results in a domainadmin with no rights. Then I also tried importing an account as DomainAdmins via python manage.py modo import account.csv Again, that account does not have sufficient rights. To me, this does not like like wanted behavior for a domain admin account?

kerem

2026-02-27 11:17:39 +03:00

closed this issue
added the
feedback-needed

stale
labels

kerem commented

2026-02-27 11:17:40 +03:00

Author

Owner

@reesing322 commented on GitHub (Mar 3, 2021):

I have investigated this myself a bit more in depth. I had a look at the core_objectaccess table,
and if I understand it correctly a domainadmin only sees the objects that are linked to him/her in that table,
is that correct? So having more than 1 domain admin actually is not going to work as expected...
As a test, I have deleted the primary DomainAdmin. The second one still sees no items.
Then I have executed the "python manage.py modo repair " script,
but that script didn't mention any objects without owner.
The objects were all linked to site-admin users instead.
As another test, I also linked them to the second DomainAdmin user by manually adding records to that table,
and indeed, that second (now only) DomainAdmin now can see the other identities...

So, I think modoboa was not designed to have more than 1 DomainAdmin (per domain), correct?

@reesing322 commented on GitHub (Mar 3, 2021): I have investigated this myself a bit more in depth. I had a look at the core_objectaccess table, and if I understand it correctly a domainadmin only sees the objects that are linked to him/her in that table, is that correct? So having more than 1 domain admin actually is not going to work as expected... As a test, I have deleted the primary DomainAdmin. The second one still sees no items. Then I have executed the "python manage.py modo repair " script, but that script didn't mention any objects without owner. The objects were all linked to site-admin users instead. As another test, I also linked them to the second DomainAdmin user by manually adding records to that table, and indeed, that second (now only) DomainAdmin now can see the other identities... So, I think modoboa was not designed to have more than 1 DomainAdmin (per domain), correct?

kerem commented

2026-02-27 11:17:40 +03:00

Author

Owner

@reesing322 commented on GitHub (Mar 3, 2021):

Final point, and this is the biggest issue in my opinion, when using the script
python manage.py modo import x.csv
all objects are linked to the site-admins in core_objectaccess,
but per domain mailboxes and aliases should also be linked to (each of) the domainadmins of that domain.

@reesing322 commented on GitHub (Mar 3, 2021): Final point, and this is the biggest issue in my opinion, when using the script python manage.py modo import x.csv all objects are linked to the site-admins in core_objectaccess, but per domain mailboxes and aliases should also be linked to (each of) the domainadmins of that domain.

kerem commented

2026-02-27 11:17:40 +03:00

Author

Owner

@stale[bot] commented on GitHub (May 3, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale[bot] commented on GitHub (May 3, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

kerem commented

2026-02-27 11:17:40 +03:00

Author

Owner

@stale[bot] commented on GitHub (Jul 2, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 2, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.