Hello, Harvey

I also had such an isuue but I resolved it by calling parameter initialization after let result =  await next?.handle(request); And then in the end return result; 

Andrii Orlenko,

Mine was already being initialised after awaiting the result of handling the request, so it might be that sometimes this takes long enough to be ok but not always (so would introduce a race condition).

Harvey Adcock,

Thank you for the provided information!
The problem is already registered on the R&D team, and we hope to see the fix in future releases.

Anhelina,

Thank you. 

Just an FYI, I've been reporting this since 8.0.10 (see #SR-01234445). I was told this would be resolved in "the nearest releases (8.1.1-8.1.2)", however, it's still an issue in 8.1.3 without a commitment from Creatio on a specific timeframe for a resolution. This is a pretty huge pain point so it's disappointing that it's still a problem. I do love Freedom UI (and I'll take it any day over classic!) but there's been many instances of my code breaking along the way with new versions and it sometimes seems less urgent for fixes for issues that go beyond the "no code" customizations.

Ryan

Ryan Farley,

I checked that case before replying to Harvey and asked the responsible team to raise the priority for this task. I apologize for the delay and hope to see the fix soon.
Meanwhile, they shared one more workaround, which is better to use with parameters:

add the handler on parameter changing and rewrite it when the default value has appeared:

Anhelina,

Yes, this approach does work if all you need when the form is initialized is to work with a single value on the page. However, that is often not the case and each property initialization can happen at slightly different times, so referencing other attributes in this same handler might not work, depending on the timing of the various attributes being loaded/initialized. Adding a separate handler for each attribute you need to work with can get messy quick.

Ryan

What I think would be nice/match the existing patterns would be to have some new request handler that does the setting of default values on the page, something like "crt.HandleAttributeInitRequest", which would perform the OOTB platform's setting of these values in the next?.handle(request) and then after awaiting the result of that a developer could set their own defaults for fields they need to, which wouldn't be overwritten (since the defaults had already been set).

It would also be nice to be able to "silently" set these default values (like you could in Classic UI) so that setting values in that request handler wouldn't cause the "are you sure" dialog to appear if a user closes the page without actually modifying the data themselves. Actually it would be nice to be able to do that generally from within request handler code.

Hi, is there any update on the matter? 
Still when you're trying to read the attributes on crt.HandleViewModelInitRequest the attributes aren't initialized and are all undefined

This issue is painful... A lot of init code cannot be done because of this. No workaround is 100% effective.

Open the object and do a publish and compile. The wizards might not have run the compile for OData entities. Once you compile the object it should show via OData. 
Ryan

Ryan Farley,

Thanks Ryan. I see what's going on. There's a previous error that is coming back to haunt me. I see the following error in the system messages: "OData entities compilation errors occurred. Please recompile the app via Configuration section. Check log file for details"

When i tried to do the publish and compile, i am back to an error with "VwSysProcess" (https://community.creatio.com/questions/compilation-error-type-or-namespace-name-vwsysprocess-could-not-be-found) . 

I tried a couple of days ago to regenerate the source code, but the process never completed. Since it was not preventing me from moving forward, i just continued, but now it seems this is actually becoming a real problem.

I am giving it a shot at regenerating code again now...

Ryan Farley,

Closing the loop here. I was able to regenerate source code for all schemas, and build successfully. After that, the lookup started showing up in OData. Thanks!

Hmm. Good find. I’ll have some broken customizations as well. Hopefully we’ll get an official word about the change. This isn’t the first time I’ve had things break from changes to core Freedom UI things. I like using Freedom UI but at times it feels like a moving target. We need some commitment from Creatio about avoiding breaking changes. 
Ryan

Hi Harvey, 

I just tested this in an 8.1.3.6734 system and both "crt.OpenSelectionWindowRequest" and "crt.OpenLookupPageRequest" did open the selection/lookup window for me. However, using the results seemed to work differently depending on which request I used, it didn't work to just change the request name and leave the rest of the code as-is. So they do appear to possibly be slightly different requests, at least from my very limited tests so far 🤷🏼‍♂️

Ryan

Interesting, thanks for the additional info Ryan! For triggering the lookup page from code I think we'll stick with the original method for now then.

But a little PSA for anyone wondering why their code overriding the crt.OpenLookupPageRequest handler to intercept and add filters/perform other logic when a user triggers a lookup page on a lookup field configured to view as "Selection window" rather than dropdown list, they should now be overriding crt.OpenSelectionWindowRequest instead. Hopefully we'll get some clarification on why this has changed and any implications.

Harvey Adcock,

8.1.3 is the first release with this API published, and Creatio mentioned the API for Freedom UI selection window in the 8.1.3 release notes. At the same time, we left it without changes so as not to break possible customizations with the old unpublished API. However, the old API is effectively deprecated, and the new API should be used from now on.

The full article for the Academy is almost ready and will be officially published soon.
Here is part of main information (maybe some parts will be changed, that's why please follow the updates): 
In order to open the lookup window, you have to use crt.OpenSelectionWindowRequest:
 

/**
 * @publicApi
 */
@CrtRequest({
    type: 'crt.OpenSelectionWindowRequest',
})
export class OpenSelectionWindowRequest extends BaseRequest {
    public itemAttributeName?: string;
    public itemsAttributeName?: string;
    /**
     * @publicApi
     */
    public entitySchemaName?: string;
    /**
     * @publicApi
     */
    public schemaName?: string;
    /**
     * @publicApi
     */
    public filtersConfig?: FiltersConfig;
    /**
     * @publicApi
     */
    public features?: PageLookupFeatures;
    /**
     * @publicApi
     */
    public selectionState?: SelectionState;
    /**
     * @publicApi
     */
    public afterClosed?: (result: SelectionWindowResult) => void;
    /**
     * @publicApi
     */
    public caption?: LocalizableString;
}

Add the following code to your custom handler:

handlers: /**SCHEMA_HANDLERS*/[
			{
				request: "usr.OpenLookupRequest",
				handler: async (request, next) => {
					devkit.HandlerChainService.instance.process({
						type: "crt.OpenSelectionWindowRequest",
						scopes: [...request.scopes],
						$context: request.$context,
						entitySchemaName: "Contact",
						// caption: 'Responsible',
						schemaName: 'CustomLookupPage',
						itemAttributeName: 'LookupAttribute_2mnilrq',
						// itemsAttributeName: 'Contact_List',
						afterClosed: async (result) => {
							if (!result.canceled) {
								const lookupValues = await result.getLookupValues();
								const value = lookupValues[0];
								if (value) {
									alert(value?.displayValue ?? '');
								}
							}
						},
						filtersConfig: {
							filterAttributes: [
								{
									name: 'MyFilter',
									loadOnChange: false
								}
							],
							attributesConfig: {
								MyFilter: {
									value: {
										"items": {
											"29e16d42-36f1-4e04-9029-4321cbb2494d": {
												"filterType": 1,
												"comparisonType": 11,
												"isEnabled": true,
												"trimDateTimeParameterToDate": false,
												"leftExpression": {
													"expressionType": 0,
													"columnPath": "Name"
												},
												"isAggregative": false,
												"dataValueType": 1,
												"rightExpression": {
													"expressionType": 2,
													"parameter": {
														"dataValueType": 1,
														"value": "Super"
													}
												}
											}
										},
										"logicalOperation": 0,
										"isEnabled": true,
										"filterType": 6,
										"rootSchemaName": "Contact"
									}
								}
							}
						}
					});
					return next?.handle(request);
				}
			}
		]/**SCHEMA_HANDLERS*/,

where

entitySchemaName - the name of the entity schema whose data is displayed in the lookup window. Optional parameter. If not specified, the data source is taken from the attribute specified in itemAttributeName

caption - optional parameter, displayed in the window title. If caption is not specified, the caption is taken from the attribute specified in the itemAttributeName parameter. If itemAttributeName is not specified, then from the entity schema.

schemaName - the name of the schema that is displayed in the lookup window. Optional parameter. Default is BaseLookupPageTemplate

itemAttributeName - the name of the attribute from which the title is taken, the name of the entity schema and in which the result of the selection in the window will be written. Optional parameter. As a rule, this is the attribute with which the Combobox control is associated.

itemsAttributeName - the name of the attribute from which the data source name is taken. Optional parameter.

afterClosed - callback function returning the result of the selection in the window. Optional parameter.

filtersConfig- describes the filter to be applied to the data. Optional parameter

P.S. Additionally, users can enable features and much more, which you're able to read from the article on the Academy in the near future.

Anhelina,

Thanks for this Anhelina. 

Anhelina, 

Hi!

How i can filter SelectionWindow by using value from lookup field on page? 

I try this: 

{
   request: "usr.AddSection",
   handler: async (request, next) => {
 
       const id = request.$context.PDS_Transport2_93i8xm8;
 
 
       request.$context.executeRequest({
           type: "crt.OpenLookupPageRequest",
           $context: request.$context,
           entitySchemaName: "Section",
           features: {
               select: {
                   multiple: true,
                   selectAll: false,
                   resultType: 'lookupValues'
               },
               create: {
                   enabled: false
               }
           },
           filtersConfig: {
               filterAttributes: [
                   {
                       name: 'MyFilter',
                       loadOnChange: false
                   }
               ],
               attributesConfig: {
                   MyFilter: {
                       value: {
                           "items": {
                               "29e16d42-36f1-4e04-9029-4321cbb2494d": {
                                   "filterType": 1,
                                   "comparisonType": 11,
                                   "isEnabled": true,
                                   "trimDateTimeParameterToDate": false,
                                   "leftExpression": {
                                       "expressionType": 0,
                                       "columnPath": "Transport"
                                   },
                                   "isAggregative": false,
                                   "dataValueType": 1,
                                   "rightExpression": {
                                       "expressionType": 2,
                                       "parameter": {
                                           "dataValueType": 1,
                                           "value": id.value
                                       }
                                   }
                               }
                           },
                           "logicalOperation": 0,
                           "isEnabled": true,
                           "filterType": 6,
                           "rootSchemaName": "Section"
                       }
                   }
               }
           },
           afterClosed: function(selectedItems) {
               const textValues = Object.values(selectedItems).map(item => item.displayValue).join(', ');
               request.$context.PDS_SectionUpload_h11bk0p = textValues;
           }
       });
   }
}

but always get error: The data types nvarchar and uniqueidentifier are incompatible in the add operator.

Ryan Farley,

Maybe you can help?

Grygorii Synieok,

You forgot to await the value when getting the attribute. 

Change to this (note the added "await"): 

const id = await request.$context.PDS_Transport2_93i8xm8;

Ryan

Ryan Farley,

Thank you!

But another problem was with: "dataValueType":10 and  "comparisonType":3 with this parametrs works fine.

Full code:

{
    request: "usr.AddSection",
    handler: async (request, next) => {
 
        var autoId = await request.$context.PDS_UsrTransport2;
 
 
        request.$context.executeRequest({
            type: "crt.OpenLookupPageRequest",
            $context: request.$context,
            entitySchemaName: "SectionAuto",
            features: {
                select: {
                    multiple: true,
                    selectAll: false,
                    resultType: 'lookupValues'
                },
                create: {
                    enabled: false
                }
            },
            filtersConfig: {
                filterAttributes: [
                    {
                        name: 'MyFilter',
                        loadOnChange: false
                    }
                ],
                attributesConfig: {
                    MyFilter: {
                        value: {
                            "items": {
                                "29e16d42-36f1-4e04-9029-4321cbb2494d": {
                                    "filterType": 1,
                                    "comparisonType":3,
                                    "isEnabled": true,
                                    "trimDateTimeParameterToDate": false,
                                    "leftExpression": {
                                        "expressionType": 0,
                                        "columnPath": "Transport"
                                    },
                                    "isAggregative": false,
                                    //"dataValueType": 1,
                                    "rightExpression": {
                                        "expressionType": 2,
                                        "parameter": {
                                            "dataValueType": 10,
                                            "value":autoId.value
                                        }
                                    }
                                }
                            },
                            "logicalOperation": 0,
                            "isEnabled": true,
                            "filterType": 6,
                            "rootSchemaName": "SectionAuto"
                        }
                    }
                }
            },
            afterClosed: function(selectedItems) {
                const textValues = Object.values(selectedItems).map(item => item.displayValue).join(', ');
                request.$context.PDS_UsrSection = textValues;
            }
        });
    }
}

Hello Harvey,

I've a 8.1.3 environment and on some pages the crt.OpenLookupPageRequest works correctly  while on other pages it doesn't open the required lookup

Do you have the same issue ?

You can create an exists filter by using something like the following. This example would get accounts where an activity exists with a particular owner.

// create the sub filter for the condition inside the exists
var subFilters = Terrasoft.createFilterGroup();
subFilters.addItem(Terrasoft.createColumnFilterWithParameter(Terrasoft.ComparisonType.EQUAL, "Owner", "a6b4ea0c-420c-45ab-81e7-6e76c8cc15f7"));
 
// now create the exists filter and pass the sub filter conditions to it
// note, this second param of subFilters is optional if all you want is the exists without sub conditions
var existsFilter = Terrasoft.createExistsFilter("[Activity:Account].Id", subFilters);
esq.filters.addItem(existsFilter);

That is the equivalent to the following:

Ryan

Ryan Farley,

I am sincerely grateful to you. With your help, other answers in the community and articles from the Academy, I learned and managed to write this complex filter. Thank you. The code currently looks like this:

attributes: {
	"UsrPlatform": {
		"dataValueType": Terrasoft.DataValueType.LOOKUP,
		"lookupListConfig": {
			"filter": function() {
				var platformFilter = this.Ext.create("Terrasoft.FilterGroup");
				var accountId = this.get("Account").value;
 
				var licenceFilter = Terrasoft.createExistsFilter(
					"[UsrLicenceClient:UsrProductLic].Id");
 
				licenceFilter.subFilters.addItem(
					Terrasoft.createColumnFilterWithParameter(
						Terrasoft.ComparisonType.EQUAL,
							"UsrAccount", accountId));
 
				var productFilter = Terrasoft.createExistsFilter(
					"[Product:UsrPlatform].Id", licenceFilter);
					platformFilter.addItem(productFilter);
				return platformFilter;
			}
		}
	}
}

I hope it helps someone and saves a lot of time.

Have you tired “generating source code for all schemas” before compiling?

Ryan

Ryan Farley,

I tried but the process never completed. I am trying again now. Will report back.

I haven’t seen that one before. Could it be permissions on the configuration folders under Terrasoft.WebApp? Does generating source code and compiling (without adding new items) work normally?

Ryan

Ryan Farley,

In the end i solved the issue by moving the code from the Windows 11 machine where it was initially hosted to a Windows Server 2019. As far as I know permissions and prerequisites were set up the same in both.

This is because there can be multiple "Account - Contact" records for  an account so the choices there are aggregates only. If you're adding this as a filter condition, select "Quantity" and then choose Quantity > 0. Then, inside of that, as a condition within the Quantity>0, you can add additional conditions, such as "Account" = "Some specific account", etc. 

Ryan

Oh, I didn't believe the solution is so simple :) Thank you!

Hello Pedro,

You can add a few equal phone numbers as the communication options. All you need is to choose the different types for them:

Hi Anhelina,

Thank you for the response.

The idea here is to use the same type. For example, we need to create multiple duplicated instances for "Mobile Phone", because later on we will be using these records for our business logic. The number might be the same, but we have other attributes that have unique keys. We want to change this rule so it can be applied to those attributes.

Best Regards,

Pedro Pinheiro

Hi Harvey, 

Does it not work to bind an attribute to the enabled property of a button and set as true/false? I've not tried that, but I assume it would work? Have you already tried that?

Ryan

Classic UI buttons have a property 'enabled'
Freedom UI buttons have a property 'disabled'

Huh, not sure how I missed that, could've sworn I tried doing that! Thanks both.

As a note, the only way I could find to put some kind of hint/tooltip on the button when it's disabled is by using the "title" property, which gives you a standard browser tooltip display when hovering the mouse over the button. And binding that to an attribute that you change to be blank when the button is enabled.

Anybody have any info on this?

Does anyone have any other methods for managing per-user system settings in Creatio? It seems like there aren't a lot of options besides setting them in JS code when a user does a given action, but then that feels like it defeats some of the purpose of system settings being that the value doesn't have to be calculated every time a user does something, and also means it can't reliably be used for tasks like setting a default field value on an entity.

Contemplating using this methodology for running code when a user logs in to set it, hopefully it will work. Would be nice to have some clean way of doing it though, especially since we don't really need to be calculating it every time a user logs in but just when certain data changes: https://customerfx.com/article/executing-code-in-creatio-application-an…

Hi! 
Were you able to figure that out how set up FUI setting per user in system setting without code? 

I did not, and I suspect there wouldn't be a way currently possible without code. I haven't figured it out with code either! I believe we moved on to going another route that didn't involve system settings in the end. I'm sure this functionality would be useful again in future though, if anyone else has worked out how to do so?