enable fields for several users

Roi

hi,

I need to enable some fields in requisition work sheet only for several users.

I wrote following code in the OnOpenform trigger,but it is not working perfectly


IF USERID = 'CHANAKA' THEN
CurrForm.Confirmed.EDITABLE := TRUE
ELSE
CurrForm.Confirmed.EDITABLE := FALSE;

Deep

All what I can judge is that you are trying to Hard code some functionality on the basis of User IDs, which is one of the worst practices in writing code. :thumbsdown:
If you want to make something accessible/editable for some users, make it setup based instead.

Use the user setup table to configure the user access for a specific form/table (using boolean), and write a small function which checks the Login ID with that of your setup, and accordingly does as required.

kriki

Instead of hardcoding a test on the user, it is better to test if the user belongs to a certain role.
Check also this : http://www.mibuso.com/forum/viewtopic.php?t=10695

matttrax

Doing it the way you have coded it will require the customer to come back every time they need someone else to have access / remove access to those fields. The customer should have the option of implementing your modifications for any user in the company.

Simple rule of thumb: If you've hard-coded something then you're probably doing something wrong.

Roi

Hi all,

I agree with u.I'll include another field in the User Setup table and try to restrict through coding.

Thanks
Erandi

Savatage

your not too far off.

Once a boolean has been created in the setup table for REQ work sheet editable.
then you'll just do a get usersetup.get(userID);
before your code
usersetup.get(userID);
IF MYBOOLEAN THEN
CurrForm.Confirmed.EDITABLE := TRUE
ELSE
CurrForm.Confirmed.EDITABLE := FALSE;

kriki

Savatage wrote:

your not too far off.

Once a boolean has been created in the setup table for REQ work sheet editable.
then you'll just do a get usersetup.get(userID);
before your code
usersetup.get(userID);
IF MYBOOLEAN THEN
CurrForm.Confirmed.EDITABLE := TRUE
ELSE
CurrForm.Confirmed.EDITABLE := FALSE;

And for each extra test, you need to add an extra field in the setup....

With my system, you just implement the codeunit for the test. And in each form where you need a test, you just add the code to test. For the rest you can just create a new role (without permissions under it) and add/remove users to it whenever you want.

Deep

kriki wrote:

With my system, you just implement the codeunit for the test. And in each form where you need a test, you just add the code to test. For the rest you can just create a new role (without permissions under it) and add/remove users to it whenever you want.

:thumbsup: :thumbsup: :thumbsup:
Ultimate... =D>

David_Singleton

Sorry to do this, but I disagree with all the suggestions here.

If this is exactly as stated that it certain number of fields for a certain number of users, then just create a new form. On the existing form remove or make non editable the fields that those users will not have access to. The users that need access to more fields will have access to the new form. This is then handled by standard Navision security. And if the client wants to add or hide more fields its simple.

Don't write code unless its needed.

DenSter

David Singleton wrote:

Don't write code unless its needed.

Right you are :thumbsup:
It's becoming a lost art form though :thumbsdown:

Reinhard

David: By default, the ALL role has access to all forms. Do you advocate changing this?

themave

David Singleton wrote:

Sorry to do this, but I disagree with all the suggestions here.

If this is exactly as stated that it certain number of fields for a certain number of users, then just create a new form. On the existing form remove or make non editable the fields that those users will not have access to. The users that need access to more fields will have access to the new form. This is then handled by standard Navision security. And if the client wants to add or hide more fields its simple.

Don't write code unless its needed.

As an end user, this is what we did years ago. I never even thought about hard coding it into the program. I was reading through the answers, and thinking boy you can sure tell they are all programmers, David you are a rare one, who doesn't automatically think, what do I need to code. When I browse the board, so often every solution is code this code that, when in so many cases, it is just a setup issue in Navision. I mean Dynamics NAV, boy do I hate that name.

themave

Reinhard wrote:

David: By default, the ALL role has access to all forms. Do you advocate changing this?

Rather then change that, you can use menu's, we have a set of menus for corporate users that get access to editable forms for many things, and standard forms on menus for the users that arn't editable or specific fields arn't editable. In general you want to make your special forms the editible one, since with navigation you can get to the standard form in many ways. in answer to your question, the all role has execute access to all forms, not read access.

Reinhard

since with navigation you can get to the standard form in many ways.

Good point. We have started controlling access through menus it seems to be a decent solution. Now whenever I set up a new user, besides copying a similar user's roles, I also copy their Menu Restriction as well.
However, I think that for the scenario from this thread, there is no way through *standard* Nav permissions to control which of the two forms a user has access to, assuming they get execute permission to all forms, since both forms have the same source table.

David_Singleton

themave wrote:

David Singleton wrote:

Sorry to do this, but I disagree with all the suggestions here.

If this is exactly as stated that it certain number of fields for a certain number of users, then just create a new form. On the existing form remove or make non editable the fields that those users will not have access to. The users that need access to more fields will have access to the new form. This is then handled by standard Navision security. And if the client wants to add or hide more fields its simple.

Don't write code unless its needed.

As an end user, this is what we did years ago. I never even thought about hard coding it into the program. I was reading through the answers, and thinking boy you can sure tell they are all programmers, David you are a rare one, who doesn't automatically think, what do I need to code. When I browse the board, so often every solution is code this code that, when in so many cases, it is just a setup issue in Navision. I mean Dynamics NAV, boy do I hate that name.

Thank you

gerdhuebner

Reinhard wrote:

However, I think that for the scenario from this thread, there is no way through *standard* Nav permissions to control which of the two forms a user has access to, assuming they get execute permission to all forms, since both forms have the same source table.

May be this could be interesting, too
http://mibuso.com/blogs/massivedynamicsnav/2009/07/

kriki

David Singleton wrote:

Sorry to do this, but I disagree with all the suggestions here.

If this is exactly as stated that it certain number of fields for a certain number of users, then just create a new form. On the existing form remove or make non editable the fields that those users will not have access to. The users that need access to more fields will have access to the new form. This is then handled by standard Navision security. And if the client wants to add or hide more fields its simple.

Don't write code unless its needed.

In general I would agree, but it means you have to maintain 2 forms! In stead of one.
And if the customer wants a new field and you put a new programmer on it (no need to use an expert to do this), he probably will only find 1 form.

My solution is between too-much-code and too-much-forms.

David_Singleton

kriki wrote:

David Singleton wrote:

Sorry to do this, but I disagree with all the suggestions here.

If this is exactly as stated that it certain number of fields for a certain number of users, then just create a new form. On the existing form remove or make non editable the fields that those users will not have access to. The users that need access to more fields will have access to the new form. This is then handled by standard Navision security. And if the client wants to add or hide more fields its simple.

Don't write code unless its needed.

In general I would agree, but it means you have to maintain 2 forms! In stead of one.
And if the customer wants a new field and you put a new programmer on it (no need to use an expert to do this), he probably will only find 1 form.

My solution is between too-much-code and too-much-forms.

There is something seriously wrong when a Navision customer needs to pay for a developer to add a new field to a form. I would always be training the customer to do that them selves.

Alex_Chow

David Singleton wrote:

There is something seriously wrong when a Navision customer needs to pay for a developer to add a new field to a form. I would always be training the customer to do that them selves.

I would agree training is always the best solution.

But the customer would never remember how to do them.

matttrax

That's what documentation is for.

Reinhard

Another problem that I see with having multiple forms as an approach in general in order to restrict the user is that you can link from the card, to the list, which links back to a different card form. To prevent this from happening, you would need to write custom code. Which is what you were trying to avoid doing in the first place...

For the Requisition I guess it doesn't matter since their card/list relationship is a little weird.

idiot

David Singleton wrote:

There is something seriously wrong when a Navision customer needs to pay for a developer to add a new field to a form. I would always be training the customer to do that them selves.

In order for a Customer to be able to add a new field to a form, the field must be a field from the table, not based a computed value, which is what many Customers require.
In order to have a computed field, that field could be a flowfield, which you would need to explain how to create a flowfield or some variable. How much is that Customer paying?

kriki

David Singleton wrote:

kriki wrote:

David Singleton wrote:

Sorry to do this, but I disagree with all the suggestions here.

If this is exactly as stated that it certain number of fields for a certain number of users, then just create a new form. On the existing form remove or make non editable the fields that those users will not have access to. The users that need access to more fields will have access to the new form. This is then handled by standard Navision security. And if the client wants to add or hide more fields its simple.

Don't write code unless its needed.

In general I would agree, but it means you have to maintain 2 forms! In stead of one.
And if the customer wants a new field and you put a new programmer on it (no need to use an expert to do this), he probably will only find 1 form.

My solution is between too-much-code and too-much-forms.

There is something seriously wrong when a Navision customer needs to pay for a developer to add a new field to a form. I would always be training the customer to do that them selves.

1) They need an extra granule for it (and pay for it). But true, if done well, the gain in the end.
2) I prefer they don't do that. I have very bad experience wth it. Even if explained well what they need to do (documentation,send us the objects,...) they don't do it (forget or don't care). And if they mess up something, the blame us and we should fix it without that they pay us.

So best is they don't go in design.

David_Singleton

If the partner sells the Form and Report designers, then that partner has no right what so ever to tell the customer not to use them.

my objective is allways to make the customer as self sufficient as possible, and train them to do it properly. Writing code should allways be the last resort.

DenSter

David Singleton wrote:

If the partner sells the Form and Report designers, then that partner has no right what so ever to tell the customer not to use them.

So true. At the same time, if a customer purchases the designers, and they start modifying objects and code without documenting any of their work (even when they don't do this on purpose, which most of the time is the case), then that customer has no right to blame their partner for screwing up their system.

David_Singleton

DenSter wrote:

So true. At the same time, if a customer purchases the designers, and they start modifying objects and code without documenting any of their work (even when they don't do this on purpose, which most of the time is the case), then that customer has no right to blame their partner for screwing up their system.

But Daniel, you know that both you and I have been in that sales meeting where the sales person said "Sure for $800 bucks each you can buy the designers so you can customize screens and make all the reports you need youself so that you wont be dependant on us for everything.

After that its total BS to go back and tell the client, "um sorry I know we told you to buy these, but we don't want you using them".

gerdhuebner

Without programming, the only possibility is to create (copy) a new req. worksheet form from the existing one (with form designer), remove or disable the unwanted columns and set up one's user rights (execute permissions) on the two forms appropriately. - Though all this can (in principle) be done by an experient end user (provided, form designer is available), this is not the way problems like this are solved in practise, and a consultant should not advise his customer to proceed in this way, for several reasons:
1.) user rights management becomes complex and elaborate to handle (as mentioned above) when one introduces execute permissions on objects
2.) Further form design efforts on req. worksheets will duplicate, because there are now two forms to handle
3.) The method is hardly extendable (consider a third group of users, which should have other columns dis-/enabled)

But even a programmatic solution (via flag in user setup table) is not the best solution, I think.
As this kind of problem is not too rare, may be a general solution is worth while thinking about it. How to make arbitrary fields in arbitrary forms visible/editable for certain user roles? This may eventually give rise to some extension of standard functionality...

DenSter

David Singleton wrote:

After that its total BS to go back and tell the client, "um sorry I know we told you to buy these, but we don't want you using them".

I am agreeing with you that customers should not be limited to what they are allowed to do when they purchase the designer granules. All I am saying is that they should also take responsibility for the modifications that they make with them, and pay for any help they need to solve any problems they may cause. I've been on both ends of that discussion and I can see the point on both sides.

David_Singleton

We are getting way off topic here, but basically Daniel we both agree on both points, i.e. if a partner sells something then they have NO RIGHTS to tell the customer not to use that granule. BUT they have every right to have the customer to agree to pay for any damage they do and to put that in the sales contract.

My experience though is that in the early stages the customer makes a few expensive mistakes, but over the years save a lot by having the skill in house. Its important to remember that if you have a car worth $10,000 your don't pay $11,000 a year for insurance. You buy a new car when you have a crash.

My reason for interjecting in this thread, is that the client seems to have a very simple requirement and every response was to write code. I am not saying that code is not the correct solution. I am saying investigate all options before just hitting Shift+F12.

As consultants its our job to understand the issue, know the future direction the customer needs to head, and based on FACTS give them sound advise.

Writing code should always be the last option after all other options are exhausted.