Reply to: tickets(404045)

Hello,

Please add this CSS code to EventON > Styles (If you don’t see any change, EventON > Scripts & Styling > turn off Write dynamic styles to header > save settings > turn on Write dynamic styles to header).

You can also add this code to wp-admin > Appearance > Customize > Additional CSS.

.tax-event_type .evotax_term_card { display: block !important; padding: 0; margin: 0; } .tax-event_type  .content { width: 100% !important; float: none !important; } .tax-event_type  .evo_card_wrapper .evo_sidebar { margin: 0; flex: 1 1 30%; } .tax-event_type  .evotax_term_card .evo_card_wrapper { display: flex; }

Reply to: tickets(403906)

Ah okay, thank you! We completely misunderstood where the button was more. Maybe for in the future, it could nice to name the button ’go to current month / ga naar huidige maand’. 

Thanks! 

Reply to: tickets(404054)

Hello,

Thank you for your great suggestion, at the moment it is not supported. However please create a new ticket and select Feature Request as category so others can vote on your idea and get it moved into development faster.

You can add the list manually using Custom Meta Fields:

https://docs.myeventon.com/documentations/setup-use-custom-meta-fields-events/

Reply to: tickets(404055)

Hello,

Thank you for your great suggestion, at the moment it is not supported. However please create a new ticket and select Feature Request as category so others can vote on your idea and get it moved into development faster.

Reply to: tickets(403019)

We are glad your issue is resolved, if you have any further questions or concerns please create a new ticket.

Reply to: tickets(403967)

Thank you for the clarification on the capability requirement — i do not understand your reasoning but i thank you for approving the workaround! Happily awaiting your fix for assigned users.

————————–

If you are still up for discussion:

We do NOT want to give Contributers the permission to ”Edit Other Users events”. This is a much to broad permission. Isn’t that specifically what you developed the ”assigned user” function for? As an override to that?

I do not unterstand your reasoning, because your settings clearly state:

“Allow event assigned users to see event in event manager” — visibility

“Allow event assigned users to edit those events in event manager” — editing

Both are ON in our case of course. Both promise the admin: turn this ON, and assigned users will be able to view/edit. No mention of additional capabilities required. Especially not requiring way too broad a permission. Or to view it from antoher angle: If ”edit_others_eventons” is required anyway to view assigned events, then these two settings are functionally useless. A user WITH ”edit_others_eventons” can already view and edit all events — they don’t need the “Assigned User” feature for that. ???

—————————–

Perhaps do mind however the two small issues that OPUS 4.6 found, that are unrelated to the capability discussion but might be valuable for your next release:

1. In class-event_manager.php (v2.5.13), lines 138 and 141 inside get_user_events(): break should probably be continue. Currently, if a user has edit_others_eventons but lacks edit_published_eventons, break terminates the entire foreach loop — all remaining events after the first published one are silently dropped. 

2. In class-functions.php, user_assigned_toevent() (line ~244): the $userid parameter is never checked against the assigned users list. The function fetches all WordPress users via get_users() and returns true if any user’s ID matches any assigned slug — regardless of which $userid was passed. This means can_currentuser_edit_event() and can_currentuser_delete_event() may grant access more broadly than intended.

Just flagging in case it’s helpful. Thanks for the great plugin!

Stephan