I want to work on "Multiple domains for organizations" - thoughts about the correct way to do it?

I have seen these feature requests (with multiple “likes”), and I also would like this feature myself, so I am planning to try to implement it:

https:// community.zammad. org/t/organisations-with-multiple-domains/377

(That thread also includes links to other issues that it seems I cannot access.)

https:// community.zammad. org/t/organisations-multiple-domains/1783

Before I get started writing code, I can think of several possible ways to implement this, and I would appreciate input about which of these makes the most sense, since they all have pros and cons.

  1. Allow comma-separated values in the existing domains field
    Pros: No database changes
    Cons: Requires using LIKE for lookup queries, which is probably inefficient; unstructured; requires manual query for uniqueness.

  2. Change the domains field to a PostgreSQL array (TEXT[])
    Pros: Can be indexed; Can be converted from existing text field; Zammad is moving to require PostgreSQL in 7.0+ anyway
    Cons: Requires a manual check or an extra table and a trigger for uniqueness; Cannot be released in Zammad 6.x because it relies on PostgreSQL.

  3. Add an additional field for other_domains (either comma-separated like #1 or an array like #2)
    Pros: Most organizations with only one domain will keep the existing easy code path of looking up a single domain, and we will only fall back to the other_domains field if the initial domain lookup returns no result
    Cons: Requires additional documentation about other_domains not being checked for duplicates, and not overriding domain from a different organization, or requires manual implementation of duplicate checks

  4. Add a separate table for domains, with a foreign key to organizations
    Pros: The cleanest way to implement in the database itself
    Cons: Requires the most code changes, including migration of the existing domain field to the new table, and design changes to the organization editing screen to allow multiple fields.

I’m inclined to do option #3+#1 – additional field stored comma-separated – because that is probably the least work to get a reasonable result, but I’m curious if anyone has any input before I actually start working on it.

3 Likes

First of all: Awesome! Thank you for taking up this task!

I’m not affiliated with Zammad in any way, but I would imagine #4 would be the best solution. Besides being the cleanest database implementation, it’ll probably reduce technical debt in the future.

You might want to take a look at the implementation of the multi-organization conversion and migrations. At one point, users could only belong to a single organization. It was then converted to having a primary organization and optionally secondary organizations. Maybe this will give some new ideas on how to proceed, or what other changes might be required?

Again: thank you for your willingness to contribute!

1 Like