Teams

minor bug fix

XenTeams 1.1.2 - Discussions, Private teams + footer cleanup

This is a big update bundling everything since 1.0.x. Three things landed:

🆕 Team Discussions (1.1.0)
Team leaders can now start "Discussions" inside their team. Each discussion is published as a real forum thread in the forum of your choice, so:
- Team conversations are visible to the wider community.
- Replies happen on the forum with full native XenForo tooling (search, alerts, reactions, moderation).
- Each team builds its own thread history without you having to create per-team forums by hand.

This was the most common piece of feedback, "make Teams feel connected to the forum, not isolated".

🆕 Private / Hidden teams (1.1.2)
Team leaders can now mark a team as private. Once private, the team:
- Disappears from every public listing (Top, Recent, search results, sidebar widget).
- Stops counting in public stats.
- Is only visible to its members, to users who received an invite, and to admins.
- Cannot be applied to from outside (it's invisible to non-members).
- Can still be invited to. Invites give the invited member access automatically.

Toggle the new "Private team" checkbox when creating or editing a team. Existing teams stay public by default.

🧹 Fixed: duplicate XenSupport credit in the footer (1.1.1)
Removed an older footer credit injection that was firing alongside the consolidated one. If you had several XenSupport add-ons installed, your footer was showing two "XenForo add-ons by ©XenSupport" lines. Now you'll see exactly one, no matter how many XenSupport add-ons you have.

Drop the new files in and run the upgrade from the Admin CP. The schema upgrade is idempotent and safe to re-run.

XenTeams 1.0.22 — Release notes
New feature
Edit announcements: announcements can now be edited after posting. A pencil icon appears next to the existing pin and delete buttons (visible to the announcement author, team managers, and admins with bypass). The form is pre-filled with the existing title and message. The "edited" indicator shows up automatically once a change is saved.
Bug fix
Fixed: events disappearing right after creation. Symptom: a freshly-created event would appear briefly on the team page, then vanish on the next refresh or page interaction (e.g., clicking "Accept" on a pending application).
Root cause: the date-clamping logic introduced in 1.0.20 (designed to prevent year-30000 spam events) had a subtle race condition. When a submitted date was older than now - 24h, it was silently clamped to exactly now - 86400 at the moment of save. But the upcoming-events listing filters on start_date >= now - 86400, where now advances every second. A few seconds after save, the new now - 86400 cutoff was after the saved start date, so the event fell off the listing.
Fix: the lower bound clamp has been removed. Dates are now saved as the user submitted them. The upper bound (no events past now + 5 years) is still enforced to prevent integer overflow / spam. If a user creates an event with a date in the past, it simply won't show in the "Upcoming events" section — which is the expected natural behavior. The event still exists in the database and is accessible via direct link.