Adding affiliation and room information

[Philldomd]

• Adding affiliation to left and join output
• Adding room.jid to log row for Occupant left
• Adding room.jid to log row for New occupant

When using this combined with token_affiliation we would like to get that information by event_sync as well.
When occupants join or leave the log should tell us which room, in larger systems its really hard to connect log rows against specific meetings.

[shawnchin]

Thanks for the contribution @Philldomd

Room jid in log lines make sense.

I'm a little torn re the 'affiliation' user context since it's very specific to token_affiliation, and adding this as a default behaviour increases payload size for everyone. We made an exception for id/name/email since those are documented and would likely be set for most jwt users.

I'm tempted to suggest that we add the new entry commented out to serve as an example, with some additional comment stating "additional fields from jwt user context can be included in the payload e.g. the 'affiliation' field as required by token_affiliation module".

Thoughts @emrahcom ?

[emrahcom]

In my opinion, it would be nice to have the option to add additional context. Commented entry as an example is fine for VM setup but it doesn't help in Docker setup.

By the way I don't think that the payload size is very critical since it still contains small data.

• We can add the whole context. So no need to think about what modules and context fields are available.
  But this duplicates the existing fields.

• We can add the affiliation if it is already exist in the context.

[shawnchin]

fine for VM setup but it doesn't help in Docker setup.

Good point.

We can add the whole context.

A config option to enable that would be nice. Which I'm assuming is easy to set when enabling event_sync in a Docker setup. e.g. include_full_user_context = true to send everything in user context, and default to existing behaviour of just id/email/name if not set.

This is slightly more work that just optionally including "affiliation", but perhaps more useful to a wider audience?

[shawnchin]

@Philldomd Any chance you're willing to take this on?

General idea - Add a module option include_full_user_context that defaults to false. If true, add all fields from user_context to occupant_data, otherwise just include id/name/email as before.

I'd offer to help, but alas I don't work with Jitsi much these days and no longer have a deployment ready at hand to test changes.

[Philldomd]

Hmm sure I could give it a try. I have a jitsi setup. I will reach out if I'm in need of assistance understanding something. Is there an example of plug-in variables in some other files?

[shawnchin]

Thanks for taking this on 🙂

Perhaps take a look at how include_speaker_stats is defined and used in the event_sync module -- that's also a Boolean config variable with defaults.

[Philldomd]

Hi Check if the new addition suits our need better. If include_user_info is set the whole user context is looped over and added to output.

[emrahcom]

I haven't tried it but wouldn't this work instead of looping?

occupant_data = user_context

[shawnchin]

occupant_data = user_context

That could work assuming event_origin.jitsi_meet_context_user never changes and is accessible throughout the duration of the meeting. Never tried. 🤷🏽

If that works, then my comments above should be ignored and we can set occupant_jid, joined_at, left_at later.

[Philldomd]

I was uncertain lua would handle the conversion if any. But I could try data = context . Would it handle if user_context contains another map when using = here?

[Philldomd]

I haven't tried it but wouldn't this work instead of looping?

occupant_data = user_context

Would lua create a hard copy?
What happens otherwise if we add to the original context

[shawnchin]

That was indeed my concern. occupant_data = user_context is not going to make a copy of the table, so if the original table changes or gets destroyed then this won't work the way we expect it to.

My main concern would be whether that data is still accessible when the user session is gone but we still need that information for the muc-room-destroyed event.

Would be interesting to find out if you have a deployment you can test this in.

[Philldomd]

My concern was the addition of fields that might interfere in other parts.
We do add occupant_jid and timestamps that would also be added to user_context

[shawnchin]

Excellent point. We definitely shouldn't modify existing user_context.

I'm assuming you've test this all locally and the payload is as expected with and without that new option?

[Philldomd]

I can do the smal changes you suggested and run it one more time tomorrow, with and without include_user_info

[shawnchin]

Thank you Philip. Appreciate your effort on this.

[Philldomd]

include_user_info: false

2026-02-27 10:05:03 muc.meet.jitsi:event_sync_component              info       New occupant in room: fk_test@muc.meet.jitsi - 
{
	"occupant_jid":"f8268548-80b8-4d9c-90c6-9d34e0f921a4@meet.jitsi/91COYvL_UzNG",
	"joined_at":1772183103,
	"name":"Philip"
}
2026-02-27 10:05:04 muc.meet.jitsi:event_sync_component              info       Occupant left in room: fk_test@muc.meet.jitsi - 
{
	"occupant_jid":"f8268548-80b8-4d9c-90c6-9d34e0f921a4@meet.jitsi/91COYvL_UzNG",
	"joined_at":1772183103,
	"name":"Philip",
	"left_at":1772183104
}

include_user_info: true

2026-02-27 10:07:41 muc.meet.jitsi:event_sync_component              info       New occupant in room: fk_test@muc.meet.jitsi - 
{
	"occupant_jid":"b5ad11b3-13d7-43c8-90a3-dfa6f53304b1@meet.jitsi/gd3WNZ_zFPs-",
	"joined_at":1772183261,
	"lobby_bypass":true,
	"name":"Philip",
	"affiliation":"owner"
}
2026-02-27 10:07:43 muc.meet.jitsi:event_sync_component              info       Occupant left in room: fk_test@muc.meet.jitsi - 
{
	"occupant_jid":"b5ad11b3-13d7-43c8-90a3-dfa6f53304b1@meet.jitsi/gd3WNZ_zFPs-",
	"left_at":1772183263,
	"joined_at":1772183261,
	"lobby_bypass":true,
	"name":"Philip",
	"affiliation":"owner"
}

Tested and commited with changes