The core principle

Think of backend restriction as two layers:

  1. What they are allowed to do (ACL permissions).

  2. What they are allowed to see (Administrator menu modules + Access Levels).

You need both tuned for a clean experience. Joomla’s permission keys and the meaning of Access Administration Interface (core.manage), Administrator Login, and especially the danger-card core.admin are documented in the official ACL references. Joomla! Programmers Documentation


Foundation pattern (use for every restricted backend role)

1) Create a new group

Users → Groups → New
Name it something specific like:

  • WVSB Directory Editor

  • EasyBlog Author (Backend)

  • Media Uploader (Backend)

Parent choice:

  • Start with Public if you want a truly minimal base.

  • Or Manager if you want a quicker setup (but you’ll still tighten things).

The official docs walk through creating a group and then attaching it to appropriate access levels. docs-next.joomla.org

2) Add group to an access level that can see admin menus

Users → Access Levels

  • Edit Special

  • Add your new group

This step is commonly required so admin menu modules assigned to “Special” actually appear for them. docs-next.joomla.org

3) Grant only the minimum global permissions

System → Global Configuration → Permissions
For the new group, set:

Allowed

  • Administrator Login

  • Access Administration Interface (core.manage)

Never give

This gets them into admin without handing them the keys to the kingdom.


Make the backend menu match the role (clean UI)

4) Create a custom Administrator Menu module

Extensions → Modules
Filter Administrator
Create Administrator Menu module.

  • Assign it to position: Menu

  • Set Access to your new group’s access level
    (often Special or a custom access level)

This approach is a standard way to show a reduced, role-specific admin menu. Joomlashack

Then you can:

  • duplicate the default admin menu module,

  • remove items they don’t need,

  • and publish the trimmed module for only that access level.


Role recipes tailored to your typical use cases

A) “Blog-only staff” (EasyBlog + Articles)

Goal: They can create and manage blog posts, not touch system stuff.

Global

  • Allow: Administrator Login, Access Administration Interface

  • Leave everything else inherited

Content

  • Content → Articles → Options → Permissions

    • Allow: Create, Edit, Edit Own (and Edit State if they need publishing)

    • Do not allow Configure/Options

EasyBlog

  • In EasyBlog’s own permissions screen (if present):

    • Allow create/edit/publish as needed

Menu

  • Custom admin menu containing only:

    • Content

    • EasyBlog entries

Reality check
Some third-party components implement ACL more loosely than core; test with a dummy user.


B) “WVSB Directory Editor” (J-BusinessDirectory)

Goal: They manage listings/categories inside the directory, not the rest of the site.

Global

  • Allow: Administrator Login, Access Administration Interface

Directory component options

  • Go to the component’s Options → Permissions

    • Allow: Manage component items

    • Add Create/Edit/Edit Own/Edit State as appropriate

Menu

  • Custom admin menu showing:

    • Directory component

    • Media (if they need images)

    • Maybe Content if you tie listings to articles


C) “Media Uploader (Backend)”

Goal: They can upload images/files for others.

Global

  • Allow: Administrator Login, Access Administration Interface

Media

  • In Media component permissions:

    • Allow: Create (upload)

    • Possibly Edit/Delete if you want them to clean up

Menu

  • Only Media + maybe a minimal dashboard


Testing checklist (fast and revealing)

  1. Create a test user assigned only to the new group.

  2. Log in as them in a private browser.

  3. Confirm:

    • They can enter admin.

    • They see only your custom admin menu module.

    • Direct URL access to other components fails (not just hidden).
      This proves ACL is correct, not just the UI.


Common gotchas

  • They can log in but see no menu
    Usually missed putting the group into Special (or the access level used by your admin menu module). docs-next.joomla.org

  • They still seem too powerful
    Check you didn’t accidentally allow anything at global that cascades downward, particularly admin/configure-level rights. Joomla! Programmers Documentation

  • You hid it, but they can still open it by URL
    That means you changed menu visibility but not ACL.


The quick “best practice” structure

If you want a consistent scheme across CD/WVSB sites:

  • One group per job:

    • CD Blog Admin

    • WVSB Directory Editor

    • CD Media Uploader

  • One custom admin menu module per group

  • Minimal global permissions

  • Component-level permissions set explicitly where needed


If you want, I can draft a ready-to-follow click-path with exact permission toggles for:

  • Articles + EasyBlog

  • J-BusinessDirectory

  • Media
    and a suggested naming convention for groups/access levels/admin menu modules so it stays tidy across multiple client sites.