I

Do they need to view only - or also edit these fields?

If you wish to display records only created by each AccountName, just include that in your key as:

YourRegularKey = YourRegularKey

AND

Get (AccountName) = Related::AccountName

Or create a new TO for it. But changing the fields which display in a portal is a bit trickier if they need to be able to change the values in those fields.

How will you determine which fields will be shown for which AccountName? Is it by their Group? If they don't need to change the data, you can display a concatenated Case() calculation of the fields dependent upon the AccountName.

I think the only easy way to do this is have 5 different layouts, each with the correct fields, then control navigation to the layouts using Get(AccountName).

Hopefully you don't have a lot of layouts that require this. There is a way, via a "visibility" trick, only show fields for an account name (inside a portal only valid for an account name, or group of account names). But it requires space on the layout for ALL the possible fields; not ideal.

If you have several users sharing the same privileges, then perhaps you should consider showing fields (navigating layouts in my method) based on Get(PriviledgeSetName) instead.

Another method which works, for layout navigation, is to have a field in a central "Staff" table/file, which holds the field or layout "type" for each account. You assign types to accounts (multiple types in a return-delimited list). You can read their type(s) from other tables/files using a relationship with Get(AccountName) in a calculation field on the left to a regular field with it in Staff.

The advantage (or disadvantage :-) of this method is that it can be user-configurable. You can assign several users to the same set, arbitrarily. It does expose the account names in the database file, if that's a big security concern.

Moonshadow,

Yeah, they need to be able to edit them. Each person needs to be able to add

Hmmm, if all they need to set are three fields, you could capture the portal row they select, display Custom Dialog and let them input the three dates into global dates and use script to set the fields for them.

In oldies days, you'd use GetField( ) to dynamically display either the field selected labels and its contents.

As for editing, yes, I'd guess CustomDialog would be helpful.

You may also have a combination of both GetField( ) calcs and classic related fields in a same portal if those selections you listed (Date In, Date Out and Date Expected) would be necessary for inputs independantly of the User account, but you'd like the other fields in portal to display "custom" values...