I have form20 with Properties:
- “Source table” = G/L Entry
- “ModifyAllowed” = Yes
The problem is that I have created another field on table G/L Entry but when I try to modify it from form20 an error is displayed (“You can’t change…”), in spite of “ModifyAllowed” property is set to Yes.
On the other hand I use the property Permission, include table 17 with read and modify permission checked and it allows me to change the new field. Why must I define Permission property (I have never used it) if ModifyAllowed is defined?
G/L entry… isn’t it a restricted table?
do you have granule 7300 (solution developer) ?
G/L Entry is a protected table that cannot be changed using a customer licence, unless they have the development granule. To allow user to change it you have to:
give the permissions to the object (in your case the form, it should be better a codeunit, take a look at cu 103 and 113) that modify the table
Set the Modify Permission to Indirect for the user using that form
Yes, it’s a restricted table and No, I don’t have granule 7300.
Anyway, I created the field “Checked” (boolean, just for Financial department affairs) and I used Permission property on form20 with development license. As I said it works good with our partner license.
The question was about the difference between InsertAllowed, ModifyAllowed and DeleteAllowed of the form and the Insert, Modify, Delete of the Permissions property, what’s the difference between them?
The InsertAllowed, ModifyAllowed and DeleteAllowed are property of the form. For example a list lookup on sales order is just for lookup, so it makes sense that it shouldn’t be editable. I strongly suggest not to add the permission the form. Create a codeunit instead and onmodify trigger on the form call you codeunit to modify the field and only that field. Add permission to the codeunit for the GL entry table. The problem being on the form is that the user can modify other fields, and the user cannot add additional fields to the form, because they wouldn’t be able to compile the object.
Thanks for your notes Rashed but I can’t create codeunits with our license… ooohhhh !!. Anyway, users can’t change another fields because I set all fields property Editable to No, I think it’s enough.
Oohh BIG MISTAKE !!.
I don’t know what the f*** I tested but It doesn’t work, it allows me to change the field wanted but when I go back to the record… surprise, the new value was not saved !!.
I have granule 7300 on my license and I defined Permissions form property to modify Cust. Ledger Entry but it doesn’t. Can somebody help me please?
Place code inside codeunit 103 - Cust. Entry-Edit.
Great, Nuno. Thanks [:D]
Anyway I don’t understand why it works with the codeunit and not with the form, having the same Permissions property values
Ledger entries aren’t supposed to be editable by customers since they are protected. Permissions in ledger entries aren’t 100% effective because they can have hidden protections. For example you can only edit directly G/L Entries if you have granule 7300.
To overcome that restriction in customer side has added codeunits with permissions to edit ledger entries.
I hope I could explain myself.
You explained perfectly. What I can’t understand is why NAV doesn’t show this “hidden” restrictions to developers.
If restrictions on a few tables (G/L Entry, etc…) could be solved with license affairs, like granule 7300, I would understand it, but I do have this granule, so I can’t understand why being the NAV Admin I can’t allow any form to modify this table. Thanks at the lord you have the answer jajjaja
Thank you Nuno