-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New true/false property type for member type is null although the default value is set #8473
Comments
Hi @deekoulos, This is by design - see #7409 (comment) for more information on this. I understand it's a pain with 30000 members. I would suggest you reverse the property meaning so "default false" works for you. Otherwise the good folk over at the forum might be able to help you with a workaround. |
There is a plan afoot to 'rename' this configuration option for a checkbox so it's clearer what the outcome of setting the option is: #8420 but yes the workaround when working with checkboxes added to existing content, is to presume their absence = false, or insert the default value into the cmsPropertyData database table using SQL for the 'current' version of the content item you are providing the default value for. |
Hey guys, thanks for the feedbacks, although it would be great for the future to have a short dialogue first, before a ticket is closed so quickly. It could make sense, if this is the design for content items, using the true false property type, to know, if an editor actually set the value or not. But for member types? What is the consideration behind this for a member type? This behaviour does not make any sense to me for a member type. And as we already know, compared to content items, which have a content transfer feature between environments, members are not transferable between environments. So you suppose to workaround the behaviour directly in sql for all environments? And no, it would not help to set the default value to false, since the value is null as i mentioned, and not false. Any other solutions, like converting and so on is a dirty workaround for this behaviour. If this is the design of umbraco for member types, then actually the design is buggy! I of course coded a workaround for this misbehaviour. But in the end, this is still a bug, wether in design or in the implementation for member types, and needs to be fixed. You cannot expect for larger environments with many thousands of members, to run sql scripts for every additional true false property type and every environment. |
@deekoulos Yes, agree, I was just saying SQL is 'a way' not the 'best way' you should definitely do!! or be expected to do... and it's great to raise issues like this because it does flag how much of a bugbear this is to everyone, that can get help get focus on finding a good 'default value' solution - #7859 the problem is that it isn't a 'default value', the architecture of Umbraco isn't currently geared up to allow you to add a property, and set a 'default value' and have that value automatically populated across all the things with that property. But by labelling the 'initial value for the checkbox editor when it is presented in the backoffice' as 'default value' it leads to that very misconception. which is easy to correct. (the naming) But doesn't solve the underlying problem which is not constrained to the checkbox - which is how to set default values in Umbraco, that then update existing content, when they are added or presumably when they change their default state - which would be a great new feature to have! |
value of a new boolean property type, added to an existing member type is null.
Umbraco version
I am seeing this issue on Umbraco version: 8.6.3
Steps to reproduce
which means, you have to open and save every member separately or write a script to do this, to get the new property value set, although the default value should be set already.
Expected result
the value of the new property for all members of the member type is automatically set to true, due to presetting of the default value.
Actual result
the value of the new property is null, until it gets saved through every member in the backoffice, which is a pain when you have 30.000 members.
The text was updated successfully, but these errors were encountered: