The Catalpa Handbook
  • The Catalpa Handbook
    • Handbook guidelines
  • 1. ABOUT CATALPA
    • 1.1 About Catalpa
    • 1.2 Vision, Values and Strategic Plan 2022
    • 1.3 Governance at Catalpa
    • 1.4 Organisational structure of Catalpa
    • 1.5 Our projects and key contacts for each
    • 1.6 Our key products
      • Bero
        • Content
          • Exams
          • Targeting Content to Users
            • Resizing images for Bero
        • Design
        • Requirements
        • Theming
      • Gathr
      • Openly
  • 2. OUR PEOPLE AND HOW WE WORK
    • 2.1 How we work and the tools we use
      • Google Drive
      • Trello
      • Github
      • InVision
    • 2.2 Communicating internally
      • All Hands Stand-up (weekly / Mondays)
      • Tutorial Tuesdays
      • Show & Tell
      • Guide to Slack
      • Team meetings
      • Other Events
    • 2.3 Mission Driven Teams
    • 2.4 Recruitment and Onboarding
      • Hiring Guidelines
    • 2.5 How we support our people to thrive
      • Onboarding a new hire
        • Onboarding Trello
        • Onboarding buddy guide
        • 30/60/90 Day Plan
      • Goal Setting
      • Regular work/task based 1X1's
      • Quarterly Catch Up's
      • Feedback
      • Managers - Managing Underperformance
    • 2.6 Offboarding
    • 2.7 Leave and public holidays
      • Leave
      • Public Holidays
    • 2.8 Supporting our Mental Health
    • 2.9 Working from home & remotely
    • 3.0. Learning & Development Allowance
  • Page
  • 3. EXTERNAL COMMUNICATIONS
    • 3.1 Guide to Communication
      • Describing Catalpa
      • Guide to photography
      • Guide to social media
      • Writing: style guide
      • Writing: grammar
    • 3.2 Procedures for the collection, storage and use of stories, photos and video
    • 3.3 External Complaints and Feedback Policy
  • 4. PARTNERSHIP AND GROWTH INCLUDING BUSINESS DEVELOPMENT
    • 4.1 Introduction / overview
    • 4.2 Pre-bid stage including networking and partnering
      • Networking
      • Positioning for priority bids
      • Tracking bid opportunities
      • Partnering
        • Partnership brokering
        • Due diligence of downstream partners /subcontracting agencies
        • Pre-bid agreements
    • 4.3 Go / No Go
      • Go / No Go meetings
      • Selection criteria and guidelines
    • 4.4 Tender planning and preparation
      • Project planning and design pre-submission
      • Key templates and links for bid planning and preparation
      • Bid Writing - full proposal or concept note
        • How to appoint an external bid writer
        • Key templates
        • Commonly required building blocks / required materials for tenders
        • Guides
    • 4.5 After a bid has been submitted
  • 5. PROJECT AND PRODUCT CYCLE MANAGEMENT
    • 5.1 Introduction
    • 5.2 Planning and pre-submission design
      • 5.2.1 Monitoring, Evaluation & Learning
        • Project-level M&E
        • Catalpa's organisational approach to MEL
      • 5.2.2 Risk Management
      • 5.2.3 Cross-cutting issues in projects
        • Gender equality
        • Disability inclusion
    • 5.3 Mobilising a new project
      • Handover from BD team to PM team
      • Program Summary Document
      • Team Kickoff Meeting
      • Team Charter
    • 5.4 Post-contract implementation
      • Stage 1 - Learn: Design and Discovery
        • Human Centred Design
        • Our Tools
        • Creating a product
      • Stage 2: Create and Ideate
        • Our model
        • Agile Project Management
          • Getting started
          • Product design and development phases
            • 0. Contracting
            • 1. Learn
              • 1.1. Prepare
              • 1.2. Discovery
              • 1.3 Empathise
            • 2. Create
              • 2.1 Ideate
              • 2.2 Implement
            • 3. Refine
            • 4. Evaluate
          • Product Roadmap
          • Defining releases
          • Create the solution
          • Make a global plan
          • User Stories
          • Prototyping
          • Incremental development
          • UX & UI
          • Conducting tests
      • Stage 3: Refine and Release
        • Introduction and overview
        • Data privacy on a project basis
        • How-tos
          • Retrospective
        • Scrum methodology
          • Daily standup
          • Sprints
          • Sprint prep
          • Sprint meeting
        • Release
          • Epics
          • Epic selection
          • Epic planning
          • Product Q&A, deployment and implementation
          • Make it available
          • Delivery
      • Stage 4: Evaluate
        • Define the maintenance support plan and team
        • Customer support
        • Ongoing user data collection and analysis
      • Glossary of Terms
    • 5.5 Project close-out
      • Product transition and handover
      • Transition to governmen
      • SMA
      • Licenses / handover documents
      • Migrating to Gov owned data-center or cloud hosting
  • 6. POLICIES AND PROCEDURES
    • 6.1 Register of policies and compliance
    • 6.2 Policy Development Procedure
    • 6.3 Code of Conduct
    • 6.4 Data Privacy & Storage Policy
    • 6.5 Human Resources Policies
      • Breastfeeding and Work Policy
      • Occupational Health and Safety Policy
      • Domestic and Family Violence Policy
      • Gender Equality Policy
      • Disability & Discrimination Policy
      • Use of Catalpa Vehicles Policy - PNG
      • Anti-Bullying, Harassment and Discrimination Policy
    • 6.6 Safeguarding Policies, Templates and Training
      • Child Safeguarding Policy
      • Prevention of Sexual Exploitation, Assault and Harassment Policy (PSEAH)
      • Safeguarding templates
      • Safeguarding training
      • Safeguarding procedure for collecting, storing and using images / stories
    • 6.7 Financial and Asset Management
      • Fraud & Corruption Policy
      • Vehicle Use
    • 6.8 Complaints and Feedback
      • Internal Complaints and Feedback Policy
      • External Complaints and Feedback Policy
      • Whistleblower Policy
    • 6.9 Contract Development Procedure
Powered by GitBook
On this page
  • Tags
  • Permissions
  • Sites

Was this helpful?

  1. 1. ABOUT CATALPA
  2. 1.6 Our key products
  3. Bero
  4. Content

Targeting Content to Users

PreviousExamsNextResizing images for Bero

Last updated 3 years ago

Was this helpful?

Content in Bero can be targeted to users by 2 mechanisms: Tags and Permissions.

Tags allow users to target their own content.

Permissions allow administrators to target content at users based on group membership and login.

The additional Sites mechanism is a possible future capability, adding more capabilities at a reasonably low engineering cost. It would allow the targeting of not just content but interface to all users regardless of login.

Tags

As of now most content (Courses, Lessons etc) can be assigned tags by content creators. Tags can be created in the CMS easily on the page being tagged.

Tags show up in the user interface behind the filter icon, allowing users to filter the list to content matching tags

Tags allow users to search for the content they are interested in without hiding any content from anyone

Permissions

Pages in wagtail can be given 3 types of permission, public, private ( logged in ), and private ( group members)

  • Public content is shown to all users

  • Private ( logged-in ) content is shown to only authenticated users

  • Private ( group membership ) content is shown to only members of the specified groups

Child pages obey the permission setting of their parent so a whole category / topic can be made private and its contents will be private too.

Permissions allow site admins to target content to users based on if they have a log in, and the groups they are a member of, but you must be logged in to be a member of a group.

Sites

NOTE: This is not currently implemented

Wagtail allows us to create multiple sites under one installation differentiated by the domain used to access the site.

We could use the same deployment to host multiple user sites, different content would be seen depending on the domain used to access the site.

What this would allow

Different site domains would be able to:

  • have different theming / images

  • have different login help contacts

  • have different languages exposed

  • have different content

All content would be managed in one CMS allowing:

  • content to be easily copied from one domain to another

  • Single login for program staff across multiple domains