### Steps to reproduce:
event = env['event.event'].create({
'name': 'Repro Event',
'date_begin': '2026-09-01 08:00:00',
'date_end': '2026-09-01 18:00:00',
})
ticket = env['event.event.ticket'].create({
'event_id': event.id,
'name': 'VIP',
'seats_limited': True,
'seats_max': 1,
})
env['event.registration'].create({
'event_id': event.id,
'event_ticket_id': ticket.id,
'name': 'Attendee 1',
'state': 'open',
})

ticket.seats_available -> 0
ticket.is_sold_out -> True

result = ticket._get_current_limit_per_order(event=event) print(result) # {ticket.id: 30} -- expected {ticket.id: 0}

### Issue and Expected
`_get_current_limit_per_order()` used `if not seats_available:` to detect the "no limit" case returned by `_get_seats_availability()`. That check is truthy for both `None` (genuinely no limit) and the integer `0` (fully booked), so a sold-out ticket/slot combination was incorrectly treated as unlimited and returned `limit_max_per_order or EVENT_MAX_TICKETS` (e.g. 30) instead of `0`.

### Fix
`_get_seats_availability()` explicitly documents `None` as the "no limit" sentinel, with `0` meaning "constrained, zero seats left". Use `seats_available is None` to preserve that distinction instead of a falsy check.

No functional regression was found in the current website_event flow: sold-out slots/tickets are filtered or re-derived independently before reaching this value in every existing UI path. This fixes the underlying contract of the method itself, so future or additional callers don't inherit the wrong value.

https://github.com/odoo/odoo/issues/284098




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284100

Problem:
The bookings calendar of an appointment type opens on the week of the most
distant booking instead of the next one, even when a booking exists later the
same day.

Cause:
`action_calendar_meetings` sets the landing date from `appointments[0].start`,
where `appointments` is `self.meeting_ids.filtered_domain(domain)`.
`calendar.event` is ordered on `start desc` and a one2many is read in the order
of its comodel, so the first record is the furthest booking rather than the
next one. The original `search([...], order='start')` was replaced by the
one2many in 14b5caccc325 (odoo/enterprise#23191).

Solution:
Sort the filtered bookings on `start` in `action_calendar_meetings`. That
method is the only place the initial date is built, and
`action_calendar_event_view_request` reuses it for the gantt start date, so
both entry points are covered. `calendar.event` keeps its `start desc` order,
which the booking list views rely on.

Steps to reproduce:
- Go to Appointments.
- Open the appointment type "Schedule a Demo" and click Appointments.
- Click New, set the date to later today, save and go back.
- Click New, set the date to one year from now, save and go back.
- Go back to Appointments, reopen "Schedule a Demo" and click Appointments.
- Switch to the calendar view.
- Observe that the calendar opens on the week of the booking one year from now.

Ticket [link](https://www.odoo.com/odoo/project.task/6480029)

opw-6480029

Forward-Port-Of: odoo/enterprise#129000