MaleusMaleus

Control project access with groups

A group is a set of people plus the projects they can reach. Being a member of the workspace grants nothing on its own: groups are what open doors.

In the appSettings · Groups
On this page

Access in Maleus has exactly two moving parts. A member belongs to the workspace. A group holds members and grants them a set of projects. Nothing else decides who sees what.

The consequence is worth stating plainly: a member who belongs to no group can sign in and reach no project at all. Membership is the door to the building; groups are the keys to the rooms.

Groups live at Workspace settings → Groups.

What a group carries

FieldWhat it does
NameHow the group appears when you assign it, on the member side and the project side.
DescriptionWhat this group is for. Optional, and worth filling in anyway: the next admin is not you.
ProjectsThe projects its members can reach. Leave it empty and the group grants no access.
MembersWho is in it.

Create one

  1. Open Workspace settings → Groups, then Create group.
  2. Name it after the access it grants, not after an org chart. Procurement apps survives a reorg; Marie's team does not.
  3. Pick the projects it opens. You can leave this empty for now and come back.
  4. Add the members, or invite people straight into it from the Team page.

Membership and project access are both managed from the group page. The member row on the Team page does not carry them.

The built-in admin group

Every workspace has an admin group, and it cannot be deleted. Its members reach every project in the workspace, including projects assigned to no group at all. Putting someone in it makes them an administrator of the whole workspace, not just of the projects it lists.

Treat it as the short list it is.

Reading it from the project side

A project's settings show which groups can reach it, with one important note: admins always have access. If no group is assigned, the project says so, and only admins can see it.

That is a reasonable state for a project you are still setting up, and a bad one for a project a team is supposed to be working in. The message on the project tells you which of the two you are looking at.

Removing a group is not reversible: its members lose the access it granted, and Maleus warns you before it happens. Emptying a group of its projects has the same effect on access, and is undoable.

Name groups after the access, keep them few, and let people belong to several. A dozen groups that each grant one project is easier to audit than three groups nobody dares to touch.