Jump to content

Multiple Portals/Fields?

the Otter

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

Recommended Posts

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


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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