Why do you need this change?
The Job Task table contains the internal CalledFromHeader Boolean variable, which is used to control whether certain deletion-check logic should be suspended when operations are initiated from the Job Header context.
The table already provides the following procedure
The Job Task table contains the internal CalledFromHeader Boolean variable, which is used to control whether certain deletion-check logic should be suspended when operations are initiated from the Job Header context.
The table already provides the following procedure to set this value:
procedure SuspendDeletionCheck(Suspend: Boolean)
begin
CalledFromHeader := Suspend;
end;This allows standard Business Central code and extensions to set the runtime state of CalledFromHeader.
However, there is currently no corresponding procedure that allows extensions to retrieve the value of CalledFromHeader after it has been set.
This creates a limitation for extensions that need to participate in or extend the standard Job Task deletion logic. In particular, a Table Extension or Codeunit Event Subscriber may need to determine whether the current execution was initiated with deletion checks suspended.
Without a getter procedure, extensions cannot reliably determine the runtime state established by the standard Job Task table logic. The alternative is to maintain a separate state variable in extension code or duplicate/infer the standard logic, neither of which guarantees that the extension remains synchronized with the standard Business Central behavior.
We therefore request a public procedure that returns the current value of CalledFromHeader.
Describe the request
Please add a getter procedure to the Job Task table that returns the current value of the CalledFromHeader variable.
The requested procedure would be:
procedure SuspendDeletionCheck() Suspend: Boolean
begin
Suspend := CalledFromHeader;
end;This would complement the existing setter procedure:
procedure SuspendDeletionCheck(Suspend: Boolean)
begin
CalledFromHeader := Suspend;
end;The existing setter would remain unchanged.
The addition of the parameterless overload would allow extensions to retrieve the current runtime state without exposing or modifying the underlying CalledFromHeader variable.
For example:
if Rec.SuspendDeletionCheck() then begin
// Deletion check has been suspended by the standard logic.
end;This would allow Table Extensions and Codeunit Event Subscribers to determine the state that was established during the current execution of the Job Task record.
The requested procedure does not change any existing Business Central behavior. It only exposes the current value of an already existing runtime variable through a public procedure.
Expected implementation
The implementation can be kept minimal and would simply return the current value of CalledFromHeader:
procedure SuspendDeletionCheck() Suspend: Boolean
begin
Suspend := CalledFromHeader;
end;This procedure would be an overload of the existing SuspendDeletionCheck(Boolean) procedure.
The existing procedure:
procedure SuspendDeletionCheck(Suspend: Boolean)
begin
CalledFromHeader := Suspend;
end;would continue to be used to set the value.
The new parameterless procedure would only retrieve the value and would not modify it.
Why is this required?
The CalledFromHeader variable represents runtime state within the Job Task table.
An extension may need to make a decision in an event subscriber based on whether the standard logic has suspended deletion checks. For example, an extension may subscribe to an event associated with deletion, validation, or related Job Planning Line processing and need to determine whether the operation is being executed in the context where the standard deletion check has been suspended.
Currently, there is no supported way for an extension to obtain this state.
Without the requested getter, an extension would have to use one of the following approaches:
- Maintain its own Boolean variable and attempt to keep it synchronized with the standard code.
- Infer the state from other fields or execution context.
- Duplicate part of the standard Business Central logic that determines when
CalledFromHeader is set.
- Request additional events solely to expose information that is already available internally in the table.
These approaches introduce unnecessary coupling to the current implementation of the standard application.
Providing a getter procedure allows extensions to consume the existing state directly and keeps the extension dependent on the supported public API rather than the internal implementation.
Extensibility considerations
This request follows the existing pattern already established by the SuspendDeletionCheck(Boolean) procedure.
The current procedure provides a mechanism for code to modify the state:
SuspendDeletionCheck(Suspend: Boolean)
The missing complementary operation is the ability to read that state:
SuspendDeletionCheck(): Boolean
Adding the getter would therefore provide a complete API for the state without exposing the underlying variable itself.
This is particularly useful for extensions because CalledFromHeader is an implementation variable and cannot be accessed directly from a Table Extension or external Codeunit.
Alternatives evaluated
The following alternatives were considered:
1. Maintain a separate Boolean variable in the extension
An extension could maintain its own Boolean variable and set it whenever it believes SuspendDeletionCheck(Boolean) has been called.
This is not reliable because the extension would need to reproduce the standard application's execution flow and ensure that its state remains synchronized with Microsoft's implementation.
Any future change to the standard logic could cause the extension's state to become inconsistent with CalledFromHeader.
2. Infer the value from the current execution context
An extension could attempt to determine whether deletion checks are suspended by examining other fields or the calling context.
This would couple the extension to assumptions about the current implementation rather than directly using the state that the standard application has already established.
There is also no guarantee that the same contextual conditions will continue to represent the CalledFromHeader state in future Business Central versions.
3. Add an integration event to expose the value
An event could be introduced to pass CalledFromHeader to subscribers.
However, an event is unnecessary for this requirement because the requested functionality is simply to retrieve an existing state value. A public getter procedure provides a smaller and more direct API and avoids introducing an additional event publisher that extensions would need to subscribe to.
4. Expose CalledFromHeader directly
Making the variable itself accessible would unnecessarily expose an implementation detail.
A getter procedure preserves encapsulation while providing extensions with the information they require.
Justification for the getter procedure
The requested procedure is required because the existing SuspendDeletionCheck(Boolean) procedure provides only the ability to set the runtime state.
An extension that needs to participate in subsequent standard or extension logic has no way to determine what value was set.
The parameterless overload:
procedure SuspendDeletionCheck() Suspend: Boolean
begin
Suspend := CalledFromHeader;
end;provides a read-only access pattern without changing the existing behavior or exposing the underlying variable.
This also avoids introducing an IsHandled pattern or additional event solely for exposing state.
The procedure does not make a decision on behalf of the caller. It simply returns the current value of CalledFromHeader, allowing the consuming extension to make its own decision.
Performance considerations
The requested procedure only reads a Boolean variable and returns its value.
It does not perform database operations, filtering, record traversal, or additional business logic.
The performance impact is therefore negligible.
The procedure would only execute when explicitly called by standard code or an extension.
Data sensitivity review
No external or sensitive data is exposed.
The procedure only returns the value of the existing internal Boolean variable CalledFromHeader.
No record data, customer data, user data, or other sensitive information is exposed by this change.
Multi-extension interaction
There is no multi-extension state-management concern introduced by this change.
The procedure is read-only:
procedure SuspendDeletionCheck() Suspend: Boolean
It does not modify CalledFromHeader and therefore cannot overwrite or interfere with the value established by standard code or another extension.
Multiple extensions can independently call the procedure and receive the current value of CalledFromHeader.
The existing setter procedure remains responsible for changing the state.
Breaking-change considerations
This is an additive change.
No existing procedure, variable, trigger, event, or behavior needs to be changed or removed.
The existing procedure:
procedure SuspendDeletionCheck(Suspend: Boolean)
continues to behave exactly as it does today.
The proposed parameterless overload simply adds a supported way for extensions to read the existing state.
Proposed implementation:
procedure SuspendDeletionCheck() Suspend: Boolean
begin
Suspend := CalledFromHeader;
end;This should be added alongside the existing procedure:
procedure SuspendDeletionCheck(Suspend: Boolean)
begin
CalledFromHeader := Suspend;
end;The two procedures would provide complementary setter/getter functionality for the existing CalledFromHeader runtime state in the Job Task table.
Provide an implementation (optional)
Why do you need this change?
The
Job Tasktable contains the internalCalledFromHeaderBoolean variable, which is used to control whether certain deletion-check logic should be suspended when operations are initiated from the Job Header context.The table already provides the following procedure
The
Job Tasktable contains the internalCalledFromHeaderBoolean variable, which is used to control whether certain deletion-check logic should be suspended when operations are initiated from the Job Header context.The table already provides the following procedure to set this value:
This allows standard Business Central code and extensions to set the runtime state of
CalledFromHeader.However, there is currently no corresponding procedure that allows extensions to retrieve the value of
CalledFromHeaderafter it has been set.This creates a limitation for extensions that need to participate in or extend the standard Job Task deletion logic. In particular, a Table Extension or Codeunit Event Subscriber may need to determine whether the current execution was initiated with deletion checks suspended.
Without a getter procedure, extensions cannot reliably determine the runtime state established by the standard
Job Tasktable logic. The alternative is to maintain a separate state variable in extension code or duplicate/infer the standard logic, neither of which guarantees that the extension remains synchronized with the standard Business Central behavior.We therefore request a public procedure that returns the current value of
CalledFromHeader.Describe the request
Please add a getter procedure to the
Job Tasktable that returns the current value of theCalledFromHeadervariable.The requested procedure would be:
This would complement the existing setter procedure:
The existing setter would remain unchanged.
The addition of the parameterless overload would allow extensions to retrieve the current runtime state without exposing or modifying the underlying
CalledFromHeadervariable.For example:
This would allow Table Extensions and Codeunit Event Subscribers to determine the state that was established during the current execution of the
Job Taskrecord.The requested procedure does not change any existing Business Central behavior. It only exposes the current value of an already existing runtime variable through a public procedure.
Expected implementation
The implementation can be kept minimal and would simply return the current value of
CalledFromHeader:This procedure would be an overload of the existing
SuspendDeletionCheck(Boolean)procedure.The existing procedure:
would continue to be used to set the value.
The new parameterless procedure would only retrieve the value and would not modify it.
Why is this required?
The
CalledFromHeadervariable represents runtime state within theJob Tasktable.An extension may need to make a decision in an event subscriber based on whether the standard logic has suspended deletion checks. For example, an extension may subscribe to an event associated with deletion, validation, or related Job Planning Line processing and need to determine whether the operation is being executed in the context where the standard deletion check has been suspended.
Currently, there is no supported way for an extension to obtain this state.
Without the requested getter, an extension would have to use one of the following approaches:
CalledFromHeaderis set.These approaches introduce unnecessary coupling to the current implementation of the standard application.
Providing a getter procedure allows extensions to consume the existing state directly and keeps the extension dependent on the supported public API rather than the internal implementation.
Extensibility considerations
This request follows the existing pattern already established by the
SuspendDeletionCheck(Boolean)procedure.The current procedure provides a mechanism for code to modify the state:
The missing complementary operation is the ability to read that state:
Adding the getter would therefore provide a complete API for the state without exposing the underlying variable itself.
This is particularly useful for extensions because
CalledFromHeaderis an implementation variable and cannot be accessed directly from a Table Extension or external Codeunit.Alternatives evaluated
The following alternatives were considered:
1. Maintain a separate Boolean variable in the extension
An extension could maintain its own Boolean variable and set it whenever it believes
SuspendDeletionCheck(Boolean)has been called.This is not reliable because the extension would need to reproduce the standard application's execution flow and ensure that its state remains synchronized with Microsoft's implementation.
Any future change to the standard logic could cause the extension's state to become inconsistent with
CalledFromHeader.2. Infer the value from the current execution context
An extension could attempt to determine whether deletion checks are suspended by examining other fields or the calling context.
This would couple the extension to assumptions about the current implementation rather than directly using the state that the standard application has already established.
There is also no guarantee that the same contextual conditions will continue to represent the
CalledFromHeaderstate in future Business Central versions.3. Add an integration event to expose the value
An event could be introduced to pass
CalledFromHeaderto subscribers.However, an event is unnecessary for this requirement because the requested functionality is simply to retrieve an existing state value. A public getter procedure provides a smaller and more direct API and avoids introducing an additional event publisher that extensions would need to subscribe to.
4. Expose
CalledFromHeaderdirectlyMaking the variable itself accessible would unnecessarily expose an implementation detail.
A getter procedure preserves encapsulation while providing extensions with the information they require.
Justification for the getter procedure
The requested procedure is required because the existing
SuspendDeletionCheck(Boolean)procedure provides only the ability to set the runtime state.An extension that needs to participate in subsequent standard or extension logic has no way to determine what value was set.
The parameterless overload:
provides a read-only access pattern without changing the existing behavior or exposing the underlying variable.
This also avoids introducing an
IsHandledpattern or additional event solely for exposing state.The procedure does not make a decision on behalf of the caller. It simply returns the current value of
CalledFromHeader, allowing the consuming extension to make its own decision.Performance considerations
The requested procedure only reads a Boolean variable and returns its value.
It does not perform database operations, filtering, record traversal, or additional business logic.
The performance impact is therefore negligible.
The procedure would only execute when explicitly called by standard code or an extension.
Data sensitivity review
No external or sensitive data is exposed.
The procedure only returns the value of the existing internal Boolean variable
CalledFromHeader.No record data, customer data, user data, or other sensitive information is exposed by this change.
Multi-extension interaction
There is no multi-extension state-management concern introduced by this change.
The procedure is read-only:
It does not modify
CalledFromHeaderand therefore cannot overwrite or interfere with the value established by standard code or another extension.Multiple extensions can independently call the procedure and receive the current value of
CalledFromHeader.The existing setter procedure remains responsible for changing the state.
Breaking-change considerations
This is an additive change.
No existing procedure, variable, trigger, event, or behavior needs to be changed or removed.
The existing procedure:
continues to behave exactly as it does today.
The proposed parameterless overload simply adds a supported way for extensions to read the existing state.
Proposed implementation:
This should be added alongside the existing procedure:
The two procedures would provide complementary setter/getter functionality for the existing
CalledFromHeaderruntime state in theJob Tasktable.Provide an implementation (optional)