Nathan Phillips (CW) 1/27/2011 11:11:27 AM
In workflows, I already control access to buttons and the visibility of records using this method. Control over the visibility of views using this method is the only thing missing.
Kirill Bondar 1/27/2011 11:12:24 AM
Hiding the information is not a good way to control the access. From security perspective you'd better set up **table** access rights for non-reviewers; this way they won't able to see records even if they guess some URLs (direct URL to view the record, for example).
If we suppose this is the proper way to handle this scenario, perhaps we can end up with something like simple checkbox near relationship's Detail View: "Hide section if it has no records and no New action is allowed"?
Nathan Phillips (CW) 1/27/2011 11:29:28 AM
Agreed about the security consideration. When I want the records hidden, I do that at the table access permissions level. I set up a custom rule formula for View access that hides the records. Then the views are still shown and simply empty. In that case, what you're suggesting here would work perfectly. That would definitely be useful to me in some places.
In other places, like reviewing interfaces, I don't really want to hide the records completely. They should still be visible to the user in other places. But users who are not engaged in the review process probably don't need to / shouldn't see the review interface. In those cases, I think what I'd want to do is control visibility of the interface rather than access to the data.
The particular situation I'm thinking of is a data cleanup review. We want the data to stay visible and in-use to the people who are using it throughout the system. And for just the people who are doing the data cleanup, I'd like to also show the details views they use in the cleanup process.
Maybe some sort of "special interface" entry point would work here. ie, users click a button to open a special interface form, and on that form particular details view are shown. Those special interface details views are not shown in the normal interface.
Another possible benefit to formula-control over view visibility would be to allow users to configure the interface for themselves. If I can control visibility of the details views based on a flag on the user's record, I can create flags that the user can go and set or unset themselves. That way they can control what they see and what they don't see to their own preference.
Nathan Phillips (CW) 1/27/2011 11:39:12 AM
>would be to allow users to configure the interface for themselves.
I do this today with notifications, which is why it came to mind. There are a set of notification flags on user records which the user can control themselves. So they're able to choose which notifications they want and which they don't want.
Another possible use for this would be showing and hiding interface based on internal company organization. For example, everyone in the sales department has the Sales role - but there are different groups of sales representatives for different markets. The user's "sales unit" is recorded in the system. With formula control over visibility of the details views, I could show the details views that show the most-relevant data for the user's sales unit, and hide all of the other sales unit's details view.
In fact, I've wanted to do this on views in the view-list in the sidebar. Maybe doing it directly on views would be better than doing it on the relation, because then I could show or hide in the sidebar and on the details views.
Nathan Phillips (CW) 1/27/2011 12:20:30 PM
Maybe I've gotten ahead of myself with the view visibility ideas. The formula wouldn't have access to a particular record, so it couldn't pull properties off the user table. I guess all of those ideas really depend on having configurable user properties that are accessible in formulas.
Philipp Matuschka 1/27/2011 12:23:11 PM
Or session variables .......
Kirill Bondar 1/27/2011 12:34:50 PM
@Nathan: The view "knows" about the parent when executed in a context of master record - we apply the filter by [reference]=[key] in addition to view's standard filter - that's how it displays related records only.
Yet, the same view can be executed separately. So it's definitely not a task for a view.
Our one-many relationship's concept is used in two different usage scenarios (while they are represented by the same database structure):
1. To address a record from a reference table such as list of Countries or Cities - that's fine with current concept.
2. To present master-detail relationship where detail record is in a strict connection to its master - this is the missing piece. In this case we could implicitly do much more, such as derive parent's access restrictions, make details invisible based on parent's condition, etc - as long as we know that parent does definitely exists.
Nathan Phillips (CW) 1/27/2011 12:40:22 PM
>2. To present master-detail relationship where detail record is in a strict connection to its master - this is the missing piece. In this case we could implicitly do much more, such as derive parent's access restrictions, make details invisible based on parent's condition, etc - as long as we know that parent does definitely exists.
This kind of thing sounds perfect. The ability to show or hide a details view based on some condition in the master record would be useful in my applications in several places today.
Scott Miller 6/27/2012 4:40:44 AM
I have found the dynamic element (behaviour) of Forms incredibly useful in terms of managing the layout and only displaying what is required.
It would be incredibly useful to have the same functionality for Views (specifically the Details View within Table Relationships).
Kirill Bondar 6/27/2012 5:11:29 AM
528 - Dynamic Views
Desmond Beatty (Conc) 2/3/2014 5:20:23 AM
Where detail tabs are only used under certain conditions (eg master record type = "xxxxxx"), then do not show the details where conditions do not hold.
Kirill Bondar 2/3/2014 5:27:48 AM
717 - Conditional display of detail tabs.
Gii Systems 2/3/2014 5:49:42 AM
It would also be nice to rename the tab when displayed in details view.
Sometimes we create more than 1 relationship between tables with different match conditions.
Currently it sits as 2 tabs with the same name and the user cannot distinguish between the two.
Slava Shinderov 2/3/2014 5:54:55 AM
Daniel Vazquez Ger 10/3/2014 7:18:07 PM
There many situations where it would be better to hide a specific detail view because you have to show another instead, so the users do not become confused on which one have to use.
Slava Shinderov 10/4/2014 9:04:49 AM
Daniel Vazquez Ger 10/4/2014 3:11:50 PM
Just to have the chance to hide a detail view if it not accomplishs a filter condition.
Slava Shinderov 10/4/2014 3:15:49 PM
767 - Filter the Detail Views
Litwack, Israel (UK) 12/8/2015 10:45:15 AM
Sad to see this did not progress since 2014.
Absolutely, this functionality - conditional control over the display of relationships- would be valuable.
Binding relationship visibility (or even view assignment to the relationships) to the form view would be another way to achieve this... then you can use existing form behavior controls to hide/show the tabs without implementing a similar construct at the relationship level.
Gii Systems 4/28/2016 12:57:20 AM
Hi There - I would love to see this implemented.
1. Conditional display of detail tabs would be very useful.
2. Selecting a different view for the relationship based on role will also be great.
Any update on possible implementation here?
Philipp Matuschka 4/28/2016 3:36:02 AM
Daniel Vazquez Ger 4/29/2016 12:32:20 PM
There are many cases where you have to show / hide detail views or show one view instead others.... I hope you can implement it asap !
Andrew Winters 9/15/2016 1:43:33 PM
Just wondering if you guys are looking into this. Would be very handy to hide the details view based on conditions within the parent record.
Rafael Muñiz 2/14/2017 10:25:35 AM
So many "new" ideas are created every week, but this "old" one was proposed in 2011...
I´ll be happy to know if you have any plans on it.