U4-5672 - Properties and Tabs moving/incorrect when Enable list view selected

Created by Miku Kelley 21 Oct 2014, 16:53:58 Updated by Chris Morley 06 Dec 2017, 11:14:37

Is duplicated by: U4-6800

Relates to: U4-6800

Relates to: U4-10734

Relates to: U4-4569

Relates to: U4-5352

Subtask of: U4-9609

Buy document has list view enabled (Child Items tab is created by Umbraco, Content tab has a sort order/id of 1, widgets tab is 2, and so on. Content and Widgets are not Inherited tabs/properties but set on this doctype) [screenshot 1] Notice that the MNTP for Widgets appears below the Child Items instead of on the tab it is assigned to [screenshot 2]

Changing to the widgets tab we don't have the widgets MNTP here (where it should be), just the Child Items table again (not sure it should be) [screenshot 3]

Going back to the Child Items tab we now have no widgets MNTP and no amount of going between the tabs will bring it back or make it appear (oh noes) [screenshot 4]

This isn't limited to MNTP, before the MNTP was there it did the same thing with the texstring and richtext editor properties on the Content tab, nor is it just this doctype...

Edit: Looks like U4-5352 U4-4569 are from this same issue

6 Attachments

Download krael7.bak

Download U4-5672.mp4


Sebastiaan Janssen 26 Oct 2014, 20:40:01

Unfortunately I can't reproduce this issue on a clean 7.1.8 install: Create a doctype with 3 tabs, the document type has an MNTP, RTE and color picker on different tabs, this all shows on the tabs I assigned for them.

Please re-open this issue if you can reproduce this on a clean 7.1.8 install and give some more detail on what's on there so we can reproduce and investigate.

Miku Kelley 27 Oct 2014, 12:01:55

I can reproduce this on a clean 7.1.8 Could it be something to do with the number of tabs, inherited & on the docType in question; as a comparison of the html on content shows that on nodes where this problem is happening and on nodes where it isn't the Child Items tab is being generated as:

On one where this isn't happening it also has the following tabs markup within

// tab25 for child items mentioned at the top is here

But on the instance causing the error above (which I have recreated by recreating, not copying or exporting and importing, the site docTypes and content in a clean 7.1.8) has the following tabs markup within

// tab25 for child items mentioned at the top is here

Notice the second tab25 (which is the widgets content)

It is also the same on the docType with the richtext editor that is behaving like this: within

// tab25 for child items mentioned at the top is here

TabsAndPropertiesResolver.cs states listViewTab.Id = 25; If 25 is set in stone for the "Child Items" and there are enough doctypes with tabs to get to the ID 25 I'm guessing this is why creating just 1 doctype with 3 tabs as a test is not recreating it but when I recreated the whole site's doctypes I immediately get the problem again?

As such I will mark this as open again.

Miku Kelley 27 Oct 2014, 15:14:43

Just to add, although not pretty, adding for(tab in data.tabs) { if( data.tabs[tab].alias == "umbContainerView" && data.tabs[tab].id == 25 ) { data.tabs[tab].id = 110432; } } to the umbraco.controllers.js within contentResource.getScaffold and contentResource.getById blocks has fixed it for now; as the site needs this feature going forwards I had to employ a workaround and don't see myself hitting 110432. A proper work around would probably calculate a true id here or in TabsAndPropertiesResolver.cs by looking at what tab ids already exist, and making sure the child list is always bigger.

Sebastiaan Janssen 27 Oct 2014, 15:45:34

I absolutely believe that you can reproduce it, I just need to be told how so we can look at it. Would be good if we could get the database of your clean 7.1.8 install that's displaying this problem.

Miku Kelley 27 Oct 2014, 17:20:19

The easiest way to reproduce it is to create a doctype and give it 25 tabs, place some properties on each tab, enable list view, and watch what happens when you create it under content. Although this isn't something I would call real world, it does show the problem. In my case the first tab I created actually got the id of 12 so I only needed to create 13 tabs to create the problem, which isn't that hard a number to reach if you run multiple sites in a single instance or have many very different document types. I guess my two live sites that I've used my workaround on were just very unlucky in that the 25th tab is an important one that gets inherited by other doctypes.

I have attached the .bak of a really quick demonstration of the issue for you.

Miku Kelley 30 Oct 2014, 09:16:38

Unsure how viable this is as a solution but working from source; changing line 125 of TabsAndPropertiesResolver.cs (Umbraco.Web.Models.Mapping) from: listViewTab.Id = 25; to: listViewTab.Id = display.Tabs.Count() + 25;

Then building and replacing umbraco.dll has fixed the issue on that sample site.

Shannon Deminick 26 Jun 2017, 06:40:03

Closing issue due to inactivity - see blog post for details https://umbraco.com/blog/issue-tracker-cleanup/

Todd Dubenezic 30 Jun 2017, 17:58:53

We're running into this issue as well; when activating list view for a content type that also has a cmsPropertyGroup with id=25, both tabs share the editor of whichever tab is leftmost and the other editor is inaccessible.

Liam Beckett 14 Jul 2017, 07:38:16

I am experiencing this issue too now, on a clean installation of 7.6.3. I think this problem may be exacerbated through the use of a number of "compositon" documents/tabs, meaning the number of tabs in the system can quickly reach 25.

Miku Kelley 14 Jul 2017, 08:57:34

I opened this in 2014, it was insta-closed (dismissed) and even after reopening it, and giving everything required to reproduce or see where to fix it, nothing was done. I wish you guys luck but in the end we had to fork and apply our own fix to each version we used.

src/Umbraco.Web/Models/Mapping/TabsAndPropertiesResolver.cs Change: listViewTab.Id = 25; To: listViewTab.Id = display.Tabs.Count() + 25;

The extra step might be the reason our boss wants to move to Wordpress :(

Liam Beckett 14 Jul 2017, 11:14:48

@Miku Thanks Miku. I actually used your "umbraco.controllers.js" solution above to avoid rebuilding the DLL (my first ever core code change, really) and this helped, but obviously this is going to be an issue going forward, with updates. I know what you mean ;)

Sebastiaan Janssen 17 Jul 2017, 08:10:48

PR: https://github.com/umbraco/Umbraco-CMS/pull/2049

Since this is a tough one to reproduce, I've added a video. In the first part, tab number 8 got the ID of #tab25 which means the list view (hardcoded with ID 25) is showing up instead of the content of tab number 8.

After adjusting the code and rebuilding it, the list view tab just gets the highest tab ID + 1, which means it's not #tab28 and the number 8 tab is still at #tab25 which now works (has an mntp on it).

Bjarne Fyrstenborg 17 Jul 2017, 08:24:43

@nul800sebastiaan there is also this issue about the hardcoded tab id, when listview is enabled. http://issues.umbraco.org/issue/U4-6800

and this PR https://github.com/umbraco/Umbraco-CMS/pull/1552

Bjarne Fyrstenborg 17 Jul 2017, 08:28:36

Maybe also take a look at the PR here to rename the "Child items" tab: https://github.com/umbraco/Umbraco-CMS/pull/2034

Warren Buckley 17 Jul 2017, 08:41:52

@sebastiaan PR all looks good & merged in

Sebastiaan Janssen 17 Jul 2017, 16:00:40

@Bjarne.Fyrstenborg Thanks U4-6800 has the same solution as this one. Great suggestion, U4-10088 is now also fixed and part of the next release!

Chris Morley 06 Dec 2017, 11:06:59

I dont think this is quite fixed. On our latest Umbraco Cloud (7.6.11) we have a tab which is inheritting a tab from a composition with ID 12. and when we are enabling ListView the generated tab is calling

listViewTab.Id = display.Tabs.Count() + 1;

And setting its TabId to 12 also (in my instance).

We need to ensure that the tabId doesn't clash with any existing tabs on the doctype. I saw that there was a commit: https://github.com/umbraco/Umbraco-CMS/pull/1552/commits/56f4166be742037af72ecef65b91fd38dd7da45a which seemed to do this by adding 1 to the highest tab Id on the Document. This seems like the simplest way to achieve this.

Priority: Major

Type: Bug

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted: Inline code

Affected versions: 7.1.6, 7.1.7, 7.1.8, 7.5.8, 7.6.1

Due in version: 7.6.5

Sprint: Sprint 63

Story Points:

Cycle: 3