Unable to customize _create_event_button.html to hide the button to non logged users

Dear community,
I did some customization on my 3.2.6 Indico successfully (eg. the login page). Now, following the suggestions found in the past threads, i created a customized _create_event_button.html with this inside:

{% extends '~events/management/_create_event_button.html' %}

{% macro create_event_button(category, classes="", text="", with_tooltip=true) %}
 {% if category.can_create_events(session.user) %}
    <a href="" class="{{ classes }} i-button arrow js-dropdown"
       {% if with_tooltip %}title="{% trans %}Create event{% endtrans %}"{% endif %}
        {{- text -}}
    <ul class="i-dropdown">
        <li>{{ create_event_link(category, 'lecture', _('Lecture')) }}</li>
        <li>{{ create_event_link(category, 'meeting', _('Meeting')) }}</li>
        <li>{{ create_event_link(category, 'conference', _('Conference')) }}</li>
 {% endif %}
{% endmacro %}

The Customization debug told me that the template “is customized” but connecting to indico (without having logged in) the buttons appear… we’re I’m wrong ?

It’s not possible to hide the top menu ‘Create event’ item with a template customization. The top menu items are defined in Python code, the macro you’re looking at is only used in other places such as the category toolbar.

So unfortunately there is no good/easy way to hide this button.

Thanks for the prompt reply, but I don’t understand the ratio behind having menu items for actions that a user will not be able to do, especially when the rights could be simply verified before building these items.
I think (correct me if I’m wrong) that 99% of users of an indico platform will not create a conference/meeting and will never be accounted to do it, so why having a UI for this in the “normal user” pages ? Maybe I’m loosing something.

Could you point me to the relevant code for manage that buttons in python code ?
Just to be clear, I think that Indico it’s a very good piece of software, but some choices are unclear to me, i.e. not having a negative input for money (which could represent a “discount”). If I’m not wrong, a plugin could not change this behaviour, which seems to me being harcoded too.

Thanks again.

Note that you do not have access to the current category there. However, if you have a way to determine whether the user is someone likely allowed to create events or not you could use that to (not) show those sections. This is not something that can be easily done from a plugin though, so you’d need to build your own Indico package…

You can choose the category in which to create your event, even if the current one does not allow you to create events. So it makes sense to always show those buttons. Checking if the user is able to create events somewhere is not feasible in larger instances which can have thousands of categories, and rely on LDAP or similar groups to determine if one can create events there.

PS: Most normal users who just attend an event do not need an Indico account at all! You can register for an event without one (unless the event restricted or requires you to login to register). Only those who want to submit abstracts or (as speakers) upload slides etc need an Indico account. So the majority of your normal users shouldn’t even create an account…

Actually, the “Create Event” is rendered even if you are not logged in. I guess this could be a candidate for a patch…

Yes, and you will be asked to log in, and then the event creation dialog opens. I’m pretty sure some of our users would not appreciate a change to this behavior…

Thanks for the hints. I’m aware that attending does not require an Indico account, but this confirms to me what I said, why having a “create - something” showed to anyone (logged in or not) if they will not able to create anything ?

For the custom package, it’s not a problem as we’re doing the full Italian language which actually it’s not distributed, so I’ve my dev installation for building it.

The same logic you suggested for overriding the template could not be applied wide in the code ? Obviously you’re the expert, I don’t know Indico code in deep. Mine are just thoughts out loud.

For your use-case:

def _topmenu_sections(sender, **kwargs):
    if session.user:
        yield TopMenuSection('create-event', _('Create event'), 90)

should work for hiding the top menu entry (probably add the same check to the items) from non-loggedin users.

Yes, it would need a config flag as well. But I agree that this is not really high priority currently.

This worked for me: I did a little change adding

def _topmenu_sections(sender, **kwargs):
    if session.user and session.user.is_admin:
        yield TopMenuSection('create-event', _('Create event'), 90)

but I had to add the same line to

def _topmenu_items(sender, **kwargs):
    if session.user and session.user.is_admin:
      yield TopMenuItem('create-lecture', _('Create lecture'), 'lecture', 30, section='create-event')

to avoid a critical runtime error.
The choice to restrict to admins only is because we’re thinking that in our scenario only admins will create events.
So the first half seems ok to me; now the second half… As I wrote in the OP, the customization seems not applied even if in the indico.log I got this:

DEBUG    030f95d8393c49ec  -       indico.customization      Customized: core/events/management/_create_event_button.html

any change that I do to the macro in the customized file it’s not reflected anywhere. Indeed, changing the original file ( ~indico/.venv/lib/python3.9/site-packages/indico/modules/events/templates/management/_create_event_button.html) e.g. adding a XYZ string to the text, that change appears (after a restart of indico services).

I’m doing anything wrong in the customized file that prevents the other templates to use the extended macro ?

Hope I was clear.