- Issue created by @m4olivei
- 🇮🇳India prashant.c Dharamshala
I think this issue will have dependency on https://www.drupal.org/project/navigation/issues/3412119 📌 Restrict configuration of the Navigation bar footer items Fixed
- Assigned to thebumik
- 🇲🇩Moldova thebumik
I'll be taking ownership of this ticket and will work on resolving it as soon as possible.
- Status changed to Needs review
8 months ago 9:32pm 11 March 2024 - 🇲🇩Moldova thebumik
Added the "revert to default" operation so users now can reset their navigation layout to the default configuration provided by the navigation module.
In developing this feature, I ensured careful consideration was given to the user experience and communication aspects. Users will be clearly informed about the implications of reverting to the default layout, including what changes will be lost. This addition aims to provide users with more control and flexibility while minimizing the risk of unintended modifications.
Overall, I believe this enhancement will greatly improve the usability and manageability of navigation settings. - Status changed to Needs work
8 months ago 7:26am 12 March 2024 - 🇪🇸Spain plopesc Valladolid
Good job in the MR!
Added some comments that should be addressed before merging this.
Thank you for your efforts.
- Status changed to Needs review
8 months ago 8:05am 12 March 2024 - Status changed to Needs work
8 months ago 8:46am 12 March 2024 - 🇪🇸Spain plopesc Valladolid
Good job!
As mentioned in the MR comment, I believe we need to rethink the logic to determine the defaults the module should revert to.
Let's see if @m4olivei has something in mind for this situation.
My proposal would be to have a defaults array somewhere where ,modules could register their "defaults" to revert. Taking into account that maybe not all the navigation blocks would be defined by navigation module in the future.
On the other hand, that would end up in a situation where contrib modules define their own defaults, having a long list of defautl blocks that exceeds the space available in the navigation bar.
What do you think?
- Status changed to Postponed
8 months ago 1:38pm 13 March 2024 - 🇨🇦Canada m4olivei Grimsby, ON
Found some small thinigs with the code, just nit picks really.
Beyond that, I agree with @plopesc:
I have the feeling that we're just moving the problem to a different place.
Imagine that in the future, we need to add some other config to config/optional we don't want to revert. We would be in the same situation.
We need to consider that in the future, if this module become part of Drupal core, some of the default navigation blocks will not be provided by navigation module, but for other modules. A good example of that would be the ShortcutsNavigationBlock plugin class.
We might need to rethink a bit how to detect which are the "defaults" this button should revert to.
I agree if we go forward with this feature, there needs to be a way to define what is considered "default".
However, ultimately I'm not sure how viable this feature request really is? I'm wondering if there is precedent in core already for this kind of feature. For example, the core node module installs optional config for /admin/content. That's pretty central to the Drupal admin, and can "lead them to make a series of changes that they ultimately regret". There is no UI for reverting that. It would fall to either doing a config import of previously exported config that has the former state, or just rolling up your sleves and manually reconfiguring the view back to what it was.
Lets bring this one to the Admin UI call today to discuss.
- Status changed to Closed: won't fix
7 months ago 1:08pm 6 April 2024 - 🇪🇸Spain ckrina Barcelona
As mentioned in #9, we discussed this feature during that week meeting and agreed on not implementing it on the Navigation module. It's a feature that we don't have is core and that has a potential risk for "breaking" the site, since this would change the main admin navigation. Since there are already ways to implement this revert though configuration, having a UI option for this brings a risk that we don't want to take in this module isolated from core direction. If core start implementing a revert feature through the UI, we'll re-evaluate how we should do it for the navigation.
That said, thanks all for working on this and I'm sorry for not including the efforts invested in here.