People Groups

People Groups

Where: Tickets → Users → Groups Table: knowledge_user_groups (+ knowledge_user_group_members)

A named group of people, holding analysts and self-service portal users together. Made once, used across FreeITSM: give it access to a knowledge folder, or assign it an LMS training course, without building the same list twice.

---

Why they exist

Before this there was no way to group portal users at all. Analysts could be grouped three ways over — teams, LMS learning groups, morning-check groups — but the people who use the service desk could only be addressed one at a time.

That mattered as soon as anything needed to reach a set of them: granting a folder to the three engineers on site this fortnight, or pushing security-awareness training to the finance team.

The table already existed

This is worth knowing if you go looking, because the history is confusing.

knowledge_user_groups shipped with the Knowledge access lists. It had everything — polymorphic membership (an analyst or a portal user), a per-member expiry, membership resolution, enforcement, a passing test, and a "Group" row in the folder permission picker.

What it never had was a way to make one. The only INSERT anywhere in the product was inside its own test file. So on every installation the folder picker offered a kind of principal that could not exist, and searching for one could only ever answer "nothing found".

The Groups tab is that missing screen. Nothing about the access model changed when it was added.

Why the table still has a knowledge_ name

It is no longer a Knowledge thing, and the name is now historical. It was deliberately not renamed:

Database Verification only ever creates tables. Under a new name it would make an empty one and leave the populated one orphaned beside it — every membership on the installation would silently stop granting anything, with a green tick on the verification screen. The lookup that resolves membership catches its own error and reads a missing table as "no groups yet", so nothing would report the loss either.

A slightly odd table name is the cheaper of the two problems, and it is invisible to users.

---

Making a group

1. Tickets → Users → Groups, then Add.
2. Name it, and write a description. Worth doing: a group can be given access to a knowledge folder, so the next person needs to be able to tell what it is for.
3. Add people by searching for them. The search finds analysts and portal users together, so you do not have to know which kind somebody is before you look.
4. Optionally give a membership an Access until date.

Membership changes take effect immediately. There is nothing to re-apply afterwards, anywhere.

---

The end date

The reason the table exists at all.

"Three engineers on site for a week" is the driving case, and an access list that quietly stays open after they go home is the failure worth designing out on day one. So each membership — not the group — can carry a last day. When it passes, that person stops being a member: the access is taken away by the clock, rather than by somebody remembering.

Two consequences worth knowing:

• An expired membership is still a row. It stays on the list, marked as expired, because who had access and until when is worth keeping. It simply stops counting.
• The group's member count excludes expired memberships, and lapsed ones are counted separately beside it. One number would hide the difference, and "12 members" beside a group that will reach nine is how somebody concludes a push half-failed.

Leave the date blank for access that does not end, which is the ordinary case.

---

Who can change one

Anyone with the Tickets module can see the groups. Only an administrator can change one.

This is not filing. Once a group is on a folder's access list, adding somebody to it is a grant of access — made from a screen gated on Tickets, to a folder governed by Knowledge. Without the administrator floor, anyone holding the Tickets module could put themselves into "Payroll" and read it.

It is the same rule the Knowledge access lists already state for editing a list directly, and the same reasoning that put analyst and team management in the System module.

---

What a group is good for

Use	Where
Access to a knowledge folder or article	Knowledge → the folder's access list. See Knowledge Folders and Permissions.
Assigning an LMS course	LMS → Assignments → Who for. See Training for Portal Users.

Both read the same group. A group made for one purpose is immediately available to the other.

---

Multi-company installations

The member list and the search are scoped to the company you are viewing, exactly as the requester list is. A group can legitimately span companies, so anything the scope removes is counted and reported rather than silently dropped — an administrator deciding whether a group is right needs to know it has members they cannot see.

---

See also

• Training for Portal Users — assigning courses to a group
• Knowledge Folders and Permissions — granting a group a folder
• People Groups Developer Guide