Hide records on a per user basis permanently

[Steven Swallow]

I have a little database that the sales people here can access via IWP (it's a FM 12 Advanced database).

 

I have provided a function where they can look at a list of new companies, and assign themselves to those companies. This has the effect of showing that company on their Dashboard.

 

I have also provided the rather useless function of hiding the portal row when they're looking at the list of companies. Useless, because as soon as they revisit the list, anything they've hidden comes back again.

 

I would like to provide a feature where they can click the same 'hide' button, and that company record is permanently hidden from view per user. So Adam hides it, but if Chris or Bob log in, they can still see it...Adam will never see it again.

 

I'm thinking I need some sort of join table with the sales persons UID linking to the companies UID, and a script behind the 'hide' button to do the work, but I'm not quite sure how to get started and implement it...or even whether I can get the 'hide' script to work with the limitations of IWP.

 

Any help much appreciated.

[GisMo]

Sounds like a good case for Many-To-Many relationship. Put the new table between the Company and User with fields JoinID, Company ID, User ID, and a Hide/Show flag field. Maybe just a number 0 and 1(Show/Hide). Your Portal will now be based on the Join Records. Use a Portal Filter Flag=0 or Create the Filter in the relationship graph. 

 

Let us know how it goes.

[Steven Swallow]

Yeah, that's the sort of thing I was trying to get to, but couldn't get get it straight in my mind.

 

I'll give it a whirl and let you know how I get on.

 

Thanks.

[Steven Swallow]

I've got so far and am now stuck again.

 

I must apologise as I made a mistake in my first post where I said "I have also provided the rather useless function of hiding the portal row when they're looking at the list of companies."

 

This is not true. It's not a portal, it's just a list view layout based on table 'table_pri_Companies'. However, most of what you said struck true, so I have created a table as you suggested (shown in the attached image as 'table_join_HiddenCompanies').

 

This is working correctly in that when in the list view, clicking the 'Hide' button runs a script that creates a new record in 'table_join_HiddenCompanies', copying over the Company ID (text_fk_CompanyCode) and the current user name (using Get(AccountName)) into 'text_fk_Username'. It also sets the hidden flag (num_ShowHide) to '1'.

 

I'm now stuck as to how, when opening the company list view, I can filter the records depending on who has logged on. I'm guessing I want a script to run 'OnLayoutEnter', but I'm not sure where to start with writing it, so any help you can provide would be appreciated.

Relationships.tiff

[GisMo]

Gotcha.

This is a common thing. When the rep logs into the database you need to capture their login account with a startup script. Then you can store this in a global field somewhere.

This is my preferred method...Using get(accountname) in the startup script you will get the username. This should be unique and stored in the Rep Table for each rep...I prefer email because it's easy to remember and always unique. You can then get the RepID PK for the AccountName. Get RepID PK put that into a global field of some type of Dashboard Table. ( you need to create this)

Then create a new set of tables...starting with the dashboard, connect the global rep ID PK to the Join Table and connect the rest of the table together. Make a portal in the dashboard layout of the Join table. Now you have a rep dashboard which is context sensitive to the Rep who logged in.

One nice benefit of this is now that you've stored the RepID in a global field, you can use it from any context for making related records and keeping and audit log.

Let me know how it works for you.

[Steven Swallow]

Right...I'll have a play with that.

 

I do already have a Dashboard layout as the individual sales reps log in and then are presented with the 'Home' screen that shows them companies that are assigned to them.

 

The Dashboard layout is actually based on the reps table (table_nrm_Reps), but I'm not grabbing the logged in user on startup as you suggest, just using get(AccountName) on the fly where it's needed.

 

I'll tweak what I've got with what you've suggested and see how I get on.

 

Thanks again.

[eos]

You don't really need a join table; a field in Reps/Staff will do just fine.

 

 

HideCompanies_eos.fmp12.zip

[GisMo]

Right...I'll have a play with that.

 

I do already have a Dashboard layout as the individual sales reps log in and then are presented with the 'Home' screen that shows them companies that are assigned to them.

 

The Dashboard layout is actually based on the reps table (table_nrm_Reps), but I'm not grabbing the logged in user on startup as you suggest, just using get(AccountName) on the fly where it's needed.

 

I'll tweak what I've got with what you've suggested and see how I get on.

 

Thanks again.

Getting the account once will save the extra calls to it later. Long term it makes maintenance and expansion easier as well as more consistent.

[Steven Swallow]

Sorry for the late reply, I've been on holiday.

 

Thanks both for your help. I've gone with GisMo's suggestion(s) as I was 85% there from the start, although I'll be looking at eos's method for other projects.