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
Pros:
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
Cons:
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)
Hey @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.up and/or self.down on them. Rails change method will not work! A migration would look like this:
# db/addon/your_package_name/20200121171523_your_migration_name.rb
class YourMigrationName < ActiveRecord::Migration[5.2]
def self.up
ObjectManager::Attribute.add(
# ...
)
ObjectManager::Attribute.migration_execute
end
def self.down
ObjectManager::Attribute.remove(
object: '...',
name: '...',
)
ObjectManager::Attribute.migration_execute
end
end
For testing purposes you can use Package::Migration.migrate('YourPackageName') or Package::Migration.migrate('YourPackageName', 'reverse') on the Zammad rails console.
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.
This does indeed cause the form field to render as disabled!
However it only works on select attributes. textareas, date, and 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
@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.