Automating creation of custom Object Attributes

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:

  1. 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)
    • Limited functionality?
  2. Create a zpm (Thanks for the instructions @thorsteneckel !)

    Pros:

    • Easy to deploy
    • Raw power of rails

    Cons:

    • 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

  1. Create a class using class Ticket::CustomSelectFieldName < ApplicationModel (example)

  2. Seed the database with some default values (example)

  3. Create the Object Attribute with ObjectManager::Attribute.add (example)

  4. Wrap this all up in a zpm as described here

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

With an entry in your zpm file like this:

    {
      "location": "db/addon/your_package_name/20200121171523_your_migration_name.rb",
      "permission": 644
    },

For testing purposes you can use Package::Migration.migrate('YourPackageName') or Package::Migration.migrate('YourPackageName', 'reverse') on the Zammad rails console.

Hope this helps :+1:

1 Like

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).

But @thorsteneckel might correct me here. :slight_smile:

@MrGeneration thanks for the quick reply

I think you misunderstand me, I’m referring to the editing sidebar an agent sees.

Example:

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 assets/javascripts/app/views/widget/*) support an attribute.disabled field.

Edit: Reading the source I see that I can specify “disabled” in the screens field of the Attribute.

screens: {
"edit"=>{
"ticket.customer"=>{"shown"=>true, "required"=>false},
"ticket.agent"=>{
  "shown"=>true,
  "required"=>false, 
  "disabled"=>true # <--- add this
}}}

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 :construction_worker_man: 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 :heart:

:boom: PR #2929: Consistently handle the ‘disabled’ attr in inputs

2 Likes

As promised: https://gitlab.com/digiresilience/link/zammad-addon-template

1 Like