Hide dynamically Currform.Controls

kirkostas

Somebody asked me if I would be able to make a functionality in Navision to hide any control in a Form.

For example, I want to hide some controls in Customer table for some users.
If the user "Mike" opens the Customer form he would not be able to see the Customer's Name.

But I don't want to write it like this:

If USERID := "Mike" Then
  Currform.Controls.Name.VISIBLE := FALSE;

I want to be able to read from another table which field user "Mike" allowed to see, and write this kind of code in the Form:

"User Field Access".SETRANGE("User ID",USERID);
If "User Field Access".FINDSET Then
  REPEAT
    Currform.Controls.("User Field Access".FieldName).VISIBLE := "User Field Access".Visible;
  UNTIL "User Field Access".NEXT = 0;

I really don't expect Navision to handle this kind of code but I have to ask you...and hope it can. :whistle:

Waldo

Sorry dude .. no-can-do (at least not in my knowledge ).

kine

Waldo wrote:

Sorry dude .. no-can-do (at least not in my knowledge ).

Same for me... :-)

You cannot access the controls dynamically without using some external automation...

Xypher

It would be so nice if there was a way to create object indexing in NAV :-#

Slawek_Guzek

Hi,

Indeed there is no collection or table in NAV which hold the list of all control on the form.

But if you think a bit longer it is not so painful. Or - even if it was such a collection it would be not easy, (if not possible at all) to create a fully user-configurable solution, simple because all the controls have their own names, not necessarily following the names of variables or fields. So in virtually almost any case some small developer intervention would be required.

I've did some similar functionality, configurable to some extent. It allowed to hide some field or make the whole form or only single field readonly for some users or some database roles.

The key was to write come small piece of code which could be copied from one form to another and easily modified on the form. Of course more field you need to control the more code you would need, but - on the other hand- do you really need to control all, or most of the controls on all of the forms ? I would say no - you would rather need to control some small number of fields on some forms, which are really important from business or application point of view.

Regards,
Slawek

David_Singleton

Slawek Guzek wrote:

Hi,

Indeed there is no collection or table in NAV which hold the list of all control on the form.

But if you think a bit longer it is not so painful.

You mean like the "Field Level Security" add on from Lanham thats been around for many years now.

idiot

Any idea whether the new version will have this feature?

kine

Do not expect it. But you will have other tools to configure the interface for the user...

Waldo

afaik, the security in the "next" version is the same (same levels) as it is now... .

Slawek_Guzek

David Singleton wrote:

You mean like the "Field Level Security" add on from Lanham thats been around for many years now.

I don't know Lanham, but probably yes.. My solution purpose was to achieve field level security and visibility People (including me) all the time are reinventing the wheels

Regards,
Slawek

Waldo

Look here... .

garak

But they use CurrForm.Control.visible or :?:

Waldo

I assume (and am pretty sure) they do, yes.

Slawek_Guzek

Waldo wrote:

Look here... .

Almost identical concept, indeed

Mine didn't apply filters on data so restricting range of accounts for user was not possible.. But mine allowed to configure visibility for single Users, Database Roles, Windows Groups, included 'default permissions' and allowed to 'allow' or 'deny' view or edit privileges.

Regards,
Slawek

garak

@Waldo: ok, than they do the same like we all and i need no "white paper" ;-)

jlandeen

So Navision doesn't allow you to dynamically access a collection or set of the control objects that are displayed on the form. However I do see another possible way that you could skin this cat.

If you're running on Navision 5.0 you could build a very similar custom form to the original card (say the customer card) that is based on a temporary recordset. Then if you built a control function that handled the displaying of each record you could clear the value through some generic code that runs in the OnAftergetRecord.

"User Field Access".SETRANGE("User ID",USERID); 
"User Field Access".SETRANGE(Visible,FALSE);
If "User Field Access".FINDSET Then 
  recordRef.GetTable(Customer);
  REPEAT 
    lfieldRef := recordRef.field("User Field Access"."Field No.");
    lfieldRef.value := '';
   UNTIL "User Field Access".NEXT = 0; 

If you further need to restrict edits to the table you could handle that in the table directly and have some code that throws an error in the OnModify trigger of the customer table.

Alternatively to all this you could build a seperate form for these users that need a restricted data set and then use permissions and custom menus to control what they access.

I don't think I would hold out much hope that MS will provide access these types for form/display objects in the near future. NAV2009 seems to be based on some similar structures and does not provide a better development environment. Mabye NAV 7.0?

David_Singleton

jlandeen wrote:

So Navision doesn't allow you to dynamically access a collection or set of the control objects that are displayed on the form. However I do see another possible way that you could skin this cat.

If you're running on Navision 5.0 you could build a very similar custom form to the original card (say the customer card) that is based on a temporary recordset. Then if you built a control function that handled the displaying of each record you could clear the value through some generic code that runs in the OnAftergetRecord.

"User Field Access".SETRANGE("User ID",USERID); 
"User Field Access".SETRANGE(Visible,FALSE);
If "User Field Access".FINDSET Then 
  recordRef.GetTable(Customer);
  REPEAT 
    lfieldRef := recordRef.field("User Field Access"."Field No.");
    lfieldRef.value := '';
   UNTIL "User Field Access".NEXT = 0; 

If you further need to restrict edits to the table you could handle that in the table directly and have some code that throws an error in the OnModify trigger of the customer table.

Alternatively to all this you could build a seperate form for these users that need a restricted data set and then use permissions and custom menus to control what they access.

I don't think I would hold out much hope that MS will provide access these types for form/display objects in the near future. NAV2009 seems to be based on some similar structures and does not provide a better development environment. Mabye NAV 7.0?

Which part of "There Is An Add-On Available From Lanham To Do This" was I not clear enough about?

jlandeen

Hey I'm all for people buying add-ons.

But there's nothing wrong if they want to try & develop something on their own. who knows maybe they could come up with a neat new add-on.

David_Singleton

jlandeen wrote:

Hey I'm all for people buying add-ons.

But there's nothing wrong if they want to try & develop something on their own. who knows maybe they could come up with a neat new add-on.

Ah OK, competition is always a good thing. I thought from your post that you felt there was NO solution available. But you are saying that you want to make a better one.

jlandeen

No sorry...i meant that I don't think there is a solution (nor will there be one soon) that allows you to have dynamic programatic access to the screen elements.

Like in .Net there is a control collection for a form that you can loop through to access text boxes, labels, etc. Which is what the original post was hoping to find a way of doing.

I don't think the new Page or Form object in Nav2009 expose this kind of functionality.

vyanku

I am using the following code for one client to hide columns form other user except the director. So we define one roll of director and write the following code. Its working very fine \:D/ \:D/ \:D/

Datatype :- memberof -record -Member OF table

   id:=USERID;
  "User ID":=id;
memberof.SETRANGE(memberof."User ID", id);
   
IF memberof.FIND('-') THEN
REPEAT
IF (memberof."User ID" = id) AND(memberof."Role ID"='DIRECTOR')THEN
user_in_memberof :=id;
UNTIL memberof.NEXT=0 ;

    IF userinmemberof <>id THEN
BEGIN
 CurrForm.FieldNale.VISIBLE:=FALSE;
END

Slawek_Guzek

vyanku wrote:

I am using the following code for one client to hide columns form other user except the director. So we define one roll of director and write the following code. Its working very fine \:D/ \:D/ \:D/

yea... until somebody changes DIRECTOR role name to something else...

Regards,
Slawek

David_Singleton

vyanku wrote:

IF (memberof."User ID" = id) AND(memberof."Role ID"='DIRECTOR')THEN

[-X

Waldo

I agree with " [-X ". Hardcoding stuff is never a good idea.
Better to foresee some setup-fields instead.

ajhvdb

He is sharing a sample code and we're quick to comment on it. O:)

His code is not that bad at all, by using a role and not a userid is almost the same as using a setup field. If he documented this it's ok by me. My 2 cents.

Slawek_Guzek

ajhvdb wrote:

He is sharing a sample code and we're quick to comment on it. O:)

His code is not that bad at all... ...My 2 cents.

His code is an example of bad programming. My 2 cents.

Just a few simple examples:

What happens if somebody create another company in the same database, and create another role called DIRECTOR but for different purposes for example....

What if anybody needs to hide the same fields but for different role name in the same or different company.

What if anybody (company NAV admin not involved in development at all) rename roles.

What if company wants to change structure and adjust roles accordingly.

And probably a few more..

Regards,
Slawek

David_Singleton

ajhvdb wrote:

He is sharing a sample code and we're quick to comment on it. O:)

His code is not that bad at all, by using a role and not a userid is almost the same as using a setup field. If he documented this it's ok by me. My 2 cents.

My personal opinion is that this is very bad practice, and its dangerous that someone sees this code and since its on mibuso accpets it as gospel. Not only do we prevent future readers from making the same mistake, we also help the original poster to correct is practices and be a better programmer going forward.

vyanku

Is there any other solution .....????
What will be the good practice? :-k

garak

to be flexible, its better to use a separate table where you store the permissions for the fields on a form (like the Lanham solution).

Waldo

Just take the Lanham example. That isn't hard-coded... .

ajhvdb wrote:

If he documented this it's ok by me. My 2 cents.

So you document to the user that if they want this functionality, they should name the role "DIRECTOR" (exactly that, and nothing else)... and warn them ... if they use "DIRECTOR", this functionality is triggered... .

Hm :-k no, not for me, thanks ... my two cents.