Skip to content
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

Closed
deekoulos opened this issue Jul 24, 2020 · 4 comments

Comments

@deekoulos
Copy link

deekoulos commented Jul 24, 2020

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

  1. Create a member type
  2. add members to the member type
  3. add a new True/False property type to the member type
  4. set the default value of the property type to "true"
  5. create a page which is calling the Current.Services.MemberService.GetAllMembers();
  6. using debugger: iterate the members and take a look into the properties of each member and their values
  7. find the bool property you just created, look into the values of the property
  8. it has no values.
  9. go back to BO\members and open one of the members, save, and repeat the steps above. now the property has a value.

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.

@kjac
Copy link
Contributor

kjac commented Jul 28, 2020

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.

@kjac kjac closed this as completed Jul 28, 2020
@marcemarc
Copy link
Contributor

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.

@deekoulos
Copy link
Author

deekoulos commented Jul 28, 2020

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.

@marcemarc
Copy link
Contributor

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants