U4-10437 - Listview children not showing after upgrade to 7.7

Created by Sebastiaan Janssen 20 Sep 2017, 09:18:03 Updated by Sebastiaan Janssen 29 Sep 2017, 06:41:28

Tags: Unscheduled

Is duplicated by: U4-10433

Is duplicated by: U4-10469

Subtask of: U4-9609

To repro:

  • Install 7.6 - add new starter kit
  • Upgrade to 7.7
  • All nodes with a list view now no longer return children from the GetChildren method (see first screenshot)
  • In the Users section go to Groups and check out the migrated group for the admin user, see second screenshot, it's not allowing anything
  • In the migrated group, you can enable "Browse nodes" to make list views work again
  • The other solution is to remove my user from this migrated admin group

I'm assuming this migrated group is not being converted correctly and I'm not sure why it's necessary. I didn't customize anything in 7.6, the existing admin group is the only one this user should be in anyway.

3 Attachments


Rune Grønkjær 20 Sep 2017, 10:54:05

The items disapear when being checked for assigned permissiong in line 122 in the FilterAllowedOutgoingContentAttribute.cs file. Apparently none of them have anything in their AssignedPermissions property. Publishing the nodes again does not help.

Sebastiaan Janssen 20 Sep 2017, 11:20:24

Correct. See above for the workaround.. check the groups your user is assigned to.

Rune Grønkjær 20 Sep 2017, 12:21:47

Hey. That worked. Didn't read the desciption properly after starting on a linked issue. Sorry, but thanks :)

Eric Schrepel 20 Sep 2017, 16:12:48

Related (I'm here because of the 7.6 to 7.7.1 upgrade making list views empty): what are all the Migrated ___ groups? Do i need to keep those? It made like 8 of those groups, and I'm not sure if I'm supposed to enable "Browse nodes" for all of them?

Eric Schrepel 20 Sep 2017, 16:24:51

Don't know if this helps, but I see that as an administrator, I was part of several groups (including Administrators). While "Browse nodes" was enabled already for the Administrators group, it wasn't enabled for some of the other newly-created "Migrated ___" groups that I was also in. I would have assumed the Administrators permissions would overrule the other groups, but not the case. Switching "Browse nodes" to true for all the other groups I was in eventually allowed the List View to display correctly.

Dan Booth 22 Sep 2017, 15:34:53

Are these "migrated" groups necessary? I'm not clear what the purpose of them is or whether they are needed after an upgrade has succeeded? Can they just be deleted?

Shannon Deminick 25 Sep 2017, 12:45:44

@DanDiplo The migrated groups are created to denote:

  • A group is created per user type with those default permissions set, any user that was part of that user type is now part of this user group - potentially this group doesn't affect security but it denotes a role. You cannot delete Admin or translator since those are special roles
  • A single user's granular content permissions - so if you want to keep those, you'll need to keep the group created for the user
  • One or more user's section access to the back office - we create a migrated group for each unique collection of section access given to users (instead of creating one group per user for section access)

Shannon Deminick 27 Sep 2017, 12:20:36

PR for review: https://github.com/umbraco/Umbraco-CMS/pull/2220

The problem is that we were iterating over each permissions set for each user group/entity id combination. So the migrated group doesn't have any default permissions so after looking at the admins permissions (which were fine) it moved on to the migrated group's permissions and since nothing matched it removed that node. This logic is just flawed because we are supposed to be checking against the aggregated permissions across groups for that node. So that is what the fix does and it works as expected.

Sebastiaan Janssen 28 Sep 2017, 20:00:55

This almost worked well now, except when you select items (see screenshot) in the list view, you get an error that the item already exists in the dictionary. This is because GetPermissions returns an EntityPermissionsCollection with permissions for each user group, so in my case there was a result for the normal admin group (all permissions) and for the same EntityId there was a result with for the permissions for the migrated group (none).

Fixed this in the same way as was done in the GetAllPermissions method. https://github.com/umbraco/Umbraco-CMS/pull/2220/commits/448a99d5a484d27885de157c3749e696bce47537

Shannon Deminick 29 Sep 2017, 02:19:27

The PR wasn't merged but this was marked as fixed ;)

I'll update, i think the code can be simplified since we have a method to do that now

Sebastiaan Janssen 29 Sep 2017, 06:41:28

The PR wasn't merged but this was marked as fixed ;) Wat!

Eh... ah, I see, I only pushed my changes to the branch haha sorry!

Cool, simplification looks good indeed, thanks!

Priority: Major

Type: Bug

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.7.0, 7.7.1

Due in version: 7.7.2

Sprint: Sprint 68

Story Points: 1