Hello!

The no-code designer cannot do this. The "Apply static filter" dialog only accepts constants or current-user macros, and a business process can populate data but cannot filter a list on a page. To filter a list by a Text field of the current record, you need a few lines of code in the page schema. This is the documented Creatio approach for dynamic list filters.

Every list on a Freedom UI page has a data source attribute in viewModelConfig.attributes with a filterAttributes array. You add your own filter attribute there, then set that attribute to a sdk.FilterGroup in a handler. Whenever the attribute changes, the list reloads with the new filter.

Step 1. Add the SDK dependency

At the top of the page schema (UsrPreScreening_FormPage or whatever your form page is named):

define("UsrPreScreening_FormPage", /**SCHEMA_DEPS*/["@creatio-devkit/common"]/**SCHEMA_DEPS*/, function/**SCHEMA_ARGS*/(sdk)/**SCHEMA_ARGS*/ {

Step 2. Register a filter attribute on the list's data source

Find the data source for your Application list in viewModelConfig.attributes. It will look something like GridDetail_xxxx_DS or DataGrid_xxxx_DS. Add a new entry to its filterAttributes:

"GridDetail_Application_DS": {

    "isCollection": true,

    "modelConfig": {

        "path": "GridDetail_Application_DS",

        "filterAttributes": [

            { "name": "GridDetail_Application_PredefinedFilter", "loadOnChange": false },

            { "name": "GridDetail_Application_ActiveFilter", "loadOnChange": true },

            { "name": "UsrCustomerNameFilter", "loadOnChange": true }

        ]

    }

}

Keep the existing entries; only the last line is new. Also declare the attribute itself next to the others:

"UsrCustomerNameFilter": {}

Step 3. Build the filter in handlers

Add two handlers to the handlers array. The first sets the filter when the page opens. The second rebuilds it when the user edits Customer Name. Replace the attribute names with the real ones from your page (PDS_UsrCustomerName_xxxx and PDS_UsrApplicationNumber_xxxx), and the column names with the real Application object column codes.

handlers: /**SCHEMA_HANDLERS*/[
    {
        request: "crt.HandleViewModelInitRequest",
        handler: async (request, next) => {
            await next?.handle(request);
            await applyCustomerNameFilter(request.$context);
        }
    },
    {
        request: "crt.HandleViewModelAttributeChangeRequest",
        handler: async (request, next) => {
            if (request.attributeName === "PDS_UsrCustomerName_xxxx" && !request.silent) {
                await applyCustomerNameFilter(request.$context);
            }
            return next?.handle(request);
        }
    }
]/**SCHEMA_HANDLERS*/,

Then define the helper above the return { ... } of the schema module:

async function applyCustomerNameFilter(context) {
    const customerName = context.PDS_UsrCustomerName_xxxx;
    const appNumber = context.PDS_UsrApplicationNumber_xxxx;
    const filter = new sdk.FilterGroup();
    filter.logicalOperation = sdk.LogicalOperation.And;
    if (customerName) {
        await filter.addSchemaColumnFilterWithParameter(
            sdk.ComparisonType.Equal, "UsrCustomerName", customerName);
    } else {
        // no name yet: show nothing instead of everything
        await filter.addSchemaColumnFilterWithParameter(
            sdk.ComparisonType.Equal, "Id", "00000000-0000-0000-0000-000000000000");
    }
    if (appNumber) {
        await filter.addSchemaColumnFilterWithParameter(
            sdk.ComparisonType.NotEqual, "UsrApplicationNumber", appNumber);
    }
    // required workaround: the filter must be a plain object to trigger reload
    const plainFilter = Object.assign({}, filter);
    plainFilter.items = filter.items;
    context.UsrCustomerNameFilter = plainFilter;
}

The last three lines are not optional. The list only reloads when the attribute receives a new plain object, so copying the FilterGroup this way is the standard trick.

Notes

• Use sdk.ComparisonType.Contain instead of Equal if you want partial matches on the name.
• Column codes in addSchemaColumnFilterWithParameter are Application object column codes, not page attribute names.
• If you also want Date of Birth or ID Card matching, add more conditions the same way.
• The static filter you configured in the designer can stay or be removed. Your code filter combines with it through the PredefinedFilter attribute.

Alternative without code

If you can change the data model, make Customer a lookup object instead of a Text field and reference it from both the pre-screening record and the Application object. Then the standard list-to-page binding by lookup column filters automatically. That is the only no-code option, but it only works if a shared lookup makes sense for your data.

Hello,

First of all you read only 1 record in the "Read Insurance" read data element (it can be seen from the "First item of resulting collection" macro value). The sum of this will always be the value you read. I think something else was intended here.

Next, you can use Enumerable.Sum method, but you need to get an enumerable. Or introduce a method that can be called inside a script task like (and add Terrasoft.Core.DB to the process usings):

protected decimal GetInsurancePremiTotal(Guid insuranceTypeId) { //or any other argument suitable
    var query = (Select)new Select(UserConnection)
        .Column(Func.Sum("UsrPremi")).As("TotalPremi")
        .From("UsrInsurance").As("usrInsurance").WithHints(new NoLockHint())
        .Where("usrInsurance", "UsrTypeId").IsEqual(Column.Parameter(insuranceTypeId));
    decimal totalPremi = 0;
    using (DBExecutor executor = UserConnection.EnsureDBConnection()) {
        totalPremi = query.ExecuteScalar<decimal>(executor);
    }
    return totalPremi;
}

And set the result to process parameter and then use this parameter value to proceed in the business process.

Hello,

As far as I understood you need to filter options in the "Owner" filter dropdown list. There is only one option to do that - override the crt.LoadDataRequest as (and also include "@creatio-devkit/common" to the schema dependencies):

{
                request: "crt.LoadDataRequest",
                handler: async (request, next) => {
                    if (request.dataSourceName?.includes("ByOwnerQuickFilterInTimeline_ComboBox_List_DS")) {
                        const filterGroup = new sdk.FilterGroup();
                        await filterGroup.addSchemaColumnFilterWithParameter(
                            sdk.ComparisonType.Equal, "Name", "Supervisor"); //add other filters here
                            const filterParameter = {
                                type: "filter",
                                value: {
                                    filterType: 6,
                                    logicalOperation: 0,
                                    isEnabled: true,
                                    trimDateTimeParameterToDate: false,
                                    items: filterGroup.items
                                }
                            };
                            request.parameters = request.parameters
                                ? [...request.parameters, filterParameter]
                                : [filterParameter];
                    }
                    return await next?.handle(request);
                }
            }

You also need to confirm the data source name. The easiest way to do that is to add console.log("LoadDataRequest:", request.dataSourceName); to the crt.LoadDataRequest override and see which datasource is logged when you first click this "Owner" filter.

They don't as far as I've found with a few cases of wanting archiving unfortunately.

I've always had to do some workaround such as copying the data using automated SQL scripts into an exact copy of the object for archiving purposes (I have done this by creating a new Object and setting its parent to the Object that needs archiving). This has some downsides that any changes to the regular Object won't apply to the archive Object until you re-publish the archive Object, so something to look out for.

Another issue to watch out for is how the archived data references other data, e.g. if you have parent-child relationships and you are archiving by copying exactly using SQL, the archived record would still be pointing at a "live" record rather than an archived one. Again, custom solutions are required for this.

Overall it's quite a pain, and plenty of issues can arise. It would be great if there were a built in way of doing so.

Outlook calendar integrations also needs improvements, hopefully, the new Graph API integration with Creatio 10 will improve existing behavior and allow more options 🙂. 
First thing asked by Sales teams, and first thing not living to expectations today.

Hi Dedi,

Based on you picture, it seems that you are deleting records from Offering letter section, not from attachments that are connected to one specific record in your Offering letter section. If Offering record is custom Freedom UI section than object that should be setup in your "Delete attachment Files" is Uploaded file, and you can filter files based on the filter  Record Id = Office letter Id (Parameter 1). Something like this:

I hope this can help. Let me know if you have some questions.

BR,

Jelena

Hi Jelena, thank you for feedback, now I already filter by ID, but not in Business Process, but in Design Form Page.

Thank you Jelena, appreciate it.

The errors are indicating the code is incorrect in a different schema named "LOSDATAENTERY", not in the code for the macro. Look at the schema named LOSDATAENTRY since it appears to have incorrect code and preventing the compilation from completing. 

Ryan

It's not possible for the code in Creatio to specify the path the file will be downloaded to.

Hi Ryan, ok noted, thank you for the reply

Hello,

As a best practice, we recommend first pulling and downloading any changes made by other users from the global repository. Once those changes have been synchronized, commit your updates to the local repository and then push them to the global repository. This approach helps minimize conflicts and ensures that your work is based on the latest version of the codebase.
 

We also recommend using a trunk-based development approach to organize the repository structure. Under this model, each repository typically contains: trunk, release and feature branches. When creating a new repository, generate its initial content using the Clio utility. Development work should be performed in a dedicated feature branch. Once the functionality has been completed, tested, and validated, the changes can be merged into the trunk branch for further integration and delivery.