Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

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

Recommended Posts

Posted

I have a layout that shows a list view of various open issues...

Multiple users keep that screen up during the day.

New issues get added to the list a few times a day.

The users need to manually click a refresh button to see anything new added.

I want to make it auto-refresh... so I installed a timer that would reload every X minutes.

The problem is that if a user is doing something in the app when it reloads, it kills what they are doing and forces them back to the refreshed layout.

For example, if a user is entering a new issue when this timer kicks on, it pushes back to the layout and the record they were entering is in there as incomplete and they have to go back into it and finish is.

ANy way around this?

Posted

That's odd. A user should see records appear (and disappear, if deleted) from a list view without a refresh.

This is a list view, not a filtered portal that perhaps uses a global on the parent side?

Posted

I missed one important detail.. my apologies..

the list view is filtered to omit any issue marked as CLOSED when it is first loaded.

I have all the issues in one table - and just flag the record closed.

I guess I could get around this by having records moved to a new table when they are closed.

The users are seeing the new records - they incorrectly described the issue to me - what they are not seeing, are the closed records drop off unless they refresh.

That is where I was going to add a timer - to refresh the layout causing the filter to reapply itself.

I guess I could get around it by copying a closed issue to an archive table and deleting it from the main list table... that should cause any closed item to disappear correct?

Posted

Now it makes more sense.

How are you "filtering" a list view? Are you actually finding using an OnLayoutLoad script trigger?

I don't like timers. Hmm. This layout just sits on their screen in a found set, and you need to update the found set.

How about using a filtered portal instead of a list?

Posted

yes I use a trigger on the layout load that omits anything with a status field of Closed.

The screen just sits there with the list that was filtered on load - and during the day issues are being closed. Now the good thing is that it will show closed as they get marked closed naturally... but they do not drop off the list until a layout reload.

Ideally what I would like is some way of when an issue is marked closed that it vanishes from all users screens.

The only way I can think of doing that is by copying the closed to a new table and removing the record from the table the list layout is based on.

This however opens up some other issues with reporting that I would need to address, so I am looking for other possible solutions.

Posted

OK. I would go with a filtered portal for anything that requires a dashboard.

Or, Graham Method it. That is have two "satellite" tables that allow you to view just the closed or active Issues. http://fmforums.com/forum/showpost.php?post/359157/

Posted

thank you - the graham method sounds interesting. I may have to play with that approach.

I will see what I can work up with a portal.

thanks! I really appreciate the advice.

Posted (edited)

In the Graham method, you would be moving the "closed" to an archive table. The "open" would also be in its own table. A common table would have both, and almost all the data. The "open" and "closed" tables would have essentially only the common ID, and their own unique ID.

When moved to the archive table the common ID would be passed to the archive table record, and the "open" record deleted. So the archive would still be linked to the same common table record.

All IDs could be UIDs, for low maintainance, or a mixture of ID types (auto-enter for the common table, which is really the only "real" table.

The relationship to the common table is one-to-one, on the common ID. It is generated and passed to the open/closed tables via an undocument ability of the [x] Allow creation of related records; which can populate an ID in both directions if needed. Though a script trigger could also do it (but no reason to do so).

The advantage is that "open" and "closed" can be shown in 2 different layouts in List view, each with only their own records. Users can Find, etc., without ever seeing the other type of records in that list. They would still need to Show All Records after they'd done a Find and finished looking at them, in order to catch new records.

Users would typically never see the "common" table, except via the common relationship. It would be used for analysis, etc., as it has all the data.

Edited by Guest
Posted

Fenton, since even with Graham, List views can be subject to found sets, the best way to guarantee that the user is seeing the lastest data would be to use a filtered portal.

Posted

Yes, that is true, a filtered portal would be the first approach, unless they really need/want to see a list. If a list is showing all records, then they would see new records. I was not really advocating the Graham method for this, I was just explaining what it would mean, in that case.

The portal could be set up to allow some further filtering, if needed.

  • 2 weeks later...
Posted

I have a simular situation that has time calculations on the layout. I installed a timed script that does a window refresh.

Shawn

Posted

if a user is entering a new issue when this timer kicks on, it pushes back to the layout and the record they were entering is in there as incomplete and they have to go back into it and finish is.

Why can't the triggered script return the user back to whatever they were doing?

This topic is 5247 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.