Formatting repair

This commit is contained in:
Jeremy Vyska 2021-10-30 23:55:19 +02:00
parent 89ac40c868
commit 26452d5f7c
20 changed files with 134 additions and 179 deletions

View file

@ -1,8 +1,8 @@
+++
title = "Blocked Entity.md"
title = "Blocked Entity"
weight = 270
+++
_by Abhishek Ghosh at Microsoft Development Center Copenhagen_
_Originally by Abhishek Ghosh at Microsoft Development Center Copenhagen_
## Abstract
@ -14,7 +14,7 @@ The Blocked Entity is used when it is required to stop transactions for an entit
To block entities through metadata, read this pattern. To do the same thing through data, read [Data Driven Blocked Entity pattern][anchor1].
The business entity holds a state that controls if a given transaction is allowed. The state is used by the logic controlling transactions.****The change of state could either be temporary or permanent.
The business entity holds a state that controls if a given transaction is allowed. The state is used by the logic controlling transactions. The change of state could either be temporary or permanent.
An example of a temporary halt is when a retail chain selling items has received lot of complaints about an item, and the company wants to stop all transactions, both purchase and sale, with that item until the dealer has clarified the issue with his supplier and possibly received a replacement for the defective stock. Another common example is during counting the physical inventory using cycle counting where the counting is done in one section of a warehouse at a time, so that the regular operations can continue in the other parts of the warehouse. In these situations, it is necessary to block all transactions, such as picks and put-aways, for a bin while warehouse counting is in progress for that bin.
@ -34,7 +34,9 @@ Add a Boolean field named Blocked in the table.
In the relevant logic, add a condition to check the status of the Blocked flag. The cheapest way is to use a TESTFIELD:
_<rec variable\>.TESTFIELD(Blocked,FALSE);_
```AL
<rec variable\>.TESTFIELD(Blocked,FALSE);
```
Alternatively, you can throw a custom error message. However, you should only do that if the default error message thrown by TESTFIELD is not sufficient.
@ -62,9 +64,10 @@ An example of the Boolean implementation on the Item card.
In codeunit 22 -- Item Jnl.-Post Line, the following lines of code have implemented a check based on the value of the Blocked field:
IF NOT CalledFromAdjustment THEN
```AL
IF NOT CalledFromAdjustment THEN
Item.TESTFIELD(Blocked,FALSE);
```
### Option-Field Implementation
[![ ][image2]][anchor3]

View file

@ -4,12 +4,10 @@ weight = 470
+++
_Written by Bogdan Andrei Sturzoiu, at Microsoft Development Center Copenhagen_
******Abstract**
**Abstract**
This pattern implements a generic mechanism for dynamically restricting and allowing usage of a record by the business process administrator.
[![ ][image0]][anchor0]
**Problem**
A NAV record can be used in a number of functionalities across the app. There are situations, however, when the administrator wants to restrict the consumption of such a record, as well as lift the restriction when it is no longer relevant.
@ -42,7 +40,9 @@ Currently, the restrictions are record-based and type-less. They act as simple t
You must make sure to differentiate between the reason and the purpose. That is because the restriction can only be added once per record, but consumed in multiple places.
******Example**
****
**Example**
For example, we want to restrict posting Gen. Journal Lines if a customer has not been added in Account No. field.
@ -66,34 +66,37 @@ The code behind the "Add record restriction" workflow response:
The code behind the "Remove record restriction" response:
RecRef.GETTABLE(Variant);
CASE RecRef.NUMBER OF
```AL
RecRef.GETTABLE(Variant);
CASE RecRef.NUMBER OF
DATABASE::"Approval Entry":
BEGIN
RecordRestrictionMgt.AllowRecordUsage(RecRef.RECORDID);
RecRef.SETTABLE(ApprovalEntry);
RecRef.GET(ApprovalEntry."Record ID to Approve");
AllowRecordUsage(RecRef);
END;
BEGIN
RecordRestrictionMgt.AllowRecordUsage(RecRef.RECORDID);
RecRef.SETTABLE(ApprovalEntry);
RecRef.GET(ApprovalEntry."Record ID to Approve");
AllowRecordUsage(RecRef);
END;
DATABASE::"Gen. Journal Batch":
BEGIN
RecRef.SETTABLE(GenJournalBatch);
RecordRestrictionMgt.AllowGenJournalBatchUsage(GenJournalBatch);
END
BEGIN
RecRef.SETTABLE(GenJournalBatch);
RecordRestrictionMgt.AllowGenJournalBatchUsage(GenJournalBatch);
END
ELSE
RecordRestrictionMgt.AllowRecordUsage(RecRef.RECORDID);
END;
RecordRestrictionMgt.AllowRecordUsage(RecRef.RECORDID);
END;
```
Notice****how lifting a restriction for a Gen. Journal Batch involves lifting all the restrictions for the individual journal lines in the batch (hence the special branching of the code).
Notice how lifting a restriction for a Gen. Journal Batch involves lifting all the restrictions for the individual journal lines in the batch (hence the special branching of the code).
******Consequences**
****
**Consequences**
Currently, there can only be one restriction per record. There are no restriction types.
In the future, a type field should be added to the restriction table, to allow adding restrictions for different purposes, and to refine their consumption. For example, a posting restriction might only be enforced for restrictions originating from approvals.
**NAV** **Versions**
**NAV Versions**
This pattern has been introduced in Dynamics NAV 2016\.