use two portals to navigate to specific record in third portal

[S Molly T]

I have three portals on one layout.

The top layout contains a list of tasks that a user has received.

The middle portal contains detailed information on ALL tasks a user has received or sent.

The bottom portal contains a list of tasks that a user has sent.

The top and bottom portals contain just a fraction of the task information, like name date and priority. The middle portal contains ALL the task information.

The purpose of this format is to provide the user with a quick and easy way to look at the sent and received tasks and to easily navigate to the desired task to get more detailed information about a specific task.

I would like for the user to be able to click one of the tasks in the top or bottom portal and have the detailed information be displayed in the middle portal.

This works to some degree but since the middle portal contains more records, the portal numbers do not match up with the top and/or bottom portals so the results are inconsistent.

Any help here would be greatly appreciated.

taskplanner.zip

[Ocean West]

OK here is my take -

I removed the center "portal" since for interface when a scrolling portal is ONE row tall its very likely they forget to scroll or scroll at in opportune moment and you loose focus on the task.

What I did is add a field to the users table. Selected Task.

This field is a number field that stores the related Task Record ID, and used as a key field to there relationship

to the task table. when you click on the portal row ( top or bottom ) Since its the same table just filtered differently.

I added a conditional formatted button to each portal that highlight the selected task in either portal.

If there is nothing selected (as is the case in a new record on the users, then there is nothing in the selected task field. I have a conditionally formatted text that overlays the center section.

The reason why the Selected Task Field is a Number and not a global is so that if you scroll thru records in the user table you don't see a task that is not related to the person in which record you are on. And when you go back to that record you are on the same task you had previously chosen.

planner and tasks Copy.fp7.zip

[bruceR]

There is another problem with this file. In the users table, you have a calc:

Field: openTasks

Calculation:

Count ( tasks::departmentID; tasks::taskStatus = "complete" )

This is an invalid calc, only the first part is being evaluated.

I can see what you're trying to do but calcs don't work that way.

[comment]

The reason why the Selected Task Field is a Number and not a global is so that if you scroll thru records in the user table you don't see a task that is not related to the person in which record you are on. And when you go back to that record you are on the same task you had previously chosen.

However, if it's not a global field (or variable) then the selection (a) modifies the record and ( applies to all users (I mean users that are logged in at the same time, not user records in the Users table).

Since OP is obviously using version 11, they can take advantage of:

http://fmforums.com/...-selected-child

[S Molly T]

OK here is my take -

Wow, very cool...thanks for the help.

What I did is add a field to the users table, Selected Task.

This field is a number field that stores the related Task Record ID, and used as a key field to their relationship

to the task table.

Hate to admit but I had no idea that relationships worked in this manner which is probably like very beginner type of stuff. It took me a while but I finally figured out that by typing (or placing) the recID of the related task in the Selected Task field that the corresponding record would show up. I think I understand WHAT is happening but not sure HOW it is happening.

There is another problem with this file. In the users table, you have a calc:

Field: openTasks

Calculation:

Count ( tasks::departmentID; tasks::taskStatus = "complete" )

This is an invalid calc, only the first part is being evaluated.

I can see what you're trying to do but calcs don't work that way.

Would like to have something like a CountIf function. Seems like I've done something like this before just have to remember how I did it before.

However, if it's not a global field (or variable) then the selection (a) modifies the record and ( b ) applies to all users (I mean users that are logged in at the same time, not user records in the Users table).

Since OP is obviously using version 11, they can take advantage of:

http://fmforums.com/...-selected-child

I looked at this solution before I made the initial post but I'm not advanced enough to understand it and the advantages of using that method or the disadvantages of the method posted by Ocean West.

a.) what is the harm in the record being modified?

b.) only one logged in user should be accessing their own records (corresponding to their record in the User table) at any given time.

I don't know it may be bad design but I was planning on using the Users table as an access control list and use it to control access to records and fields. Each user (in the user table) should only be able to view/edit the task records created by them and tasks created for them.

Sorry if I'm a little daft when it comes to some of this stuff, but I really do appreciate all the help from everyone...thank you all for your time.

[Ocean West]

Taking into consideration your user model and that only one user editing that record I see no harm in modifying a that record of their current selection of a task.

Would like to have something like a CountIf function. Seems like I've done something like this before just have to remember how I did it before.

In your task table create two new calculation fields.

isComplete

taskStatus = "complete"



isOpen

taskStatus ≠ "complete"

Then back in the users table you can use the logic:

OpenTasks

Sum ( tasks::isOpen )





CompleteTasks

Sum ( tasks::isComplete )



TotalTasks

OpenTasks + CompleteTasks

I am not sure I understand the difference between Task and Request - and since you only have one relationship but the portals are "filtered" any logic applied to the calculation ignores the portal filter.

[S Molly T]

Thanks very much once again for your help. I do appreciate your time.

In your task table create two new calculation fields.

isComplete

taskStatus = "complete"



isOpen

taskStatus ≠ "complete"

Don't know if it is necessary or not but I did something a little different to account for an empty taskStatus.

I am not sure I understand the difference between Task and Request - and since you only have one relationship but the portals are "filtered" any logic applied to the calculation ignores the portal filter.

There is no difference...a task and a request are the same thing. The distinction is SENT or RECEIVED tasks and that is the reason for two different portals, to show SENT and RECEIVED tasks.

isComplete

Case (

IsEmpty ( taskStatus ); 0;

taskStatus = "complete"; 1;

0)



isOpen

Case (

IsEmpty ( taskStatus ); 1;

taskStatus = "complete"; 0;

1)

[Ocean West]

Here is another sample - using separate relationships for each portal. And not using Flittered Portals.

planner.zip