Temporarily omitting a portal row

[Angus McKinnon]

I've been gradually working on a planner layout, which uses a portal and conditional formatting to display availability of hire items. It's working well so far, and is proving popular with users. 

At the moment, I'm using portal filtering to narrow down the selection in the portal, typically to just one product/item. Each occurrence in an order is displayed in a portal row. What I'd like to be able to do is temporarily exclude an item from the portal results. Sometimes the query used to filter the portal is too broad, or we have a very similarly named item that turns up when it isn't relevant. In an ideal world, the user would hit a button on that portal row, and it would disappear (and would not be counted in the various summaries etc. that we use).

If I was dealing with a found set of records in list view, I'd simply script a button to Omit Record and that would be that. There's not an equivalent behaviour within a portal since it's based on a relationship. I'm already filtering the portal and could add a condition to that formula to facilitate this, but I'm struggling to think of an elegant way of achieving it. 

What's simplest (at face value anyway) is having an "omit" field on each record. Pressing the button toggles that field, and the filter takes care of the visibility. I can think of two drawbacks. If one user toggles the field, then it will affect other users too. Also, the field needs to be "reset" afterwards. The table has 40k+ records so a simple looping Set Field step isn't going to be particularly efficient. 

The possibility I can think of is to approach it from the other angle. Each record in the portal has a unique ID. The button could copy that ID into a global field on the enclosing table, and this field is used for the filter instead. The advantage is that I've only got one field to clear/reset afterwards. I can just append multiple IDs to the one text string in the global field and use a patterncount in the filter formula. This still feels a little clumsy though, is there a better method that I'm missing?

[comment]

The part that's missing from your question is "for how long". You could store the "omitted" record's ID in a global variable. If you like, you could even have a separate variable for each parent record. That would last until you clear the variable or until the the end of the current session, whichever comes first (as would a global field, in case of a served solution).

 

14 minutes ago, Angus McKinnon said:

I can just append multiple IDs to the one text string in the global field and use a patterncount in the filter formula

It would be better to append them to a return-separated list, and use FilterValues() for the filtering.

[Angus McKinnon]

1 minute ago, comment said:

The part that's missing from your question is "for how long".

In theory, it's not long at all. The omitted record IDs definitely don't need to persist between sessions.

The actual scenario is that the user searches for upcoming availability on an item, gets taken to the planner layout, and may choose to remote a record or two. The state of the portal will only be around for that single view which is likely only to be open for the minute or two it takes them to decide that there is enough availability to approve a hire. 

I'd prefer to purge the omitted list quite promptly, so that they aren't accidentally kept out of other searches. At the moment, we don't have the volume of users for this to be much of a problem but it wouldn't take much to cause confusion. 

7 minutes ago, comment said:

 (as would a global field, in case of a served solution).

Just thinking, I'm using a served solution.Does a global field or variable share the same value between users? If it doesn't, then my concern about accidentally affecting other users isn't warranted. 

Quote

When a client connects to a hosted database, each client’s global field values are maintained independently from one another. This makes global fields useful as temporary storage locations for information unique to each client’s session, such as fields used for filtering portals or lists.

Just found this in the FM help. So it looks like I don't need to worry about different users clashing. 

[comment]

That is correct, global fields are user-specific. As are variables.

 

2 hours ago, Angus McKinnon said:

I'd prefer to purge the omitted list quite promptly, so that they aren't accidentally kept out of other searches.

It should be easy to do, if the process is scripted. If not, you could use a script trigger for this (e.g. on entering the planner layout).

 

 

Edited March 29, 2019 by comment

[Angus McKinnon]

I've only just been able to return to this task. In theory it should be simple enough to implement, but I suspect I'm doing something wrong with my syntax. (Yet again)

I've got the global text field set up (called "Orders to Omit") and there's a button on the portal which appends the OrderID of that item onto the list. The problem is the filtering. 

To try and simplify things, I've put a calculation field in each item record, using an IF statement to return a "Yes" or "No". However using Filtervalues as below doesn't seem to work. The calculation returns "No" irrespective of whether the OrderID is in the "Orders to Omit" field or not:

If ( FilterValues ( Item_Planner::Orders to Omit ; GetAsText ( OrderID ) ) = GetAsText ( OrderID ) ; 
"Yes" ; 
"No" )

 

I also tried using PatternCount as an alternative:

If ( PatternCount ( Item_Planner::Orders to Omit ; GetAsText ( OrderID )) = 5 ; 
"Yes" ; 
"No" )

 

(All of our OrderIDs are five digit numbers so this should give me a match)

I added the GetAsText function because I realised that the OrderID field is a number, but it doesn't seem to make any difference in either version of the calculation. 

I'm hopeful that it's just another simple blunder, but I'm not sure if something else might be afoot...

[comment]

If I follow this correctly, the filtering expression needs to be =

not IsEmpty ( FilterValues ( Orders::OrderID ; Item_Planner::Orders to Omit ) )

Note that a filtering expression is evaluated as a Boolean: it must return either True (a number other than zero) or False (zero or empty). In your attempts, both possible results are False because both "Yes" and "No" are strings that do not contain any non-zero digits.

[Angus McKinnon]

12 hours ago, comment said:

If I follow this correctly, the filtering expression needs to be =

not IsEmpty ( FilterValues ( Orders::OrderID ; Item_Planner::Orders to Omit ) )

 

Got it - I think!

I was trying to detect a match between the Filtervalue result to the Order ID of the line item in the portal.

It figures that if there isn't a match the result will be empty so no need to to worry about equivalence. That's a much more elegant way of working it. 

It'll be a day or so before I can get back to this but it'll be the first thing I try, hopefully that'll be it.