Default filters on detail

@Daan Heemskerk try starting your Process Flow with the Activate detail Process Action (https://docs.thinkwisesoftware.com/docs/sf/process_flows_actions#activate-detail).

Hi Arie,

I tried but it didn’t work;

It seems that there is still something missing.

@Daan Heemskerk Could you check in the Process flow monitor on Indicium what Status code is returned for the ProcessActionCompleted - activate_detail_report_custom_next?

I know there is an open bug (which I could reproduce just now) on the fact that this Process Action sometimes, incorrectly, returns a -1 status code instead of a 0 status code and then does not continue properly.

EDIT: if indeed you get Status code -1 returned, please do raise a TCP with your specific Process Flow and Screen Type setup.

Hi Arie,

Thank you, I will have to look why my process flow monitor is not working first.
( Possibly a firewall thing ).

If I look at the network traffic from another page where I open a document I can see a call to the processes flow. On this page I don’t see any call related to the process flow.

Greetings,

Daan

@Daan Heemskerk check if you have Websockets enabled in IIS. That is a prerequisite for the Process Flow monitor to work. Also make sure you have that screen opened in a separate tab before starting the Process Flow.

https://docs.thinkwisesoftware.com/docs/deployment/indicium#prerequisites

Hi Arie,

Thank you, it was actually simple, I selected the wrong reference, and it took a while until I noticed.

But now I do have two new problems;

First: I have a double Key; ( context_level_id, context_id ) on one lookup.

When I don’t apply the filter from the workflow this allows me to select all ( context_level_id, context_id ) combinations.
When I set the filters using the workflow the first key context_level_id gets locked to the value I set using the workflow.

Second: while the Open Document action only fires the first time I open the document this action always fires, clearing the filter set by the user, which was not what I want, it was just not to start empty.

Do you know what the correct behaviors with respect to the first problem are? Should it be possible to create a single lookup for a double key relationship, or is it an coincident that this works in this scenario?

Thank you,

Daan


 

1. the inline filter form only provides values which are available within the filtered dataset. So the fields filter eachother too. If you select a value in field A, the options in field B are reduced. It sounds like you are facing this by-design behavior.
2. If the activate_detail action is a start action, there is currently no way to only run on the first run. You might consider to create a idea for that. For this case it sounds like a valid case.
   
   In the meanwhile, maybe convert the filter in a prefilter, which is default selected on the detail? Or work with detail tiles to open the detail subject in a separate document, maybe?
   
   I hope this helps.
   
   Best regards, Erik

Thank you,

Unfortunately, I don’t think the prefilter is an option.

The option to start a workflow opening a detail the first time would work, and I might create an idea out of it..

I do make sure in the model that the user sees a report corresponding to the most recent month. So, not selecting a filter means filtering on “Whole organisation”, “This month”. 

Not being able to set the filter makes that it is not clear for the user that this is the case, and that “empty”, “empty” has the same meaning as “Whole organisation”, “This month”. 

I found a workaround I might also implement here and that is to use an auto-commit form instead of a  filterbar. The problem with this workaround is that it can cause interference between different browser tabs in the same session as I have to store the users selection server side. This is actually a better solution then the current one as it gives full control over the filters, with default / layout procedures etc. But the fact that the values are stored server side gives a small bug.
 

Hi Daan,
Good to hear that this alternative implementation works for this case. We see this more from other customers.

It is not clear to us what you mean with this "small bug” but feel free to raise a ticket for that in TCP.

This sounds like a specific case there the provided filter options of the Thinkwise platform did not fit. It sounds like you are on the right track now. If necessary validate this case with your Thinkwise consultant. They may know alternative options from their experience at other customers.

Best regards,
Erik