Feature request: "Speak up" / Shoutbox — let employees post call-outs to colleagues, with comments and emoji reactions

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Feature request

Is your feature request related to a problem? Please describe.

Today IntraVox is mostly a top-down medium: editors publish pages, and the rest of the organisation reads them. There is no place where an ordinary employee can simply ask something of their colleagues — "does anyone have a spare monitor arm?", "who is joining the Friday walk?", "looking for someone with Power BI experience for a short review". Those calls currently end up in e-mail to everybody, in a chat channel that not everyone is in, or nowhere at all.

Describe the solution you'd like

A "Speak up" section (working title, internally referred to as Shoutbox) where employees can post a short call-out to their colleagues.

Core behaviour:

• Anyone can post. Any employee with access to the section can create a message — no editor role required.
• Everything is public within the intranet. Messages are visible to everyone who can see the section.
• Published immediately. No moderation queue, no approval step — a post appears in the feed the moment it is submitted.
• Comments. Others can reply with comments on a message. Comments are also published immediately.
• Emoji reactions. Besides commenting, colleagues can react with emoji — the low-effort way to say "me too" / "thanks" / "nice" without adding noise to the thread.
• Pull, not push. Employees read the feed on their own initiative. No push notifications, no e-mail digests, no activity spam. The section is something you visit, not something that chases you.
• Optional tag/label. The author may optionally attach a tag/label to their post (e.g. Question, Offered, Wanted, Social), so the feed can be scanned and filtered.

The feed itself is reverse-chronological: newest post on top, with its comments and reactions underneath (or behind an expander, to keep the overview scannable).

Describe alternatives you've considered

• Nextcloud Talk. Works for conversations, but it is push-oriented and channel-based; you have to be a member and it is a separate app, so it does not surface on the intranet homepage where people already are.
• A regular IntraVox page that everyone may edit. Technically possible, but it turns a call-out into a page edit: no ordering, no per-message comments, high risk of people overwriting each other, and it requires edit rights on the page.
• Using the existing comments on a single page. Closer, but a flat comment list has no first-class notion of "a post", no tags, and no separation between "my call-out" and "a reply to someone else's".

Additional context

Some notes on how this could fit the existing architecture — not a prescription, just to show it does not need much new machinery:

• Comments and emoji reactions already exist in the app. lib/Service/CommentService.php already implements comment CRUD and reactions on both pages and comments (getPageReactions(), addCommentReaction(), …). A shoutbox post is essentially a small user-generated item that reuses that same comment + reaction layer.
• The natural shape is a new widget type (e.g. shoutbox), alongside the existing news, people, feed, photo-story widgets, so an admin can drop it on a homepage or a dedicated page and configure it (which tags are available, how many posts to show at a glance).
• Because posting is open to all employees while page editing is not, the permission model needs an explicit decision: who may post (everyone with read access to the page?), who may delete (author + admin, matching the current comment delete rules), and what happens to a post's comments when the post is removed.

Open questions worth settling before implementation:

1. Is the tag list free-form (author types anything) or a fixed set configured by the admin? A fixed set keeps the feed filterable; free-form drifts.
2. Do posts expire or get archived after a while? A call-out for a spare monitor arm is stale after two weeks, but the "no push, pull only" design means nobody is nudged to clean up.
3. Should there be any lightweight abuse handling (report/hide), given that everything is published instantly with no moderation?

Start by reading lib/Service/CommentService.php, especially its page and comment reaction methods, then inspect the existing news, people, feed, and photo-story widgets. Define how a shoutbox widget, posting permissions, deletion, comments, reactions, tags, expiry, and abuse handling should fit the architecture; done means those open questions are settled and the feature scope is implementable.