Hello Zammad team,
We run Zammad as the base of an internal service-desk system and extend it through one Zammad
package (Package.install, db/addon/, prepended modules from initialisers), without editing
Zammad's files. Three things cannot be done through Zammad's current extension points, so we carry
them as overrides that we must re-check at every release. We would like to ask for proper hooks for
them. Each is small and general; we would be glad to help with pull requests if you want them.
1. Custom fields on objects a package adds. ObjectManager.list_objects and
ObjectManager.list_frontend_objects (app/models/object_manager.rb, lines 13 to 27 at 7.2.2)
are fixed lists of Zammad's own five and four objects. A package that ships its own models with
object_lookups rows cannot offer administrators custom fields on them, although the backend
stores attributes for any object name and the GraphQL enum, the admin screen's object list, the
session payload and MigrationHelper all read those two lists. Request: let a package register
additional objects for both lists (for example a registry that list_objects and
list_frontend_objects append to, or a configuration hook read at boot), and let
spec/models/object_manager_spec.rb (lines 8 to 18) accept registered objects, since today it
pins the lists to Zammad's own. Related: MigrationHelper.rename_custom_object_attribute_reserved
(lib/migration_helper.rb, lines 38 to 52) checks every listed object and needs each one's
lookup row and class; a `models` list on such calls, as the 7.2.2 migration for reserved private
methods already passes, keeps a release's migrations from failing on a package's objects.
2. Refusing local passwords per role. Deployments where every agent signs in through an identity
provider (SAML or OpenID Connect) want staff accounts to have no usable local password: no reset
mail, no reset link, no password sign-in for those roles, while customers keep theirs. Today every
reset goes through User.password_reset_new_token and User.password_reset_via_token
(app/models/user.rb, lines 414 to 432 and 462 to 474), with no per-role switch. Request: a
setting that names the roles which may not set or reset a local password, in the form of
two_factor_authentication_enforce_role_ids (db/seeds/settings.rb, lines 6132 to 6155), honoured
by the reset, sign-up and invitation paths and by the password sign-in.
3. A registry of checks before core records change. Integrations that mirror another system of
record need to refuse, outside their own connector, any create, change or delete of records that
the other system owns (tickets, articles, time accounting, organisations, users, tags, links),
during a transition period. Today that takes prepending before_create, before_update and
before_destroy callbacks to seven model classes. Request: one place where a package registers
a check that Zammad runs before those core records are created, changed or deleted, with the
record, the changes and the acting user, and that can refuse with a message the UI and the API
report.
We pin Zammad at a release tag and upgrade through the official container image, so any of these
landing in a release would let us drop the matching override.