Propose new functionalities for Decidim software
#DecidimRoadmap Designing Decidim together
@verarojman asked on gitter whether it was possible to somehow remove menu items through the decidim.rb initializer. I investigated a bit and it looks like the menu subsystem is append-only at this point.
It is possible to hide them using CSS/JS hacks, but that's obviously brittle and can have unexpected consequences.
Being able to edit the menu through the initializer (or through the admin dashboard) seems like a sensible expectation from Decidim instance maintainers, to me. And from what I could tell, it's viable to extend the menu subsystem to allow for this within its current architecture.
Not sure how high a priority this would be, of course. Nor how common this demand is.
What do you all think?
Update
@microstudi suggests this should be done in a third-party module, and said his team might work on it at some point.
Report inappropriate content
Is this content inappropriate?
11 comments
Conversation with Xabier
Hi. I don't see the rationale for this feature. I am not sure about the general top menu. But for the case of participatory-space menus (processes, assemblies, etc.) I see several risks. Among them is the risk to manipulate a democratic process by hiding components (like proposals) o survey for wich, nevertheless only selected users might have access by direct url. I cannot see the benefits and I can see severe risks to this proposal. But maybe I am wrong or I am missing some important features.
Hi! I'm fully agree with you @xabier. You're not wrong, you need more context. In @platoniq we are working in a project which we are adapting decidim for an academic online workshop. Also, this project won't need any maintenance because the installation will use one version. So, this is an specific project which use decidim' software. In any case we pretend to extend this feature in decidim master :)
WE NOT*
Conversation with Oliver Azevedo Barnes
I probably need more context to understand what is at stake here. My assumption was that admins have the power to customize the app anyway, and that Decidim aimed to be as flexible as possible.
But come to think of it, perhaps the system user is the one that's all powerful, and an admin might be somebody with circumscribed power to ensure democratic processes aren't tampered with after a Decidim instance is installed?
In that case, the admin dashboard would definitely not be the place to do this, and the decidim.rb initializer would (only the person deploying the code would have access in this case).
But I'm still a little confused, though, since an admin already can currently add and remove components through the admin dashboard.
In any case, this is all useful for me to better understand Decidim's intent and design :)
I like your thoughts and comments.
I am not sure if "as flexible as possible" is the best criterium to drive Decidim's evolution, Drupal might be better for maximum flexibility. But even if we aim for flexibility it should always be within the limits of what is good for democracy. Sure, sysadmin with RoR programming capacities could potentially do anything (but they must also make the code available by AfferoGPLv3). Admins should be able to configure with different degrees of detail but should always have limited freedom to manipulate or distort democratic processes (e.g. last time I checked an admin could not remove a proposal component with proposals inside).
I would say that, in general, although the code can always be modified, we should alway aim for the less manipulable flexibility, both for the sysadmin and the admin.
Thanks Xabier, that makes total sense. I didn't quite have Drupal-level flexibility in mind, but flexibility relative to Consul, for example, in implementing democratic processes. I assumed admins customizing navigation would be a normal part of that, of process design and customization.
I understand the concern with opaque change to user flow mid-flight, during ongoing processes. It's a thorny, interesting problem for sure. If there are any resources (docs or threads) elaborating on Decidim's recommended approach here, I'd love to read up. By the way, does Decidim have an audit trail of configuration changes done by an admin?
With the case in point here, it does sound like removing menu items in the admin dashboard is a bad idea, unless there's safeguards and an audit trail in place. But if code level customization by a system user is also deemed risky, what is the preferred path to safely customizing navigation for legitimate reasons? Creating a module, forking Decidim?
> By the way, does Decidim have an audit trail of configuration changes done by an admin?
Self-responding: Looks like it does, @coditramuntana pointed me to the admin activity log on the admin dashboard
@xabier is right (as usual) but let's take into account that nothing stops an admin to "hide" a proposal component for instance, they just have to unpublish it, regardless of having proposals or not in it.
There's also the ability to create "private" participatory spaces which means that are places that are "hidden" if you don't know the URL.
I my view, the ability to manipulate the menu is more about customizing the items non related to components: changing titles, changing the order, adding additional items and yes, in some cases remove them, for instance the help pages if you don't need them.
That being said, I think this is a job for a module (and we will probably develop something for it when we have the time)
@oliverbarnes We've made a module to add items : https://github.com/OpenSourcePolitics/decidim-module-navbar_links
As Ivan said you can hide menus with css customization.
Hope it helps.
Hi @virgile_deville, thanks - I did check this module out, somebody mentioned it on gitter too as a possible starting point.
About css/js customizations, I suggested that to Vera on gitter to quickly solve her problem. But long-term I think that's a brittle solution. They can easily break with updates, and can break other things on the interface unexpectedly. This is the main thing that drove me to open this thread to discuss possibly allowing for this to be customizable instead.
We always add custom menu items to point people towards the specific pages where they can participate and we often remove the Processes menu because the platforms often start with one process and it doesn't make sense to keep it. OSP's module to add links is really useful but it would be really great to be able to hide the default menus. Another solution would be to replace Processes with a button to the process when there is only one.
As the others said, there are so many other ways content can be censored or hidden, not giving the possibility to customise the top navbar is irrelevant...
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...