Clearing a Portal Filter on next/previous record

[CharlieD]

Not certain if this is the best forum but the issue is directly related to portals so here goes...

Is there a way to clear a portal filter automatically (via validation/calculations/etc.) if the user does a next/previous record? I believe the answer is no but wanted to verify. Assuming the answer is no, then I'm looking for suggestions for an alternate implementation of the following portal filtering structure...

There are 3 files (project, phase, test cycles). Relationships are defined from project->phase (off projectID), phase->test cycles (off phaseID), and project->test cycles (off of a currentPhaseID which is a calculated value in projects).

In projects I reference a value list which consists of the phase names for all phases that are part of the current project. That value list is used by a portal filter (and associated calcs/other relationships) to generate currentPhaseID in Projects which allows the user to be in a projects layout, select the phase they wish to examine, and then display only the test cycles for that phase in a portal in projects.

The issue is that when the user does a next/previous the value list is updated (since not all projects have the same phases) and if the project which is nexted/previoused to has different phases the filter still retains the value which was selected in the project which was previously displayed...however it isn't a valid choice from the updated value list.

If the filter cannot be cleared (and I don't think it can) is there an alternate way to structure the relationships and maintain the functionality?

Thanx!

CharlieD

[Fitch]

Best bet is to lock down the navigation and force users to use buttons and/or scripts to go to next/previous record...

[CobaltSky]

Hello Charlie,

There are several ways you might consider setting up your database so that the filters will be cleared when the user changes records.

One relatively straightforward solution would be to constrain the users to utilize custom navigation via buttons and scripts, and to incude some additional steps within the navigation scripts which will clear the portal.

Another approach would be to turn off access to your filtering criteria fields and format them as buttons attached to scripts which place the current recordID into a global field and then place the cursor into the criteria field. Users would have to click on the criteria fields to access them, thus storing the current record number. Then you would have to define a calc to check if the current record number matches the global field and if so, reference the portal keys and/or the filter criteria. Last, you would stack the calc which references the criteria on top of the actual criteria field(s), and redefine the portal relationship to work off the calculated key field. That way whenever the user changes to a record other than the one on which they were when they entered the current filtering criteria, the relationship will break and the criteria values (the stacked calcs) will appear blank.

A third solution would be to implement one of the script triggering plug-ins, (eg Troi Activator) and configure it to call a script each time the user moves to a new record (ie drive it with a calc which references the current record ID)

and define the script it calls to clear the filter criteria.

There are a few other alternatives also, but hopefully the above will give you some ideas to work with.

[CharlieD]

Thanx for the ideas. Some comments/thoughts:

On the first (constraining the interface) I thought of that, however in our testing we found that if the user has a mousewheel it directly drives next/previous even in detail layouts and even if the left pane is hidden...so it wouldn't be 100% reliable which would be even more confusing.

On the second I'm having a hard time visualizing how the button/fields would interact and would display on the screen (sorry). Currently there is a single popup menu which contains the list of Phases (i.e. Alpha, Beta, Gamma, etc.) and a portal to the side of the filter. When the user selects an item on the popup the portal displays the associated test cycles - pretty straightforward...and it is the desired user-interface so I am somewhat constrained on that side.

On the 3rd I'll have to look into the product you mention...sounds like it might be the best solution.

Thanx!

CharlieD

[CobaltSky]

Hi Charlie,

Since you were having trouble with my explanation of the second option, I am attaching a rough sample that gives an indication of how it would work.

Hope that makes it clearer?!

sample.zip

[CharlieD]

After looking over the sample (thanx) all I can say is duh! I forgot about "invisible" buttons/fields (which is pretty sad since I use them in other parts of the interface). The only thing is that the selection field now needs to be a drop-down instead of popup menu...I tried making it a popup (which I thought wouldn't work at all) but it treats it as a dropdown anyway (and we now have the button flash) but at least it works...

FPro certainly makes some things much more difficult then should be...

Thanx again.

CharlieD

[CharlieD]

Ignore my last comment about it not working correctly as a popup menu. I was just an idiot (again). It helps if you change the right field to be a popup vs a dropdown menu.

sigh.

CharlieD

[TWillson]

Charlie,

I'm not sure if this is 100%, but others have reported it, I believe on this forum, with a few different mouse configurations. If you hide the status area, it seems the mouse scroll wheel no longer scrolls records. Actually, to make sure users need to use custom scripts in order to scroll records I have utilized a seperate database just for the front end which only has one record to display the data. I understand there are many limitations to this setup but it seems to be working for my setup so far.

Tom