Hide fields in form with recordref

jpjesus
Member Posts: 45
I know that this topic has been discussed here before and I am almost sure about the answer I'm gonna get. Still....here it goes.
Does anyone know how to replace/change the following code
CurrForm."VAT Registration No.".VISIBLE(NOT VisibleFields(23,FIELDNO("VAT Registration No.")));
into something like
CurrForm.FieldRef.VISIBLE(NOT VisibleFields(RecordRef,FIELDNO(FieldRef)));
The purpose is quite simple:
How to get a user configurable form without having to create severall forms just to hide some fields from some users. Plus, give the Customer the possibility to decide who and when to change these options, instead of having to wait for someone to come in and change or create new forms.
I am sure we all know that maintaining severall forms by user or role is not the best solution.
I create a table were the end-user define by USERID or by ROLEID to which TABLES and FIELDS we want to deny access to the user by hiding or disabling the certain fields on the form.
Although I manage to give a certain amount of control to the end-user to configure certain fields, all must be coded on the form.
So I am looking for a cleaner, easier way to achieve the same result with minor changes to the form. Ence my idea to use of RecordRef and FieldRef to call an outside routine that would return a boolean result, although I'm almost sure it's not possible to do.
Another way I've seen mentioned here is to use a similar approach to the Change Log. Although this might avoid certain users from changing some fields it won't prevent them from seing them and it's contents.
All ideas or suggestions to solve this issue are welcome.
Does anyone know how to replace/change the following code
CurrForm."VAT Registration No.".VISIBLE(NOT VisibleFields(23,FIELDNO("VAT Registration No.")));
into something like
CurrForm.FieldRef.VISIBLE(NOT VisibleFields(RecordRef,FIELDNO(FieldRef)));
The purpose is quite simple:
How to get a user configurable form without having to create severall forms just to hide some fields from some users. Plus, give the Customer the possibility to decide who and when to change these options, instead of having to wait for someone to come in and change or create new forms.
I am sure we all know that maintaining severall forms by user or role is not the best solution.
I create a table were the end-user define by USERID or by ROLEID to which TABLES and FIELDS we want to deny access to the user by hiding or disabling the certain fields on the form.
Although I manage to give a certain amount of control to the end-user to configure certain fields, all must be coded on the form.
So I am looking for a cleaner, easier way to achieve the same result with minor changes to the form. Ence my idea to use of RecordRef and FieldRef to call an outside routine that would return a boolean result, although I'm almost sure it's not possible to do.
Another way I've seen mentioned here is to use a similar approach to the Change Log. Although this might avoid certain users from changing some fields it won't prevent them from seing them and it's contents.
All ideas or suggestions to solve this issue are welcome.
Joao Jesus
jpjesus@netcabo.pt
jpjesus@netcabo.pt
0
Comments
-
I don't think you can use Form controls the way you want. I hope with version 5, navision will be more flexible, and the new visual object type they are creating to replace forms would allow this. For right now you have to write a function and write every control to be visible or not.0
-
Do not expect too much from new version, you can be disappointed. Expect nothing, you will be amazed...0
-
Yeah I agree kine, seeing the difference from 3.x to 4.x, I guess I shouldn't expect anything. Just marketing bs.0
-
OK. Thanks guys. I was hopping that someone might have found a way to achieve this... :whistle:
So far I did it the hard way ](*,) ... coded all fields on each form, commented all fields not present on the form, created a table were the users can define the enabled and/or visible fields and it seems to work. 8)
The major anoyance of this solution is that whenever a field is added to one of the tables and to the form, I'll have to go in and code it.
And there are severall minor anoyances:
1. Either in card or tabular forms, if you place the same field more than once in the form, the enabled/visible properties will only affect the first instance of the field. :-k
2. In tabular forms, it is still possible for the user to unhide the hiden fields. And if they are smart (and they are) they can select all and cut & paste to excel. So it appears that the only way to avoid this is to removed the fields from the form. Hiding them isn't enough. :-k
3. Since this 'security' feature is based on the table fields, all form variables are not available for the users to setup the enabled/visible properties. :-k
Does anyone has a suggestion? :idea: :?:
Like it was said here before, if we are waiting for Microsoft to introduce new features to solve this... well....
Cheers,Joao Jesus
jpjesus@netcabo.pt0 -
Minor anoyances solved:
1. Either in card or tabular forms, if you place the same field more than once in the form, the enabled/visible properties will only affect the first instance of the field. - Easy. I gave diferent names to each control and this way it's easy to manage them.
3. Since this 'security' feature is based on the table fields, all form variables are not available for the users to setup the enabled/visible properties. - For this one I manage to find a work around: Most times these form variables are somewhat connected with other field. So I made it dependent on the property set by the user to the field I connected the variable. :whistle:Joao Jesus
jpjesus@netcabo.pt0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions