Allow project admins to draft changes to project page, but only site admins are able to publish the changes.

Granular Permissions Settings for Admins: Porirua City Council and Western Bay of Plenty

What It Is:

Granular Permissions Settings provide more detailed control over who can access, modify, or interact with specific content within a project, consultation, or platform. This enhancement is focused on giving project admins more flexibility to assign and manage permissions beyond the basic roles like “Project Admin” or “Viewer.” This request aims to introduce more detailed, role-based access control, allowing councils like Porirua City Council and Western Bay of Plenty to assign permissions more effectively based on staff responsibilities.

Both councils have identified issues with the current permissions system, particularly with the broad and insufficiently nuanced access granted to users. With granular permissions, admins can define precise access controls, such as allowing staff to view reports or respond to public comments, while preventing them from making changes to project content.

Why It’s Useful:

1. Enhanced Control Over User Roles: Granular permissions allow project admins to control access to specific sections of a project or platform. This means that internal staff members don’t need full admin access to engage with certain aspects of a project. For example, staff can be given permissions to view reports or engage with the public without the risk of altering project settings or content. This system allows for a more tailored experience and prevents unnecessary access.

2. Reduced Risk of Mistakes or Unauthorized Changes: One of the major concerns expressed by Porirua City Council and Western Bay of Plenty is the need to ensure that only the appropriate staff can edit or modify project content. Granular permissions help mitigate the risk of accidental edits or unauthorised changes by limiting access to content creation and editing only to those who truly need it. For staff who only need to monitor or interact with the public (e.g., replying to comments, answering questions), granular permissions prevent them from making unintended changes to the underlying project content.

3. Efficient Resource Allocation: By allowing project admins to create custom roles with specific permission sets, councils can ensure that staff members have access to the exact tools or data they need to do their jobs. For example, a team member responsible for community engagement may need to respond to comments or moderate discussions but doesn't need the ability to edit content. This not only improves efficiency but also helps in aligning staff responsibilities with appropriate permissions.

4. Improved Collaboration: A flexible permission system fosters smoother collaboration between teams. Porirua City Council and Western Bay of Plenty both emphasised the importance of being able to allow staff to interact with the public in certain ways—such as replying to comments or engaging on discussion boards—without risking the security or integrity of the content. Granular permissions help strike a balance between empowering staff to participate in engagement activities and ensuring they cannot make changes that may affect the overall project.

5. Tailored Permissions Based on Job Functions: Different team members have different job responsibilities, and granular permissions cater to that diversity. For example:

   • Data Analysts can be granted read-only access to reports, ensuring they can monitor performance and feedback without altering any project data.

   • Community Engagement Officers may need the ability to respond to feedback, questions, or comments on the platform, but not change the content itself.

   • Project Managers or Team Leads can have full editing rights to content and settings, but other staff members are limited to only specific areas where they can contribute.

Who Would Benefit:

1. Site Administrators: The primary beneficiaries of this granular permission enhancement are Site Administrators. They will be able to assign roles with precise permissions, allowing them to manage access to project content based on the responsibilities of individual staff members. This enables better oversight and control while reducing the complexity of managing multiple staff roles.

2. Internal Staff: Staff members will benefit from a system where they only have access to the tools they need. For example, those focused on reporting won’t be overwhelmed with unnecessary permissions to edit content, and engagement staff won’t risk accidentally changing content while interacting with the community. The enhanced permissions structure ensures that staff have the tools they need to perform their tasks effectively without unnecessary complexity or risk.

3. Community Engagement Teams: Community engagement staff at both councils, such as those handling public comments or moderating discussions, will benefit from the ability to interact with users while maintaining the integrity of the content. They can respond to feedback or reply to questions without worrying about inadvertently editing or deleting key project content.

4. Compliance and Security Teams: Teams responsible for compliance and security will appreciate the level of control provided by granular permissions. With detailed logging of who accessed what data or made changes, they can ensure that staff only have access to the necessary elements of a project. This helps safeguard sensitive content and ensures compliance with internal policies or external regulations.

5. Executives and Senior Leadership: For executives or senior decision-makers, granular permissions enable them to have a clearer view of staff access levels, which enhances governance and accountability. They can also be confident that staff are working within their role-defined boundaries, reducing potential risks or errors caused by staff having too much access to sensitive data.

How It Should Work:

1. Custom Roles and Permissions: Project admins should be able to create custom roles and assign specific permissions to each role. For example, roles such as:

   • Site Admins: Full access to edit content, manage project settings, and modify permissions.

   • Data Analyst/Project Officer: Access to view reports and analytics but no permission to modify content or settings.

   • Community Engagement Officer: Access to reply to public comments, moderate discussions, and engage with feedback without being able to alter or edit content.

2. Fine-Grained Permissions Control: Each role should have specific permissions that can be toggled on or off for actions such as:

   • View Content: Can they view project content, reports, or data?

   • Edit Content: Can they create or edit text, images, or other project elements?

   • Respond to Public Feedback: Can they reply to comments, participate in Q&A, or interact on the ideas board?

   • Manage Settings: Can they alter the project settings, like permissions or content publishing?

   • Access Reports: Can they access performance reports, analytics, or user feedback data?

   This level of control ensures that staff only have access to what they need based on their role within the project.

3. Role Assignment via User Management Interface: The interface for managing user roles and permissions should be simple and intuitive. Admins should be able to assign roles to users with ease, and permissions should be updated immediately. A centralised dashboard for user management would enable admins to review permissions for each user at a glance and adjust as necessary.

4. Notifications for Permission Changes: When permissions are adjusted, affected users should be notified so that they’re aware of their access levels. For example, if a team member is granted permission to edit content or is restricted to read-only access, they should receive a notification explaining the change.

5. Auditing and Tracking: An audit trail should be maintained to track who makes changes to permissions and when. This will help admins and security teams review changes and ensure compliance with internal protocols.

6. Role Hierarchy and Inheritance: A hierarchical structure for roles may be useful, allowing admins to create roles that inherit permissions from other roles. For instance, a "Team Lead" role could inherit permissions from a "Project Manager" role but limit certain actions, such as access to advanced settings.

Conclusion:

By introducing Granular Permissions Settings, Porirua City Council and Western Bay of Plenty will be able to better manage user access, reduce the risk of accidental errors, and streamline workflows within their projects. This approach allows for improved security, more efficient resource allocation, and better alignment of roles with responsibilities, ultimately making the user experience more tailored, effective, and secure.

The Hill, NSW would like to see more permission settings and options to restrict project admins to certain tasks only. They started on OpenCities with Granicus so are looking for similar tiered permissions or flexibility in roles creation.