Ticket-State issue

I apologise for opening this topic again.

Due to illness, I could no longer follow it and the old topic was closed.


We have a problem in the UI in Zammad status “Open After”.

If you set the state and update, it will work. However, the marker for “unsaved changes” remains.

Only when you close the ticket and “Changes discarded” the marker disappears. The new status remains set nevertheless.

As soon as this ticket is opened again, the marker “Unsaved changes” reappears.

To understand why a new status was created.

We are coming from OTRS and the import to Zammad has messed up all the states. It was partly English and German mixed and other errors.

So we disabled all states of Zammad to avoid collisions. The new state came later.

MrGeneration meant we should list all existing IDs. However, his command did not work.

zammad run rails r “p Ticket::State::Type.find(4)”

I have now taken this as an alternative

zammad run rails c
then
Ticket::State.by_category(:pending).pluck(:id)

Output
=> [15, 6, 16, 7, 8]

Old threat

Infos:

  • Used Zammad version: 3.6.x
  • Installation method (source, package, …): Debian PPA
  • Operating system: Debian 9
  • Database + version: Postgres 9
  • Elasticsearch version: 5.6.16

Expected behavior:

The status is saved correctly and there is no mark with “Unsaved changes”.

Actual behavior:

If you set the state and update, it will work. However, the marker for “unsaved changes” remains.

Only when you close the ticket and “Changes discarded” the marker disappears. The new status remains set nevertheless.

As soon as this ticket is opened again, the marker “Unsaved changes” reappears.

Steps to reproduce the behavior:

Follow this Guide for Pending and add time/date
https://docs.zammad.org/en/latest/admin/console/working-on-tickets.html#add-a-date-and-time-picker-pending-till-for-pending-states

The following commands were used for this status.

1. Create State

Ticket::State.create_or_update( name: 'Öffnen nach', state_type_id: 4, ignore_escalation: true, next_state_id: 2, created_by_id: 1, updated_by_id: 1, )

2. Add Timetable

ObjectManager::Attribute.add( force: true, object: 'Ticket', name: 'pending_time', display: 'Pending till', data_type: 'datetime', data_option: { future: true, past: false, diff: 24, null: true, translate: true, required_if: { state_id: 15, }, shown_if: { state_id: 15, }, }, editable:false, active: true, screens: { create_middle: { '-all-' => { null: false, item_class: 'column', }, }, edit: { '-all-' => { null: false, }, }, }, to_create: false, to_migrate: false, to_delete: false, position: 41, )

3. Update Zammad-UI

attribute = ObjectManager::Attribute.get( object: 'Ticket', name: 'state_id', )
attribute.data_option[:filter] = Ticket::State.by_category(:viewable).pluck(:id)
attribute.screens[:create_middle]['ticket.agent'][:filter] = Ticket::State.by_category(:viewable_agent_new).pluck(:id)
attribute.screens[:create_middle]['ticket.customer'][:filter] = Ticket::State.by_category(:viewable_customer_new).pluck(:id)
attribute.screens[:edit]['ticket.agent'][:filter] = Ticket::State.by_category(:viewable_agent_new).pluck(:id)
attribute.screens[:edit]['ticket.customer'][:filter] = Ticket::State.by_category(:viewable_customer_edit).pluck(:id)
attribute.save!

Push, any ideas?

this state are now broken :S

For anyone who has similar problems and doesn’t know what to do.

We have now been able to fix it as follows.

Complete migration to a new, naked, Zammad. With its own backup/restore function.

Apparently many small bugs are fixed automatically and we are very happy.

Thanks to the developers for this feature! :slight_smile:

PS: Those going from Zammad 3.6.x to 4.1.x will probably need this as well. We had to do it.

Just a small hint:
The steps in your first post are technically incorrect and add new attributes for mechanics Zammad already has. Please stick to this documentation part for states and especially pending states:
https://docs.zammad.org/en/latest/admin/console/working-on-tickets.html#add-new-ticket-state

Especially StateType-ID 4 usually is state closed which doesn’t seem right for a state name that indicates a pending action.

Why not?

We had as a goal to establish a status that tickets are closed until a date X is reached. Then it should be opened automatically. Without reminder and be reprocessed normally.

For this purpose, Closed until seemed correct to us

The state_type tells Zammad what kind of status it is working on RIGHT NOW.
This means “closed” is wrong, you’re looking for pending action.

So that part:
https://docs.zammad.org/en/latest/admin/console/working-on-tickets.html#pending-reminders

After that you’ll need to update the pending_till:
https://docs.zammad.org/en/latest/admin/console/working-on-tickets.html#add-a-date-and-time-picker-pending-till-for-pending-states

and make the state visisble:
https://docs.zammad.org/en/latest/admin/console/working-on-tickets.html#make-new-states-available-to-ui


It is not possible to tell Zammad “I have a pending state here which please looks like a closed one”.

Yes, you can use custom objects and schedulers to workaround that. However: It’s no suggested way and -in my opinion- very dirty.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.