Jump to content

Calculating number of filtered portal rows


Justin P.

This topic is 4748 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Trying to calculate the number of portal rows displaying in a filtered portal.

Note that this is for a script calculation, not display (i.e. displaying a summary count in it's own one-line portal is not my answer in this case)

The reason I am trying to do this is: layout has an instant search field for a portal of related records (uses filtering to search), and when a search returns only one record, I want to automatically switch to an editing layout.

The many wise ones here may well have a better approach!

Thank you!

Juz

Link to comment
Share on other sites

By "instant search," you mean that the filter is a global? Are you using filtered portals bcs the field that you're filtering by is unstored? If that is the case (and so you cannot build the portal using a relationship), then how about an off-screen Find and if Get (FoundCount)=1, go to editing layout?

More details of you exact setup would be helpful.

Link to comment
Share on other sites

Wow, you guys are speedy. :)

You're on the right track. I have a global field on a dashboard layout, which is used in portal filtering logic to display matching records in a portal on same layout.

So I am wanting to count the records DISPLAYING (not just related), in order to:

(1) detect when the filter returns only one match, and go to it.

(2) detect when the filter returns no match, and put up a "no records found" message (blank portals are confusing :)

Makes sense?

Link to comment
Share on other sites

Note that this is for a script calculation, not display (i.e. displaying a summary count in it's own one-line portal is not my answer in this case)

This is a problem, because portal filtering occurs at the layout level - so it's difficult to get at the results from the data level. If you cannot use relationship filtering instead, consider placing the summary field in it's own one-line portal anyway (or inside the existing portal), give it an object name, and use GetLayoutObjectAttribute() to get the displayed value.

Link to comment
Share on other sites

The reason a filter was my choice rather than a straight relationship, is because there are a few different filtering criteria at work, and not all are from the same table.

I will describe the solution here, see if you think I made the right choice?

DASHBOARD table holds the filter and UI criteria base don current user.

JOBS table holds a list jobs in various filterable statuses

TASKS table holds all tasks assigned to a job.

The dashboard view is actually looking through TASKS then to JOBS, and displaying JOBS in the portal.

[dashboard] --A--> [tasks] --B--> [jobs]

That's because the dashboard shows you only jobs in which the USER has a task.

So relationship A uses USER and STATUS (open or closed tasks) to the TASKS table, then returns the related jobs using relationship B (simple ID).

The portal then uses filtering to limit the JOBS by other job-level criteria, (such as Overdue or Held jobs).

I couldn't work out how to do that "criteria across two tables" piece with just a relationship?

Did I miss something? (quite likely!)

(and yes, I can go off, perform find same as filter, and return foundcount, and store that somewhere to use for the calculation, but seemed like it may be a bit slow/clunky)

Thanks again for the assistance.

Link to comment
Share on other sites

You said originally that you're doing this calculation as part of a script. If so, this may be a solution for you:

Go to Object[ "your portal" ] // your portal needs an object name for this to work

Loop

. Set Variable[ $rows ; Get(ActivePortalRowNumber) ]

. Go to Portal Row [ Next ; Exit after last]

End Loop

The variable $rows now contains the number of portal rows.

Link to comment
Share on other sites

Could you not cut to the chase:

Go to Portal Row [ Last ]

Set Variable[ $rows ; Get( ActivePortalRowNumber ) ]

If the portal is furthest to the back in layout's stack order (or the only portal on the layout), then that's all that would be required.

---

I still think the method suggested in post #4 is simpler - and it will work for other types of summaries as well.

Edited by comment
Link to comment
Share on other sites

Could you not cut to the chase:

Go to Portal Row [ Last ]

Oh... of course. I pulled that out of part of a script I was using for something else. Good catch.

And yes, GetLayoutObjectAttribute on the summary field is ingenious... but not simpler IMO.

Link to comment
Share on other sites

That solves the problem! Thanks everyone. I was under the mistaken impression that couldn't detect "active" because their were no browsable fields in the portal, but "activerow" has nothing to do with that of course!

I will have to do something about removing the focus on the last row afterwards, but thats trivial.

As a response to the post re: moving the Filter.Globals to the Task table, this is my first attempt at a Data Separation Model solution, so I have tried to avoid putting any UI related variables into the data storage tables if I can help it. May not hold up till the end of my solution, but this is a learning experience for me and my previously pretty flat solution architectures.

Thanks again folks!

Link to comment
Share on other sites

This topic is 4748 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.