I have an app that uses portals for navigation. If two users are in different records and the user saves a record then the second user gets an error message while saving "related records have been modified" and the second user's changes are not saved. What am I missing?

You are missing nothing - this is correct behaviour.

Although your users are editing a portal row, it is the parent record that is also considered to be being modified too because relationships are bi-directional.

Maybe a technique to avoid this is to do a GTRR with a new virtual window - this way you won't end up editing the record via a related situation.

You could also consider scripting the edit routine and try to lock the record using Open Record and test the error result to determine what to do next.

None of this is perfect, but it's the way IWP works.

My implementations is a bit different. I setup a session table that has a foreign key relationship used to display a filtered portal. The contents of the filtered portal contain fields as "buttons" that when clicked a primary key value is posted back to the session table which has another relationship set to another instance of the same table but this relationship is set on the primary key for editing.

Session

fk -> a bunch of records

pk -> the specifc record to edit

The problem is that if any of the values are updated that are displayed in the portal, the second user can't save the record they are editing, even if it is a totally different record.

Is there a way to turn the message off and save the changes like the behavior in CWP and FMP?

Don't quite understand what you are doing here, but you cannot deny that the record(s) is/are locked.

When suing FMP client the lock may be so quick that the problem is not revealed. Web clients keep the records open much longer.

Are you missing a Commit Records script step here?

On Saving a Record the programs does:

Commit

Go To Field

Open Record Request

I attached a screen shot that might clarify what I am trying to do. A quick summary of the important fields and tables. Note that "Crew Portal" and "Crew Edit" are the same table but two different intances related back to Session.

Session Crew Portal Crew Edit

fk_Tour --->> fk_Tour

pk_Crew --------------------> pk_Crew

1) Click the portal row and it posts

Crew Portal::pk to Session:pk_Crew

2) Session::pk_Crew value then sets a one-to-one relationship in Crew Edit so that one record is edited.

The crazy thing is that if I edit any field other than those displayed in the Portal, things work ok. In this case, as long as I leave Tour id, First Name & Last Name alone or don't add any records then things work fine.