 | Liquid Rapid 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"?
|
| Liquid Rapid 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.
|
| Liquid Rapid 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.
|
| Liquid Rapid 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 (MMB) 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.
|
| Liquid Rapid 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 Hi All
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).
Thanks
Scott
|
| Kirill Bondar 6/27/2012 5:11:29 AM Merged with:
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 Merged with:
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 Merged with:
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 (MMB) 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.
Thanks!!
|
 | Luison Lassala 4/21/2020 5:54:52 AM The functionality already available to hide/view Fields and Sections on Forms is very powerful.
But it's missing from the display of Detail Tables tabs.
It would be wonderful to be able to display fewer Detailed tabs (Related Tables) for Master records with a specific value on the controlling Field.
Example: I have a table of CENTRES. Some of those Centres are Residential. Others are only for teaching. Others are for both.
I would like to display the CLASSES detail tab only for Centre where field "Centre Type" contains value "Teaching". And only show the detail tab for table RESIDENTS where field "Centre Type" contains "Residential".
Will this be possible in the near future??
|
 | Peter 10/22/2020 12:33:55 PM In our application many possibilities are not dependent on user rights but on parameters resulting from the projects. We work with several "views" right now. The possibility to hide views based on conditions would be great. In our opinion this is an important part between the database functions and a user input masks.
|
 | Aaron Kenter 1/25/2021 3:26:42 PM I think that this would be a very good feature to add.
What I need is the ability to make visible/invisible tabs of related tables based on the value of a particular column in the master table.
|
 | Joseph Kurian 6/29/2021 4:54:44 PM Hide/show the details view based on some formula is good idea, and that will help in my application a lot.
Sometime my parent record do not have any child records then it will display an empty child view which I do not want. I want to hide the child view in that instance.
I hope the TD will introduce this soon.
|
 | Pierre 7/30/2021 4:13:27 AM This feature would help a lot (displaying details tabs based on a condition in the parent record).
|
 | Jacques du Plessis 8/4/2021 9:08:13 AM 1. Conditional display of detail tabs would be very useful. - yes please
|
| Pierre 8/4/2021 10:41:51 AM If too complex to develop, the limited version "do not display if empty" would help.
|
 | Linnette 8/5/2021 6:11:15 AM We really need this, and its been widely requested since 2014, what are the odds of this ever happening?
|
 | Shaun Lamminga 8/5/2021 6:27:57 AM We really need this, and its been widely requested since 2014, what are the odds of this ever happening? - I would love to know too
|
 | Lawrence Bricknell 8/5/2021 6:48:03 AM Or, a method to collapse/expand detail sections, similar to the idea used with sections in the form view.
|
 | reuter 8/8/2021 11:37:36 AM We really need this, any chance we can get it soon?
|
| Joseph Kurian 8/9/2021 8:42:27 AM I really need this feature. Currently I created separate roles to control this. For certain Roles I deny the permission of the child view so that they will not see the child records, for others I allow them to see. But this way of doing things is too complicated and tiresome. Controlling the visibility of child view by using the formula is the right way of doing it. I hope TD will implement this feature soon.
|
 | Johannes Rossouw 8/31/2021 7:39:20 AM This would be very helpful!
|
 | Ashif Asharaph 10/14/2021 3:58:40 AM This would be very useful! Any update on possible implementation of this feature?
|
| Pierre 12/13/2021 7:29:42 AM This would be a useful one - I write a comment to put it back on the top section of the list
|
| Lawrence Bricknell 12/13/2021 8:22:00 AM Patience, Ashif - it has only been on the list for a little over 10 years…
|
 | Bin Xia Zhang 12/17/2021 8:42:25 AM That would be very helpful for my database
|
| Kirill Bondar 2/11/2022 8:39:23 AM Done, detail display is now controlled through form behaviors of master table -- take a look at the bottom of item list.
Blog article and documentation is on the way.
|
| Luison Lassala 2/11/2022 8:45:06 AM Hallelujah!!! That is such a massive addition to Form Behaviour! Thank you Kirill and co
|
| Shaun Lamminga 2/11/2022 9:03:36 AM HUUUUUUGGGGEEEE!!!!
|
| Pierre 2/11/2022 9:15:31 AM I love it - I love it - I love it !!!
Thanks to the TeamDesk team for this
Pierre
|
| Joseph Kurian 2/11/2022 9:59:07 AM Thank you TD for this. I really appreciate this and this will help much in my application even though I have to redo some of the pages..
|
| Pierre 2/11/2022 11:06:47 AM This is a question to Slava or Kirill (or anyone else)
There is a feature request (by me and more) about having a different field selection for:
- the subtable displayed below the form
- the documents
As of yesterday, the fields used in a documents had to be present in the detail table.
Today's GREAT improvement might address this request through one of these two methods:
1)
Declare two relationships through the detail table and the master table with the same reference field.
One of the two relationships would be used for detail display.
The other relationship would not be used for detail display, only for document generation. The detail would be hidden.
2)
Declare two relationships through the detail table and the master table with the two reference fields.
the second reference field would be kept equal to the first one with a default value formula.
Again, one relationship for detail display, the other for document display
Do you see any issue with these methods ?
Kind regards,
Pierre
|
| Slava Shinderov 2/11/2022 11:13:21 AM @Pierre there is no need to create two one-to-many relation for the same reference column or create a second reference column.
Simple create many-to-many relation with corresponding match condition for additional details view you need.
|
| Pierre 2/11/2022 12:27:23 PM @Slava
Thanks a lot for your answer, which are always helpful and quick to come.
I am not sure to understand your answer - I would like to clarify my need as it might necessary.
Let me take an example, with:
a master table : CUSTOMER
a detail table : INVOICE.
This INVOICE table has four fields: description, unitPrice, quantity, totalPrice
In the form view of CUSTOMER, in the INVOICE detail section, I want to show a simple presentation of INVOICEs, with two fields only: description and totalPrice
In a document of CUSTOMER, I want to show a table with all the details of the INVOICEs, say the four fields: description, unitPrice, quantity, totalPrice.
I can't as the fields of used in a document / subtable need to be present in the form subtable.
I am aware of the personalization feature of the detail form, allowing to hide some fields - but it is not convenient for this request as it needs to be set for each user, can be cancelled by chance, and can't be controlled.
Is the many-to-many relation solution you mentioned working with this need ?
Kind regards,
Pierre
|
| Slava Shinderov 2/11/2022 1:14:52 PM |
| Pierre 2/11/2022 2:53:41 PM Hello Slava
Thanks a lot for showing me this article which I had missed.
It addresses my problem. Many-to-Many details can also be hidden with the new feature.
Kind regards,
Pierre
|
