Domain account cannot change account's class of service?

[bhwong]

Domain Admin account should be able to change all accounts within it's domain to other class of services as long as there are availability. No? See attached error message. Does the main admin account has to do this administrative work for all domains then?

[mmorse]

Originally Posted by bhwong

ZCS Version: 5.0.11 FOSS and 5.0.18 NE editions on Ubuntu

This is not allowed in 5.x since you may want to assign a COS to a domain; an HSP may want to prevent changing COS/enabled features since that's how they charge. You can set quotas with an additional permission.

This has been solved in 6.x via Bug 11515 - role based delegate administration

Specifically Bug 29102 - expose COS and allow setting COS on account creation for domain admin

- check the assignCos right when account.zimbrasCOSId or domain.zimbraDomainDefaultCOSId is changed or provided to createAccount/Domain.

- Included setAttr right for account.zimbrasCOSId and domain.zimbraDefaultCOSId in the doaminAdmin combo right use for migrating domain admins.

- Fixed the upgrade to grant the assignCos right on COS's accessable to domain admins (by their zimbraDomainCOSMaxAccounts). FRANKLIN domain admins with zimbraDomainCOSMaxAccounts values are granted the listCos(see a cos in GetAllCos), getCos(see all cos attributes), and assignCos(can assign the COS to a zimbrasCOSId/zimbraDomainDefaultCOSId) rights.

There are 3 COS rights:
- listCos: can see the cos in GetAllCos
- getCos: can see all attributes of the COS
- assignCos: can assign the cos to an account or a domains/s default COS. the 3 together makes a COS "accessable" by an admin.

To make COS changes on account/domain, the admin also needs:
-set attr right on account.zimbraCOSId
-set attr right on domain.zimbraDomainDefaultCOSId e.g.

To assign COS-1 to user1@domain.com, the admin needs listCos,getCos,assignCos rights on COS-1, and set attr right of the zimbraCOSId attr on user1@domain.com (can be granted on the domain and inherited of course)

1. an admin login
2. the GetAllCos SOAP returns only COS's on which the authed admin has effective listCos/getCos rights.
3. the admin picks one from the returned COS list when he needs to assign cos to accounts or change the default cos for the domain.
4. Now, if the admin does not also have the assingCos right for the COS he picked, the ModifyAccount SOAP call will be PERM_DENIED.

[bhwong]

Does it make any sense to provide an option that is not allowed? What does "Allow domain admin to modify the account mail quota" actually do then? And what about "Maximum quota (mb) domain admin can specify"?

I notice that Domain administrator are not allowed to change COS despite having or given available COS to switch to by the main administrator. Yet they are allowed to bypass the COS by entering the quota for each account themselves. This just doesn't make sense to me. Anyone care to explain the logic behind this?

Since Administrator can create COS and set number of accounts limits, then it shouldn't matter if Domain administrators can swap COS according to user's need as long as these COS accounts are available, isn't it?

The default is just too inflexible, not to mention that most email HSPs are charging by domain quota with unlimited email accounts, not by account quota with limited email accounts. How can we compare and compete?

[sugiggs]

I already set everything you mentioned but still cant see the COS choices (when you create/modify account) from domain admin account..

Originally Posted by mmorse

This is not allowed in 5.x since you may want to assign a COS to a domain; an HSP may want to prevent changing COS/enabled features since that's how they charge. You can set quotas with an additional permission.

This has been solved in 6.x via Bug 11515 - role based delegate administration

Specifically Bug 29102 - expose COS and allow setting COS on account creation for domain admin