Security Matrix AX 2012 :
Jangan lupa EffectiveAccessnya Ganti Delete
By following these steps you can restrict access to the button control on the form.
So taking this to heart, and running with it, lets say you have a request to hide a form control, based on some context. Lets pick a functional one, in that we don't want users, who have read only access to a form, to see a specific form control.
In the past, real simple steps could be taking to do this, and a popular way of handling such a request, would be to (a) Make sure the control had AutoDeclaration set to yes, and (b) override the init() method of the form, and work with the forms .visible() property. This would be based on either, say the company, or a security key in the pre-AX 2012 days.
This however has changed with AX 2012, and we can achieve this need, without any code actually. How you may ask? Well check out the following Microsoft resource: Security Permissions Properties for a Form [AX 2012]
So lets explain this a little bit then, shall we? To start, we have a need Permissions node that lives under the form objects now.
With this, we see, as mentioned in the above resource, the Read, Update, Create and Delete Permission nodes. Each of this are in order of weakest to strongest security. In that, if a user has a privilege that enables them to have Read access to the form, and then control had the needed permission of Update, the user Would not see the control on the form. Since this is the desired scope, then we understand how we can relate privilege's to NeededPermission.
When looking under these nodes, you would not drag or drop controls under each. Nor do you create new elements, under the Controls node. If, we want to take a control, and have it's NeededPermission to be set as Update, then we must go to that Control, open the properties, and set the NeededPermission value as so.
On saving of this property change, we can now see that under the Update node of the Forms Permissions, contained within the Controls section, we see now our 'Control2' has appeared.
Now through proper security setup, when users only have Read level permissions to our form, they will not see the Control2, form control. So we have used security modeling aspects of AX 2012, and not code, to enable the visibility of a control on a form. Pretty powerful huh?
Well that's all for this post, I hope this helps someone out. Keep checking back as we continue to dive more and more into AX 2012.
Jangan lupa EffectiveAccessnya Ganti Delete
By following these steps you can restrict access to the button control on the form.
1.
In the AOT, highlight the
button control node at Forms > YourForm > Designs > Design > YourButton.
2.
In the Properties
window for your button control, set the NeededPermission
property to Manual.
This enables you to drag the button node in the next step.
This enables you to drag the button node in the next step.
3.
Under the AOT node Forms > YourForm > Permissions > Read > Controls, add YourButton
control. Do this by dragging the button node to this Controls
node.
4.
In the Properties
window for the new permission for YourButton
control, set the EffectiveAccess property to Read.
With Microsoft Dynamics AX 2012, the whole concept of Model more and code less is in full affect. The idea behind
modeling, is that you cut down on the need to create custom code, to achieve
needs. This is a great overall concept, and we are seeing this in Workflows, and well as Security.
So taking this to heart, and running with it, lets say you have a request to hide a form control, based on some context. Lets pick a functional one, in that we don't want users, who have read only access to a form, to see a specific form control.
In the past, real simple steps could be taking to do this, and a popular way of handling such a request, would be to (a) Make sure the control had AutoDeclaration set to yes, and (b) override the init() method of the form, and work with the forms .visible() property. This would be based on either, say the company, or a security key in the pre-AX 2012 days.
This however has changed with AX 2012, and we can achieve this need, without any code actually. How you may ask? Well check out the following Microsoft resource: Security Permissions Properties for a Form [AX 2012]
"To see a particular control on a form, the user must have a
permission to the control that is at least as strong as the permission the
control requires.
For example, suppose a control has its NeededPermission property set to Update. A user who has only Read permission does not see the control on the form. But the control is visible to another user who has Update or Delete permission to the control."
For example, suppose a control has its NeededPermission property set to Update. A user who has only Read permission does not see the control on the form. But the control is visible to another user who has Update or Delete permission to the control."
So lets explain this a little bit then, shall we? To start, we have a need Permissions node that lives under the form objects now.
With this, we see, as mentioned in the above resource, the Read, Update, Create and Delete Permission nodes. Each of this are in order of weakest to strongest security. In that, if a user has a privilege that enables them to have Read access to the form, and then control had the needed permission of Update, the user Would not see the control on the form. Since this is the desired scope, then we understand how we can relate privilege's to NeededPermission.
When looking under these nodes, you would not drag or drop controls under each. Nor do you create new elements, under the Controls node. If, we want to take a control, and have it's NeededPermission to be set as Update, then we must go to that Control, open the properties, and set the NeededPermission value as so.
On saving of this property change, we can now see that under the Update node of the Forms Permissions, contained within the Controls section, we see now our 'Control2' has appeared.
Now through proper security setup, when users only have Read level permissions to our form, they will not see the Control2, form control. So we have used security modeling aspects of AX 2012, and not code, to enable the visibility of a control on a form. Pretty powerful huh?
Well that's all for this post, I hope this helps someone out. Keep checking back as we continue to dive more and more into AX 2012.
Cara Hide Button menggunakan Security
Matrix AX 2012
Misal Saya ingin menghilangkan button NEW
Pada form klik kanan > Personalize
Di atas tidak terdapat MenuItem, karena itu
kita harus membuat menuitem (display) dari form PurchEditLines. Sebelum mendrag
menjadi menu item pada form dicustomize di permission nya seperti gambar di
bawah ini
Jangan lupa ganti
NeededPermission menjadi Manual.
Kemudian drag and drop Button ke dalam
Controls di Permisson Read (kenapa dipilih Read karena saya tidak ingin
terlihat), Jika Update maka permission untuk bisa memperbaharui atau tidak,
Jika Create maka permission untuk bisa
membuat atau tidak, jika Delete untuk bisa menghapus atau tidak.
Drag and Drop Form PurchEditLines ke
Display, sehingga terbentuk menuitem baru.
Jika sudah menjadi menu item, drag menu
item yang baru tadi ke Entry Points Privileges. Dari privileges pilih Gambar
Gembok drag ke Privileges Gambar Gembok dari Security Duties, Dari Security Duties pilih gambar Centang
lalu drag ke Duties dari ProcessCycle (secara otomatis nanti akan muncul
ProcessCycle di security Privileges.
Pilih Security Role untuk membuat Role baru
Pilih Add
Pilih ProcessCycleBITPurchEditLines
Pilih Usernya siapa yang harus diberi
security matrix.
Test menggunakan user lain
Hasilnya button sudah tidak terlihat.
Cara Ke-2 dengan Fungsi yang terdapat di
Security Role, yaitu “Override Permission” (Digunakan hanya untuk menghide field atau form,
tidak bisa hide button)
Pilih Override Permission, misal ingin hide
harga yaitu purchprice, maka ketikkan purchprice,
jadi semua purchprice akan hide. Namun jika sudah pernah di override maka tidak bisa di override
lagi.
CARA KETIGA
Cara membuat
security Matrix :
1.
Buat
Group, terdiri dari Security Privilege, Security Duties, Security ProcessCycles
|
CARA ke 4
Buka form yang ingin ditampilkan di
security role
Klik Kanan personalize
Klik Edit
Buat Menu Item Display
Buat Security Matrix
Dan Masukkan Menu Item Display ke dalam
Entry Points dari Security Role yang telah dibuat
Klik kanan pada Entry Points dan berikan
AccessLevel = Delete (artinya full control)
Kembali ke Sys Admin, buka Security Roles
Masukkan BIT_MasterProject ke dalam role
Purchasing Agent, caranya sepertin dibawah ini :
Klik Add
Pilih View by Duty / privilege
Hapus sort by Duty dan pilih Privileges
yang telah dibuat yaitu BIT_MasterProject
Close
Silahkan coba menggunakan user tersebut
==== CARA buat security hanya yang report
saja & tidak bisa edit atau tambah form ====
Buat project
Pilih Filter
Pilih Select
Filter / Criteria : inquire, *Review
SecurityDuty
Copy semua Duties ke dalam roles
0 comments:
Post a Comment