Ticket #2237 (assigned nice to have)
The domain_alias table should have more columns indicating capabilites
| Reported by: | aseques | Owned by: | nuxwin |
|---|---|---|---|
| Priority: | normal | Milestone: | ispCP ω 1.2.0 |
| Component: | Frontend (GUI) | Version: | ispCP ω trunk |
| Severity: | Hard | Keywords: | |
| Cc: |
Description
In plesk there use to be some attributes part of the domain_alias that ispcp at the moment doesn't have, they where the following:
`dns` enum('false','true') NOT NULL default 'false',
`mail` enum('false','true') NOT NULL default 'false',
`web` enum('false','true') NOT NULL default 'false',
`tomcat` enum('false','true') NOT NULL default 'false',
I don't care about tomcat, but having the information to allow/deny a service like dns or mail for a domain alias would be very important.
I was thinking of doing mail delivery only if the alias domain has mail enabled. This is trivial in dovecot with database backend and really useful.
Change History
comment:1 Changed 2 years ago by nuxwin
- Owner set to nuxwin
- Status changed from new to assigned
- Type changed from enhancement to nice to have
- Severity changed from Don't know to Hard
- Milestone changed from Working to ispCP ω 1.1.0
comment:2 Changed 2 years ago by aseques
I agree that ispcp must have each own way of do the stuff.
But the use case I'm talking about is a real one.
Tipically lots of companies have a domain for every language (.com for international, .es for spanish, and so on...), many times, if the company is not that big, the want all the mail address to be the same.
info@example.com == info@example.es
That could be accomplished easily (in fact I'm already doing that on dovecot), the only drawback at the moment is that I cannot do it selectively.



Hello ;
First: IspCP is not plesk.
The current implementation of ispCP provides already these attributes (domain properties) but only domain-level. All domain aliases that are descendant inherite of these properties.
Normally, a domain alias should be used for extend the parent domain (eg for i18n issue) and no to allow user to manage several domain names that are not linked. The actual usage of these is bad and should be review.
In the future, the possibility to link several real domain name to one user account will be added, each of these will have separate properties for the management of services.
I move your ticket to the milestone 1.1.0.