Hi, Readers.
When you onboard a prospect, you can use Configuration Packages to set up Business Central according to your best practices and their requirements. Apply the relevant configuration packages to an empty company in the customer’s tenant. In brief, Configuration Packages is an alternative method to “Edit in Excel” to upload lots of data into Microsoft Dynamics 365 Business Central. This was called “RapidStart” in the Navision days. More details: Dynamics 365 Business Central: How to Export and Import Data (Using Configuration Packages)
There are two restrictions on import tables when using Configuration Package.
1. For posted tables and entry tables, we cannot insert, modify, or delete them through the Configuration Package. For example, G/L Entry (17)

Sorry, the current permissions prevented the action. (TableData 17 G/L Entry Insert: Base Application)

2. We also cannot import or export system tables through Configuration Package.
For example,
You cannot use system table 2000000006 in the package.

This is a very convenient feature, but if the user does not have some experience using Configuration Package, the existing data may be accidentally overwritten or deleted. For example,
- Can we skip/ignore field validation errors?
- How to bulk delete data on a list page that includes a Card page (For example, bulk delete items on the Item List page)
In order to protect existing data, is it possible to limit the tables that users can import? Yes, but this requires some simple customization. I first tested using Security Filters, more details: Using Security Filters and SecurityFiltering Property.
But table 2000000058 AllObjWithCaption is a system table, which has the InherentPermissions Property set.


InherentPermissions Property: Specifies the permissions that are inherently assigned to the given object.

So even if we set an exclusion in the permission set, that is, the user does not have permission, it will not prevent the user from opening this table.

So we can only do it through customization, there are many ways. I will mainly introduce one that uses a standard event, OnAfterIsSystemTable(TableID: Integer; var Result: Boolean).

A simple example,

Test:

Great. Through this event, you can mark the table that you do not want users to import as a system table and throw a standard error.

Of course, you can create a new table to manage the tables that users are prohibited from importing, or you can add user IDs to control in more detail who can import what tables.
Give it a try!!!😁
Test code:
codeunit 50112 ConfigPackageHandler
{
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Config. Management", OnAfterIsSystemTable, '', false, false)]
local procedure "ConfigManagement_OnAfterIsSystemTable"(TableID: Integer; var Result: Boolean)
begin
if TableID = Database::"Payment Terms" then
Result := true; // Mark "Payment Terms" as a system table
end;
}END
Hope this will help.
Thanks for reading.
ZHU




コメント