Permissions changes in version 3.1.1
We just released version 3.1.1, which by the looks of it is a minor release – but with an important detail worth knowing about. Version 3.1.1 fixes an existing permissions bug that would have caused items to be invisible / inaccessible when they weren’t supposed to. If, after you update, projects, issues and articles starts showing up for users where they were previously invisible – a permissions issue has been fixed on your installation.
So – what is this permissions bug? Let’s try and explain it in simple terms.
The permission system used in The Bug Genie works on two “levels” (disregard the group/user/team access – that’s not the levels we’re talking about😉 ) – a permission, such as “Can see project” can be set for a specific project (represented in the database with target_id = project_id), but can also be specified with no target, in which case it means “Can see all projects”. This can all be done in the permissions configuration section, and the “no target id” permissions are visible in the “General permissions” tab; there is a separate tab for “Project-specific permissions”. The bug manifested itself whenever a specific target_id had been set for a permission – which meant in almost all cases, as most permissions operate on a specific item, such as a project. What happened was that if a permission had been set for a specific target, The Bug Genie never proceeded in the access check to see if a “general”, “can see all” permission had also been set. This meant that even if your user had access to all projects because of the “Can see project” permission being set for “all projects”, it wouldn’t actually work as soon as a “Can see project” permission had also been set for a project. Bad The Bug Genie. Bad, bad.
In any case – this means some items will start popping up now, where they were previously invisible. This is not a configuration error or a permissions flaw – it is actually the permissions system working as intended! If this happens, use the permissions configuration section to set a more detailed permissions set or even change the security mode between permissive and restrictive – whatever fits your setup.
We hope the fix proves to work out to the better – after all, this is how the permissions system was intended to work. This bug most likely caused a lot of other permissions bugs to manifest, as it affected most areas of the system. Don’t revert to 3.1 just because stuff “suddenly” becomes visible – use the permissions configuration section to set the permissions level desired.
Now, let’s get this weekend started!