Accessing settings in a Block custom view preview still always returns the first settings value

[PeatLaur]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

15.2.1

Bug summary

When a Block Grid block element has a settings model with more than one property any attempt to use the values in a Block Custom View an the back office always returns the first declared property in the settings model.

Specifics

This was said to be resolved in the update to Umbraco 15.2.0 but in my tests this is not the case. If I am mistaken and my testing code is incorrect, then please advise.
Previous issues where this issue was outlined A: #17989
Previous issues where this issue was outlined B: #18024
I have been on the Umbraco forum asking about this issue:

Steps to reproduce

Created a Block Grid called Feature with a Block called Feature Block and a settings Block Feature settings.
Added the same parameters/attributes to each the content and settings Feature Name and Feature Details with slightly different aliases so they do not class.

Feature block shown in page:

Feature Block shown in preview in CMS - note the repeated settings value from first entry - featureName:

Feature Block showing content parameters:

Feature Block showing Settings parameters:

Here is the complete code for the Typescript Custom Block Gris preview:

import { UmbTextStyles } from '@umbraco-cms/backoffice/style';
import type { UmbBlockEditorCustomViewElement } from '@umbraco-cms/backoffice/block-custom-view';
import { UmbLitElement } from "@umbraco-cms/backoffice/lit-element";
import { html, customElement, property, css, state } from '@umbraco-cms/backoffice/external/lit';
import { UmbElementMixin } from '@umbraco-cms/backoffice/element-api';
import type { UmbBlockDataType } from '@umbraco-cms/backoffice/block';
import { UmbBlockGridTypeModel } from '@umbraco-cms/backoffice/block-grid';

const elementName = "feature-block";

// eslint-disable-next-line local-rules/enforce-umb-prefix-on-element-name
@customElement(elementName)
// eslint-disable-next-line local-rules/umb-class-prefix
export class FeatureBlockCustomView
	extends UmbElementMixin(UmbLitElement)
	implements UmbBlockEditorCustomViewElement
{
	@property({ attribute: false })
	content?: UmbBlockDataType;

	@property({ attribute: false })
	settings?: UmbBlockDataType;

	@property({ attribute: false })
	settingss?: FeatureBlockCustomView;

	@state()
	contentState?: UmbBlockDataType;

	@state()
	settingsState?: UmbBlockDataType;

	@property({ attribute: false })
	blockTypeAttr?: UmbBlockGridTypeModel;

	@state()
	blockType?: UmbBlockGridTypeModel;


	override render()
	{
		console.log("blockTypeAttr :: ", this.blockType);
		return html`
			<p>Feature Block Custom View - end render settings</p>
			<div class="${this.settings?.blockAlignment ? this.settings?.blockAlignment : undefined}">
                <h5>Values from Settings block for Feature Block</h5>
                <p>Headline: ${this.settings?.featureName}</p>
                <p>Details: ${this.settings?.featureDetails}</p>
				
            </div>
			<div class="${this.content?.thisBlockAlignment ? this.content?.thisBlockAlignment : undefined}">
                <h5>Values from content block grid for Feature Block</h5>
                <p>Headline: ${this.content?.theFeatureName ? this.content?.theFeatureName : undefined}</p>
                <p>Details: ${this.content?.thisFeatureDetails ? this.content?.thisFeatureDetails : undefined}</p>
				
            </div>
		`;
	}

	static override styles = [
		UmbTextStyles,
		css`
			:host {
                display: block;
                height: 100%;
                box-sizing: border-box;
                border-radius: 9px;
                padding: 12px;
            }
		`,
	];
}

export default FeatureBlockCustomView;

declare global
{
	interface HTMLElementTagNameMap
	{
		[elementName]: FeatureBlockCustomView;
	}
}

Note:
I was viewing in the console.log output from UmbBlockGridTypeModel to see if there was another way of assessing the settings values. This game me this output. So I could see the ID of the settings block, but not the member values for feature name or feature details:

blockTypeAttr ::  
{contentElementTypeKey: '9c0aa734-b640-4af7-9083-fe20b3c9ad91', allowAtRoot: false, allowInAreas: true, groupKey: '3c3fd46f-98c6-418a-84b6-10b3039b8c04', label: 'Feature', …}
allowAtRoot
: 
false
allowInAreas
: 
true
contentElementTypeKey
: 
"9c0aa734-b640-4af7-9083-fe20b3c9ad91"
editorSize
: 
"large"
groupKey
: 
"3c3fd46f-98c6-418a-84b6-10b3039b8c04"
label
: 
"Feature"
settingsElementTypeKey
: 
"2994c06d-cfed-47ec-a84a-ad331a9aed1e"
[[Prototype]]
: 
Object

Expected result / actual result

Expect to see the correct values displayed in the preview for the settings parameters: Feature Name (theFeatureName) and Feature Details (ThisFeatureDetails)

I hope that this can be looked at again before the next Umbraco update and it would be great if this is resolved.

Thank you,

Kind regards,

Pete

---

This item has been added to our backlog AB#49173

[github-actions]

Hi there @PeatLaur!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[nielslyngsoe]

Hi @PeatLaur Thanks for reporting this again, we will look into this one very soon.