Notifications
Announcements
No record found.
Hi
I am working on the security . I would live to prevent a user from deleting a journal on the General Ledger journal.
Regards
Tulika
*This post is locked for comments
The easy way is to set allowdelete = false on the datasource property on the form
The best way is to create a new privilege, add LedgerJournalTable to the privilege table node and restrict the delete option. If you do it through customization, you will be forced to update your code each time you want to restrict a new user, while the first option is just a matter of configuration, you add the privilege to the desired users
Doing it via code would prevent all users if no conditions specified. However, security would be the best practice approach.
Remove privilege "Delete journalizing journals" from the role assigned to the user
Use Security Development tool to remove 'delete' rights from GL Journal Form.
1) copy/duplicate original role, which is assigned to user
2) assign duplicated role to user.
3) run SDT and select role which was created at step#1
4) change access level from delete to update using SDT.
Note: modifying original roles is not a good practice.
Hi Tulika,
The steps provided by Sohaib are helping you. Note that on step 4 you can also duplicate duties and privileges to prevent changing standard security artifacts.
You can read in my blog how to do this: www.kaya-consulting.com/.../tips-on-ax-2012-security-development-tool-part-2
Hi Sohaib/Arnaud
The Security Development Tool appear to be a very intertesting tool but I do not have it installed on my site; I am using the AOT to define the security.
I tried
First of all, why would you want to prevent a user from deleting any general journal? What if they're creating a journal, make a mistake, and need to delete it? What's the harm in deleting an un-posted journal that they created?
It seems you probably should care about them deleting the journals of other users, or perhaps deleting posted journals (which understandably AX allows, since the effects of the posted journal are unaffected and the journal is not necessarily required after posting).
Setting the allowDelete() property on the form's datasource is not a great solution. On many forms, this property is set in code based on a change of record, or a change of conditions, or a linked record. Simply changing the form in the AOT does not guarantee that it won't get enabled again once the form is running.
Event privileges are somewhat problematic. It is possible to remove the Delete mode for a form, and for the user to gain delete access to a table in other ways, and still be able to delete records even when at a glance it should appear impossible. There are several good examples of this that are more than a little frustrating and difficult to diagnose. It is, nevertheless, probably the best approach, though you should anticipate a later change to the user's security accidentally granting what you previously meant to take away forever, and how will you notice that?
If you want to guarantee that a record can't be deleted, the single best way is to override the .validateDelete() method or the actual .delete() method on the table itself, checking for conditions you care about, and failing out as desired. This is the most foolproof approach to your issue, since it can't be broken by permissions, can't change over time by accident, and it no longer matters what the form thinks it can let a user do.
@Brandon Wiese
If you want to guarantee that a record can't be deleted, the single best way is to override the .validateDelete() method or the actual .delete() method on the table itself,
okay fine, what If a user knows password of sql server or if a user has access to sql server..??? of course user can delete records from sql server if access is provided.
Similarly if a user has access to AOT, he can play with tables. Otherwise, if user don't have access to SysAdmin, that means setting permission using Roles duties etc. are enough. As machine can never stop a human to do a thing if person has access. Roles and duties are made to stop/allow access. if a user is not provided SysAdmin in AX, there is no way he/she can open AOT. so putting logic at validateDelete/Delete will be just an extra effort.
this is normally needed in case of conditions of business process such as following
If(this.InvoiceStatus == InvoiceStatus::Invoiced)
{
//stop user, so its not deleteable
}
normally to stop human from deleting a record access level/privileges can play enough role. yet if more conditions are needed as said in above example we can go for validateDelete or delete method of Table, i.e. where business conditions are involved.
I'm also not a fan of adding business logic on tables or forms to prevent e.g. deleting records. Then you also need setup which users would be able to delete it or not. When you have more requirements like this, I really would not like to customize this which will also make upgrades more complex. When you do it using security elements you can create new roles, duties and privileges. You can also reuse duties and privileges. New elements are far more easy to upgrade.
You can download the security development tool from the downloadable toold in lifecycle services. You can start exploring the tool on this page: technet.microsoft.com/.../hh859729.aspx
Also read all 6 parts of my blogs related to this tool.
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
As AI tools become more common, we’re introducing a Responsible AI Use…
We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…
These are the community rock stars!
Stay up to date on forum activity by subscribing.
Priya_K 4
Martin Dráb 4 Most Valuable Professional
Ali Zaidi 2
