Core 2.0.704

No breaking changes.

Differentiating between orders in SearchOrders​

The service SearchOrders now holds the property HasSoldToOrganizationUnit to let you filter between orders from OUs to customers and OUs to OUs, essentially displaying either sales or purchase orders. When it's set to true, you would display POs, Interbranch and Returns to supplier orders.

As a reminder, it's already possible to search for orders of specific types by specifying its enum values in the service's Properties field.

for example: "Properties":[4, 4096] which will produce both IsInterbranch and IsTransferOrder orders.

UnitPriceOverride indications​

In case of a unit price override by an employee, an order ledger item of type UnitPriceOverride will now be created and made visible in an order's History tab in Admin Suite - just as for a unit price correction.

Deleting price lists​

We've created the service DeletePriceList to allow for proper archiving of price lists. Corresponding front-end functionality is incoming and will be usable by users with the Delete scope in the Pricing permission.

EventExports extension point​

We've made a few additions to the EventExports extension point.

The Orders object now supports the following properties:

• IsReturnToSupplier
• SoldToOrganizationUnit - this lets you determine if an order is interbranch or not
• HasSoldToOrganizationUnit

Custom field security and eligibility​

When it comes to custom fields, EVA differentiates between security and eligibility. In short, security is what guides interacting with custom fields from the perspective of a logged in user (read: employee), while eligibility does the same thing but from (for example) a customer's perspective.

Aside from the currently available basic security configuration in Custom field settings, it's also already possible to extend the security aspect by means of the CustomFieldSecurity extension point.

Now as for what's new: we're introducing a bunch of extension points that will let you customize custom field eligibility. In practice this means you will be able to indicate when custom fields should be required, visible and/or editable based on variables such as a CountryID, ShippedFromOU or PaidAmount. You'll be able to script it any way you want with its corresponding extension point.

For an overview of the various new eligibility extension points, check out our Extension points docs.

One more thing: when creating and updating custom fields, any errors will now clearly display what exactly is wrong or missing, e.g. "CustomField xx is required" or "You are not allowed to edit CustomField 123".

Changes to how we return custom field data​

GetCustomFields now returns an additional property CustomFieldOptions with the following structure. This service is best used for getting custom field settings.

{
 [CustomFieldID]: {
    IsRequired: true, // nullable
    MinimumValue: 1, // nullable
    MaximumValue: 100, // nullable
    MinimumLength: 3, // nullable
    MaximumLength: 256, // nullable
    MinimumDate: "2023-08-24", // nullable
    MaximumDate: "2023-08-24", // nullable
    DefaultCustomFieldValue: [CustomFieldValueObject], // nullable,
    IsEditable: false
  }
}

The ExtendedCustomFields custom fields in GetApplicationConfiguration have been adjusted to the following structure.

{
 [CustomFieldID]: {
    IsRequired: true, // nullable
    MinimumValue: 1, // nullable
    MaximumValue: 100, // nullable
    MinimumLength: 3, // nullable
    MaximumLength: 256, // nullable
    MinimumDate: "2023-08-24", // nullable
    MaximumDate: "2023-08-24", // nullable
    DefaultCustomFieldValue: [CustomFieldValueObject], // nullable,
    IsEditable: false
  }
}

Everything else that was not metadata that was available is still available, so this is not a breaking change. However, using them moving forward is highly discouraged. Consider them deprecated.

There is also a new service GetCustomFieldMetadata that gives back the same structure as in the example above, as a lighter alternative which doesn't come with other contextual properties and everything else from GetApplicationConfiguration.

Changing users to SSO only​

We've added a new service called SetUserToSingleSignOnOnly to convert users to be allowed access via the single sign-on flow only. This service requires the functionality ChangeUserLoginType and accepts an ID (UserID).

Other additions​

• Expose MinimumLoyaltyPointsRequired in discount prefigure result.
• Added CreatedByID and CreatedByFullName in ListCashTransactionLedgerItem.
• Added ApplyTo property to the response of PrefigureDiscounts.

Subtypes in GetUserTaskTypes​

The GetUserTaskTypes service now allows you to optionally IncludeSubTypes, making it clearer what the task consists of. A Ship from Store type task for example will then include its Pick, Pack, Ship, Deliver (and possibly) Print task.

Updates to users in visibility groups​

We've made a small, but impactful change to how EVA deals with updates to employees' user information when they have multiple accounts (sharing an email address) across visibility groups:

• If an employee edits its own user, these changes will be reflected across all their accounts
• If an employee edits another user, these changes will be contained to that specific user instance

CaptureMoment in PushSalesOrder​

We've added the CaptureMoment property to PushSalesOrder allowing for better integration with Clientella.

Other improvements​

• EVA now takes visibility groups into account when fetching OrganizationUnits/Functionalities.

• Filter the roles on the ClientPrincipal on the requested UserType.
• Pass the usertype as override into the authenticator to limit the roles.
• Authentication data handling for LiveGuard.
• Multi-Currency Transfer Orders.
• Prevent stack overflow on splitting order line with product requirement.
• Prevent "truncation error" from db when creating a role.
• Handle product availability for configurable product with 1 child.
• Validate cron in a consistent way.
• Reduce size of message published to Kafka.

  max message size defaults to 1 MB, reducing number of product IDs to 10000 would leave 100 bytes per product ID in the message, which should be plenty

• Fetch the last successful action for a payment transaction.

⚡ Removed from typings​

These deprecations are now halfway through their deprecation timeline. As of now, these services and/or fields will no longer be exposed by our typings.

Deprecated​

Low​

• Low PageConfig is deprecated and will be removed in 2.0.708: This service is using infinite scrolling from now on because the result sets are huge.
  • ListGeneralLedgers.PageConfig

🚫 Effective​

These deprecations are now effective. As of now, these services and/or fields are no longer available in EVA and can no longer be used.

Deprecated​

Medium​

• Medium OrderLineID is deprecated since 2.0.704: Use OrderLineIDs..
  • SetOrderSoldBy.OrderLineID

Release dates may vary​

The exact date for deploying a Core release to production environments may vary. See How we handle Core releases for more details.