Issue #1447 customerticketzoom

[stefanhaerter]

1. I removed the code for displaying process and activity permanently, so from now on, if this information is wanted, the corresponding dynamic fields have to be used
2. A reference bug caused broken activity information in the config at runtime

Closing #1447

[bschmalhofer]

Looks fine. The removed code avoids the problem of inadvertently changing the data in the Kernel::Config instance.
I have one suggestion for further code cleanup. In line 1782 the variable $NextActivityDialogs is assigned a new value, unrelated to the previous value. In those cases I tend to give the variable a new name, declared with my.

[stefanhaerter]

Thank you for the good suggestion. I would make this change, but this seems to happen in L1795 also. I don't know if that makes much of a difference, but intuitively I would want to avoid initializing several variables which are not used later on - what do you think?

Maybe it could be a solution not to overwrite the existing variable but to actually filter the values with map?

[bschmalhofer]

I haven't really looked closely at the code. The reuse of variables in different contexts is IMHO a red flag. If it occurs in several lines then it might make sense to rename or remove those variables. But of course only when there is no danger of unwanted side effects.

[stefanhaerter]

I tried to reduce the assignments with my latest commit. Do you think this looks ok?

[svenoe]

Please confirm that $ActivityData and $ActivityData->{ActivityDialog} are always hashrefs.
Please look for LayoutObject->Block(ProcessData) in AgentTicketZoom.

[stefanhaerter]

I added checks with IsHashRefWithData on ActivityData and ActivityData->{ActivityDialog}.
AgentTicketZoom doesn't render a ProcessData block and apparently never did since the initial OTOBO commit.