We want to add some custom attributes to our ticket model automatically on several different zammad instance (prods, devs, test, etc), but I’m not sure the best way to go about.
The attributes are a handful of select, tree select, and text fields.
There seem to be 2 options:
Use the HTTP API
Easy to code - we would just need to create the new attributes manually via the UI then introspect the JSON via the API and replay it against new instances
Requires software external to Zammad that needs its own deployment and maintenance
Unclear if it is possible to modify the attributes afterwards (add new choices for example)
Create a zpm (Thanks for the instructions @thorsteneckel !)
Easy to deploy
Raw power of rails
It’s not clear how best to implement this, see below.
First, do the Zammad devs have a gut reaction as to which is the preferred choice?
Then, if taking approach
#2, would the following procedure appropriate? Proposed example procedure for creating a select attribute with options in Ruby
Create a class using
class Ticket::CustomSelectFieldName < ApplicationModel (
Seed the database with some default values (
Create the Object Attribute with
Wrap this all up in a zpm as described
@abelxluck - we recommend to use a zpm package for what you’re planning. However, addon migrations are kind of special. You need to place them in
db/addon/your_package_name and need to define
self.down on them. Rails
change method will not work! A migration would look like this:
class YourMigrationName < ActiveRecord::Migration[5.2]
With an entry in your zpm file like this:
For testing purposes you can use
Package::Migration.migrate('YourPackageName', 'reverse') on the
Zammad rails console.
Hope this helps
This is working great! I wrote a little python script to create a szpm from a source tree… I’ll post a link to that soon.
Is it possible to show a Ticket Attribute on the edit ticket screen but as readonly? We have some customer submitted fields we do not want the agents changing.
Edit: To clarify I don’t mean make the ObjectManager::Attribute itself readonly (that is via the
editable flag on the Attribute model), but rather the form control in the ticket edit screen.
I don’t think we have that yet, because otherwise you could edit ticket states. (because you need to protect default values that are mandatory).
@thorsteneckel might correct me here.
@MrGeneration thanks for the quick reply
I think you misunderstand me, I’m referring to the editing sidebar an agent sees.
Here is an attribute, “Custom Attribute”, I would like that to be readonly for agents.
I can see that all the generic form widgets (in
Edit: Reading the source I see that I can specify “disabled” in the
screens field of the
"disabled"=>true # <--- add this
This does indeed cause the form field to render as disabled!
However it only works on
text types do not have the
disabled attr applied on their html control. I suppose this is a bug?
Nice to see you digging into it
I’d call it enhancement because this is no behavior that is required in the core but in the end you’re right - we should have this. Would be great to see a Pull Request for this
is this eventually the same issue?
For each object, you can give different user rights to cutsomers and agents. There is a view, create and edit option.
But for ticket objects, the view option is missing. Can this be added somehow?
[Organization] [Ticket] [User] [Group]
@ecomsilio Almost yes. I wanted to be able to have inputs disabled but still visible. In your case you want them not shown. They’re similar as they affect the details of custom objects and how users can see and interact with them.
If you need those custom features, then I suggest writing an addon. Our addons are open source here: