Would someone know, how to display future events (conferences, meetings etc) for the forthcoming X months on the main landing site ? I have been looking through all the documentation and would be grateful for any suggestions !
many thanks
The “upcoming events” section should show you the events that are coming up. You can configure those in “Admin > Homepage”.
Thanks for the quick response !
Hmm … that is not exactly what I was hoping for … ideally it would be nice if the event in the future is showed (and not displayed as "upcoming event in the right column.
Not sure the uploaded png works.
many thanks
Vikram
Ah, right, I didn’t understand that your main category contains events directly. No, there’s no way to configure that. But having a way to override the default behavior could be an option.
I agree, especially in categories with a smal number of events this would be helpful.
It looks like the categorie settings are easy to extend with 2 timedelta fields.
I could probably provide a pull request for that.
Hmm, looking at the code once again, maybe it is better to just have boolean options for
show_all_future_events/all_past events?
Another thing I found now: the past-events selection is at least kept per user-session, while the future-events setting is always transient.
Yeah, that happens basically for historical reasons. I agree we should have ways to override the behaviour if needed, but making the default strategy a bit smarted wouldn’t hurt.
While I initially thought this would be straightforward, it turns out there are quite some questions to consider:
- harmonize user side handling ( probably best solution: add handling for future events like for past events)
-> can be done without db changes - Allow to make the time increments used configurable (on the category)?
-> probably possible without db changes, as category settings seem to be stored in a singel JSON field - Just use flags to force-show future/past events (on category)
-> probably no db changes needed - Add flags to events to force-show them independet from the default logic (this may be nice if you have one far-future, but important event in a busy category.
-> This would definititly be a more invasive change witha db migration… - Always show ‘active’ events (where active means: registration/abstract submission/survey is open)?
(1) is quite easy, basically replicating what we already have for past events (search for show_past_events and fetch_past_events_in)
(2) without DB changes would work (we have a CategorySettingsProxy), but it would make the code when editing a category’s settings more complex since it would then have to mix stuff stored in Category and stuff stored in settings and handle both of them properly when saving… so maybe adding new columns would be the better choice
(3) not sure if that’s very useful to be honest… I think it should be up to the user, especially since there is already a user-level setting for the default
(4) I think this would be a pretty good solution, but it also needs further discussion: Would an event manager be able to set this? Or just category managers (in that case possibly from the list of events within the category management area).
(5) would have to be configurable for sure, otherwise it may be a mess depending on the category.
I think this would be the best solution. I like the idea of “promoting” events.
1 Like
(1) harmonize user side handling ( probably best solution: add handling for future events like for past events)
Pull 3233 should address (1)
1 Like
Wow ! many thanks. So I guess, the easiest would be to update to a newer version … many thanks …
This change will most likely go into Indico 2.1, so you’ll still have to wait for a bit.
Note that the current change only allows users to show future events by default (the default for existing and new users will still be to not show them), and if a user shows future events in a category this will be kept until their session expires or they log out.
The other feature of being able to “promote/highlight” events has not been developed yet, so it’s unlikely to be in any version before 2.2 (later this year)
thanks Adrian, it would be enough to let our users know that this is partially implemented in the 2.1 version ! 