Labels of all homeboxes of a homebox type is always the label of the preset even if the homebox is already configured

Take care, the username is dynamic and can change. So it wouldn't be good to save a copy of that.

The question is: Did you enter the name "Test Preset" or was it created dynamically?

• If you entered it manually, we should close this won't fix, because in real world the name will never be that way.
• If the "Preset" suffix was added automatically (which I think is the case), we should simply not use that as basis for the instance label, but instead get the name from the homebox itself, which should already carry the name without suffix? I think we should then simply use that one.

As first step please check if there already is related code present for the label, that should do the trick, but isn't working as expected. If I remember correctly, we already had a working solution for hat.

Adding the name would be great, if it was immutable, but it isn't, so let's leave that out.

This is minor, but yes - should be solved.

It was created dynamically. In our Homebox "retrieveInstance()" method, we initially create a duplicate of the preset, change the owner, creator and creation time. But we never adjust the label, hence everyone's Homebox label stays "Test Preset".

@Anybody, what do you think? (The last homebox in the screenshot is newly auto generated):

If fine, I would quickly adjust existing tests to check for the new label.

I guess to conform with the "Personalize my {homebox_type_label}" label on the personalization page, we should adjust it to "max's Test" (where "Test" is the homebox type label).

Done.

@Grevil: Seems you didn't fully read my comment #2?

Adding the name would be great, if it was immutable, but it isn't, so let's leave that out.

So the user's name shouldn't be part of the label. User names can change, but the label is saved with the wrong name then. Not a good option.

Sorry. Yea we already have working solutions, where we dynamically create the label. But the list overview will show the real label.

What do you think of this approach?

Or do you recon it is too error-prone and not worth it, performance wise?

While taking a look at the whole page Title rendering, I found a few issues:
1.
Many of our page title or manual title overrides do not take presets and default presets into account. If we personalize one of them, it will only show the owner and homebox type, like "admin's homebox", even if the current homebox is not the admin's personal homebox, but a preset. To fix this, I additionally created centralized "viewLabel()" and "personalizeLabel()" methods on the homebox entity, which serve the same purpose as the "label()" method, but with a different text (e.g. prefixed with Personalize) and called these methods where necessary.

2.
We already found out in 🐛 Unclear which Homebox is personalized, when accessing foreign homebox through direct rout Closed: duplicate , that on direct homebox routes, no "personalize" label is being rendered. This is because on direct homebox routes (not accessing through user tab or custom page), drupal will directly call the view builder WITHOUT going through the HomeboxController's "build()" or "buildPersonalize()" methods, which manually add their respective labels. Meaning, I had to move them into alterBuildDefault(), so the label logic gets directly applied, when calling the viewBuilders "view()" method. BUT this is not enough. Because of the caching logic ALSO being in build and buildPersonalize, we never cache any homebox when accessing the homebox through a direct route.

The applied code will fix the issue.

This can already get reviewed, but we definitely need tests at least for the title logic and to check if the routes lead to the correct homeboxes after this change. If we are lazy, we could simply incorporate these checks in our already existing access tests.

Alright, I adjusted the tests accordingly. I am 100% sure this is ready to get merged, please do a final review!

Tests are all green.

Ok let's do it. It it fails, we should be able to revert. But hopefully it just works. :)

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