User groups now hold project roles

Teams managing access on dozens of projects no longer need to add and remove users one at a time. Create a group under Admin → Groups, add people to it, and grant the group roles on a project just as you would a single user. Everyone in the group gets those roles immediately. When someone joins the group later, they get the access. When they leave, it goes away. The project members tab shows group rows alongside users, and a group row expands to show who it covers and which of them reach the project only through that group.

A person's own roles and those of every group they belong to are combined, so they can still have direct access to projects while also belonging to groups with different access levels. Deleting a group tells you upfront how many people lose access and on how many projects, and anyone who also holds the role directly or through another group keeps it.

Public projects can let visitors read without signing in

If you have public projects that operate more like documentation or a public issue tracker, you can now opt them in to read-only access for anyone, whether or not they have an account. It is off by default and requires two separate decisions: an administrator must turn on an instance-wide switch under Admin → Settings, then opt in specific projects in their settings.

Turning the switch on asks the administrator to confirm the exact list of projects that will become readable. If that list has changed in the meantime the confirmation is refused and shown again, so you cannot accidentally open the wrong project.

A visitor can then open the project list, a project's overview, issue lists, individual issues, the wiki, and search, all without signing in. Everything else still requires an account, and MCP stays API-key only. Visitors see people by display name only, and never see private issues, private notes or attachments. Projects that are private, archived or not opted in stay invisible, and every refusal looks the same, so the responses cannot be used to find out which projects exist. Anonymous reads are read-only, rate limited per IP and never cached. Every change to either setting is written to the security audit log.

Users can change their own password

Until now the only way to change a password was the emailed reset link. Signed-in users can now change it from their preferences. The current password is checked first. Your other sessions are signed out, but the one you are using stays signed in. Wrong attempts are rate limited and audited, and they do not count towards locking the account, so someone holding a stolen session cannot lock the real owner out.

Administrators can require a password change on next sign-in

When creating an account or resetting a password, an administrator can now require the person to choose their own password the next time they sign in. Until they do, they can only see the change-password page. API keys are not affected, so an agent's key keeps working, and the flag cannot be set on a service account.

The Redmine importer now brings groups as groups

In Specivo 0.7.0, Redmine groups were imported as individual role grants on each member, one grant per person per project. Starting with 0.8.0, a Redmine group becomes a real Specivo group with the same people, and a role the group held stays a single grant held by the group. This keeps the structure intact and makes managing access clearer.

When a group's name is already taken or two Redmine groups differ only in letter case, the new group gets a suffix and the report lists it. Existing groups are never reused, because that would give unintended access.

If you are looking at Specivo as a Redmine alternative, the guide to migrating from Redmine covers what the importer carries across, what it reports instead of guessing, and how to run it against your own instance.

Security fixes

Issue autocomplete no longer reveals private issues. Any project member could find the key and subject of every issue in the project through autocomplete, including private issues they could not open. Autocomplete now applies the same visibility rules as the issue list. This affected members with any role, including the built-in ones.

Search respects role permissions. A member with a custom role lacking View issues was refused an issue by the API but still got its subject and description snippet from search. Search also previously returned every wiki page for a role that granted nothing at all. Search now checks the same permissions as the rest of the application. Only custom roles were affected.

Private subprojects are no longer listed on the parent's page. Any signed-in user who could open a project saw the names of all its children, including private ones they could not open. The overview now shows only the children the reader can access. Administrators still see all of them, as they did before.

Relations now require the right permission. The REST API let anyone who could read two issues link them, with no permission check at all. The same went for deleting: a member of one project could delete a relation from one of its issues to a private issue elsewhere. Both now require Manage issue relations, just as the MCP tools already did. The seeded Manager, Developer and Agent roles carry this permission. A custom role that has Edit issues but not Manage issue relations can no longer add or remove relations.

What to check when upgrading

Since access is now decided by roles alone, members whose custom roles lack View issues will lose access to issues everywhere, including search, autocomplete and MCP. None of the seeded roles are affected. If you have custom roles, check their permissions before upgrading.

Signed-in non-members of a public project now pass View issues checks everywhere the issue list already let them in (sprints, versions, recurring patterns, reactions, MCP). Signed-in non-members no longer see a public project's wiki pages in search. Opening a project's wiki no longer creates its Home page unless the reader can manage the wiki. Private notes no longer appear in comment search for anyone but administrators.

Adding or removing relations now needs Manage issue relations, so custom roles without it lose the ability. The relation controls are hidden from anyone without the permission.

The MCP specivo_remove_relation tool only removes a relation attached to the issue passed as issue_ref; a relation ID belonging to another issue is answered as not found.

Migration note: The upgrade stops with an explanation if an existing account already uses the login $anonymous. This is the reserved anonymous user account. If you have such an account, rename it before upgrading. Back up your instance first.

Translations

Messages, confirmations and placeholders in many interactive parts of the interface were stuck in English even on translated pages, and the new screens for groups, members, tags and password changes were not translated at all. Spanish, French, Russian, Thai and Chinese are complete again, and the interface follows the language you chose.

How to get it

Pull the Docker image with docker pull specivo/specivo:0.8.0. For servers without internet access, the GitHub Release includes an offline bundle. For installation and upgrade steps, see the user guide.