See what is on the calendar next month

EventsBeginner~5 min

Before you start

The Events Calendar 6.17.3.1 or newer active on the site, with the four event read abilities enabled. A connection bound to a user who can read events is enough for published ones; drafts and pending events need a user with edit access to events.

The calendar has a month’s worth of things on it, and finding out what they actually are means clicking into each one. The listing gives you titles. The venue, the organizer, and the real start time all sit one screen deeper, per event.

This prompt does the clicking. It reads the calendar, follows each event through to its venue and organizer, and hands back something you can forward to a colleague. It writes nothing.

The prompt
Give me a briefing on what is on our calendar for [next month]. Read only,
change nothing.
Start by listing the events on the site so we can see what falls in that
window. Then read each of those events in full so you have the real start and
end times rather than just the title.
Pull the venue list and the organizer list as well, and use them to fill in
each event: where it is happening, and who is running it. If an event has no
venue or no organizer attached, say so instead of guessing.
Finish with a plain dated list, earliest first. For each one give me the title,
the date and time, the venue with its address if there is one, and the
organizer. At the end, flag anything that looks unfinished: no venue, no
organizer, or a start time that looks wrong.

Why this is safe to run

All four abilities are reads. Listing events, reading one event, and pulling the venue and organizer lists return what the calendar already holds and cannot alter a date, a location, or a status.

What you see is bounded by the user your agent is bound to. Published events are visible to any reader, but a draft or pending event only appears if that user can edit events, and a private one needs read-private access. That is a feature here rather than a limit: bind the agent to a low-privilege user and a briefing prompt sees exactly what a visitor to the public calendar would see.

Worth knowing about the plumbing, because it decides how accurate this is. These abilities run through The Events Calendar’s own ORM, not its REST API and not the older creation wrappers, so an event that the calendar plugin considers real is the one you get back. That also means they need The Events Calendar 6.17.3.1 or newer to be active. Without it, the abilities are simply not there to enable.

Already connected? Skip the paste. Ask your agent for the “see what is on the calendar next month” recipe, or just ask what is coming up and where, and it runs the same reads against your own calendar.

How it works

  1. List the events on the calendar so you can see what falls in the window you asked about.
  2. Read each one in full to get its real start and end times.
  3. Pull the venue list so a location id turns into a place with an address.
  4. Pull the organizer list so each event gets a name attached to it.
  5. Read the whole thing back as a dated briefing, with anything missing called out.

Questions

Will this show me draft events as well as published ones?
Only if the user your agent is bound to can already see them. The events read defaults to published, and asking for drafts, pending, or scheduled events requires edit access to events, scoped to that user's own unless they can edit other people's. A private event needs read-private access. So a least-privilege connection gets the public calendar, which is usually what you want for a briefing.
Does this touch The Events Calendar's REST API?
No. These abilities are built on the calendar's own ORM, the same tribe_events, tribe_venues, and tribe_organizers repositories the plugin uses internally, so what comes back matches what the plugin itself considers an event. Nothing is written, and the calendar's REST routes are not involved.
Can it change or reschedule anything it finds?
Not with this recipe. Every ability listed here is a read. Creating, updating, and trashing events are separate abilities with their own capability gates, and they stay off unless an administrator switches them on.