Improve the structure and organization of the tours list page

Don’t know why didn’t think of it but probably could just be a view itself.

yeah that would make things more consistent to Core as well more flexible/adjustable further

FYI this one is definitely top of the list just trying to get the bugs fixed first.

no rush, one thing after the other, and fixing all those bugs and getting the entire codebase more stable is definitely the right call here in regards of prioritization. but thanks for the headsup!

Okay so may be able to tackle this one soon. Hoping it's easy haha

So unfortunately upon digging into it. Tours are config so they don't have a table to pull from. Will ask a view maintainer if there is a recommended way to turn config into views but if it's super complex may just make more sense to fix up the viewbuilder.

Apply the same pattern used on /admin/structure/views separating enabled and disabled tours.

What about instead we address the other bullets in this ticket. And open a follow up to add filters to the listBuilder. I don't think can make a view out of config (skillset wise)

Let's see if this is any better.

Looking into the test failures.

0 idea if I'm doing the calc right

But believe I'm definitely leaning on adding filters vs separate sections though objections? Probably can be a follow up.

That one slipped through, apologies. I've taken a look, a few observations and thoughts:

i would rename the title of machine_name in the tabel header to Machine name, that it is consistent with other tables like for example admin/structure/views

I would also make routes upper case so it is Routes

Then all the tours that the tour module is shipping with have no module dependencies, that way you have one empty column. But i wonder in combination with Routes. Are those two columns necessary at all? does someone really need those two details in the tour overview page? are dependencies or routes are compared on the overview page between different tours? is there a need for that? otherwise those two informations might be also good enough only be shown on the edit page of a tour maybe?

and in regards of "Apply the same pattern used on /admin/structure/views separating enabled and disabled tours." you wrote "if there is a recommended way to turn config into views ", but on closer look is it really necessary to turn this tour page into a view? as far as i understand admin/structure/views is not a view either? that pattern is only about having two tables instead of a single one. one table for enabled tours and one for disabled. so maybe that way it is not necessary to turn that tours list page into a view? cuz there is also no need to sort based on a particular column or leave the user the option to alter the columns and so on.

I'll change the issue back to needs work for the first two points about the micro copy.

Addressed the feedback round routes and modules. Less calls on the overview page.

We can push the disabled section to a follow up to not hold the other improvements here. But my idea was that we could have 100s of tours so filters would be more useful then separate sections.

Will admit also haven't done filters in listbuilders before so it would be an adventure for sure.

looks good. and completely agree on moving the disabled section part to a follow up.

and just to understand things correctly, for the ability to have a filter it is necessary that the page is an actual view? but yeah with more than 20 or 50 tours a filter would be helpful or lets say better mandatory.

oh and removing the two columns made the page less overwhelming. i like that. but i wonder with your example of 100s of tours it might be helpful to have a description column so the distinguishing is not just based on the tour name (which might be also cryptic in case you have 100s of tours. i doubt you will be able to pick clear and easy to grasp tour name each and every time).

Opened a followup: ✨ Add a enabled and disabled section to the tour list page Needs review

Automatically closed - issue fixed for 2 weeks with no activity.