When I open a ticket (Create/Edit) with a Core Workflow setup with 1. priority to remove all options, and a 2. priority workflow to show specific fixed options in a dropdown, depending on organization, and it should not, ever, show any other options for the customer.
Actual behavior:
Customer wants to create/view/edit a ticket, and for 1-3 seconds all other options pops up in the dropdown, and they are able to see other options in there.
Steps to reproduce the behavior:
Create a ticket object as dropdown with a few values. Make a core workflow with 1st priority to remove all the options, and then a 2. priority Core Workflow to add specific options to the dropdown based on a customers organization.
I’m not sure if this is something with my setup, or maybe I need to reconfigure something? Or maybe I just completely misunderstood how Core Workflows work. But I think 1-3 seconds to initialize something like that is a long time.
I have multiple customers (organizations), and I have a custom dropdown on my tickets with project names, and I use the Core Workflow to filter these projects, based on the organization of the customer.
I do not want, for 1-3 seconds, my customers being able to see other customers/organizations projects.
Is there a way to avoid that all fields are loaded into the form first, and then filters enabled? Wouldn’t it be a better approach to run the core workflows through, behind the scenes, and then when ready show the correct form, instead of initializing a for with ALL FIELDS and ALL options, and then in front of our eyes apply the core workflows?
Or… am I just completely missing something here? Is this a unique experience for me? Am I doing this wrong? Could I avoid having to use Core Workflows for this feature/functionality? Can I enable some optimization/tuning to Zammad or my server? I’ve already tried the Ajax Mode, which doesn’t help.
But besides that, I am very excited about a system like this being open source and free, and it works very well compared to other systems that are NOT open source and NOT free to use. So thanks for putting all the time and energy into this. Unfortunately, I am not a very experienced Ruby programmer, so I am not able to contribute with a lot of help on GitHub.
Have a great day!
Edit:
Here’s a screenshot of the network monitoring in my browser. The “perform” requests at the bottom, are slow…
I noticed this too. I have a simple workflow that hides a couple of things from the customers and they are always visible for a very short time and then disappear. I guess that’s a result of how the feature was implemented as a workflow that manipulates the page instead of an implementation in the core rights system or whatever.
I did find a “workaround”, but I won’t consider it a solution. Basically, I went to the object and per default set all my custom fields to hidden (removed the mark in “Shown” for all roles).
After that, I made a core workflow, with priority 1, where I set all fields to “Hide”… every single one!
After that, I made a 2nd priority workflow, where I removed all options from the fields (eg. “project” field), and then I started making workflows with lower priorities after that, that added options back to the fields, depending on different roles and conditions, and finally, I made a workflow that showed all the fields again.
This actually gave me a pretty fast initialisation of the fields, without showing other options for a few seconds. Only “Group” and “State” shows up for a split second, and then disappears. I cannot do anything with these 2 fields since they are “hardcoded” into Zammad.
Even though this is a temporary workaround, it’s a bad solution, and it makes the core workflows feature UNNECESSARILY difficult to manage for different customers/organisations, roles and specific workflow scenarios.
Also, it’s still possible (if you’re a bit technically skilled) to see the JSON response that basically has all the options shown in all the fields that are available to that customer.
I’m currently investigating this issue. If you want to support me, please do the following steps:
Configure your system that way that core workflow responds slow
Do exports for me:
zammad run rails r "puts ObjectManager::Attribute.all.to_json" > attributes.json
zammad run rails r "puts CoreWorkflow.all.to_json" > cw.json
If you have confidential data in it, then please send it to support@zammad.com handing to me Rolf Schmidt with a link to this thread. Else post here pls.
Thank you for taking your time to look into it.
I’ll take a look at it tonight.
As I mentioned in the thread, I managed to find a “workaround”, so I will just have to try and set it up again as it was.
Is it possible, through command line (I can see that it’s possible to export the workflows as json), to export the current workflow (with the command you mentioned), and then import it again later?
That would make it easier for me to:
Export current setup
Delete everything
Setup the workflow that was slow
Export that for you
Delete that again
Import original (working) workflow
So, if possible, could you give me the commands to do the steps above (export, delete, import of necessary data (attributes, CoreWorkFlow etc.))? That would make it easy/fast for me to provide you with the data you need.
@systemedz If it is to much effort for you now you also can wait for the first fix. I have a customer with a similar problem which I already debugged and flame graphed. I just wanted to ask for your data to check If it could fix your issue as well.
I have some scripts for test environments but they are not production ready. I would prefer to not share them here.
Hi guys,
please update your zammad installations. I fixed some performance issues which boosted my customers system by a lot. Hopefully it will help you too.
