[ricardoduarte]

Hi there,

I'm having trouble with some case labels, where the variables do not expand.
So, I have a task with case label @#document_number, requested by @#user . Some cases will show just the ", requested by" as the case label.
If I go to the task definition and add something before @#document_number (say "Process "), the labels work.

The descriptions for the same tasks also are not expanding the variables.

What I can see different on these cases are that some variable text have apostrophes, or braces.

Also strange is that this seem to only happen on a particular task. But all the parameters of the task are the same as the other tasks on the process.

Any idea what can be the problem?

Thanks

[amosbatto]

I can't replicate the problem in PM 3.3.4 Enterprise.

Do you see the same problem if you use one of the following?
@=document_number, requested by @=user
or
@@document_number, requested by @@user

[drmanuel]

Hi Amos,
I've the same issue. As you suggest I change the prefix variable with @= and @@ but without success.
I notice that only the new cases are affected and that if I enter in the design Case Label section and I do any change (ex. from @@ to @# or viceversa or @= ) , the case label of requests with inexact label appears correctly in the inbox area of user.
Any idea?
Thanks in advance.
M.

[programerboy]

Hi,

I have same problem!
I think this problem is when I set trigger after route.
I have to update APP_TITLE field with query again.

Thanks

[amosbatto]

I still can't replicate the problem on my installation of ProcessMaker 3.3.4 Enterprise, but as programerboy suggests, you can get around the problem by adding the following trigger to your process:

Code: Select all

$c = new Cases(); 
$aCaseInfo = array(
    "APP_UID" => @@APPLICATION,
    "DEL_INDEX" => @%INDEX,
    "APP_TITLE" => @@document_number.", requested by ".@@user
);
$c->updateCase($aCaseInfo);

Then, set this trigger to fire at some point in your process.

[drmanuel]

Hi amosbatto,
I have the same issue on 2 different server with the community version.
Strangely your solution doesn't work but the one of programerboy do.
However this solution is very difficult to follow, because I don't want to create a trigger for all tasks and for all processes, because I set the case label in the task properties differently for every task. Every user wants to see the relevant information for his job in the personal inbox section. Moreover the setting of Case Label in the task property was so cool until it worked!
Thanks in advance.
M.

[ricardoduarte]

I'm not sure I understood the suggestion by programerboy.
Can someone explain it?

I currently only see this problem on a particular task.

If I change the title on the designer, the title gets fixed but it reverts after cron runs.
Also, if I go to "Advanced Search" the task shows with the wrong name all the time.

pm_snip.PNG (40.84 KiB) Viewed 9076 times

pm_snip.PNG (6.67 KiB) Viewed 9076 times

[ricardoduarte]

I now understand what programerboy said.
The problem happens when I have a post-routing trigger.
In my case, I have one under the "Process Order" task.
If I remove the post-routing trigger, the labels are updated properly.

[drmanuel]

Yes ricardoduarte, I confirm what you say.
I've the same results deleting the trigger in post routing.
Thanks for your suggestions.

[GiftsTakers]

I'm seeing this problem too and I also have triggers in post-routing that send an email to IFTTT for notification purposes.

[amosbatto]

I found out that this is a bug in ProcessMaker. If there are multiple triggers fired during routing, then only the variables in the first trigger are saved. To get around this bug, you need to combine all your after routing triggers into one trigger if you are using 3.3.8 or later. This bug was fixed in version 3.3.9

The is another bug setting the values in grids in triggers after routing. This bug will be fixed in version 3.3.12.

[GiftsTakers]

Thank you for the info.

I changed my variables to be @# instead of @@ and for some reason now all the case labels are correct. Very odd.