Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[TASK] Split the frame index help slot: assistance request out of the core, manuals on their own icon

Open
#1,303 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, python

Research direction

Start with projects/gnrcore/packages/adm/resources/frameindex.py at fi_slotbar_helpdesk and trace the slot lists in prepareBottom_std and prepareBottom_mobile. Then read the docu handbook URL helpers (calculateExternalUrl, _absoluteLocation, and handbook_url) and the @oncalled extension pattern used by gnrsupport. Done means the manuals slot handles group documents and docu handbooks, with computed URLs, compatibility guidance, and tests for all three sources.

Written by the indexing model from the issue text.

Description

task
Summary

Split the fi_slotbar_helpdesk frame index slot into two independent entry points — assistance request and manuals — drop from the core the half of it that nobody implements, and give the manuals half a real implementation with a computed url.

Objective

fi_slotbar_helpdesk (projects/gnrcore/packages/adm/resources/frameindex.py:354) renders a single ? menu that merges two concerns which do not necessarily belong together: asking for help and reading the manual.

@struct_method
def fi_slotbar_helpdesk(self,slot,**kwargs):
    documentationcb = self.helpdesk_documentation()
    helpcb = self.helpdesk_help()
    usergroup_documentation = self.helpdesk_userGroupDocumentation()
    if not (usergroup_documentation or documentationcb or helpcb):
        return
    menu = slot.menudiv("!!Help",iconClass='iconbox help',_class='largemenu noIconMenu')
    ...

All three hooks are empty in the core (helpdesk_documentation() and helpdesk_help() return None, helpdesk_userGroupDocumentation() returns rows only if adm.group_helpdoc is populated), so the slot normally renders nothing at all. The abstraction is left half-built and, in practice, unused:

  • Assistance request. The only implementation was gnrsupport:helpdesk, and it has just been removed (softwellsrl/gnrsupport#27): it duplicated the SOS button of that package with weaker permission gating, letting users without helpdesk_self/helpdesk_others reach the assistance dialog from the ? menu. Nothing in the core or elsewhere implements helpdesk_help() any more.
  • Manuals. The only implementations are applications returning a hardcoded string, e.g. anaci_app:
    def helpdesk_documentation(self):
        return "genro.openBrowserTab('https://app.anaci.it/docs/manuale/agenzia_viaggi/cruscotto.html');"
    
    The url is frozen in the application source: moving or renaming a handbook silently breaks every link.
  • On top of that the block carries two defects that make even its populated path unusable — the group documentation query crashes the whole page and the "Open documentation" entry has no action. Those are tracked in #1302.

The goal is a design where each entry point is owned by the package that actually implements it, and where manual urls are computed rather than written down.

Scope

In scope

  1. Separate the two concerns. The merged ? menu goes away. helpdesk_help() is removed from the core: the assistance request is not a core responsibility, and the one package that provides it (gnrsupport:helpdesk) already installs its own SOS button into right_placeholder through @oncalled prepareBottom_std — the correct extension mechanism, and the one that carries the permission checks. The core must stop offering a second, weaker way in.
  2. A dedicated manuals slot. A new slot (working name fi_slotbar_manuals) with a book icon, distinct from the ?, listing the manuals available to the current user. The per-group list (adm.helpdoc / adm.group_helpdoc, reachable from Administration → Users setup → Help documents) stays as the generic mechanism for applications with no docu.
  3. docu contributes its own manuals. docu customizes adm — same @oncalled mechanism used by gnrsupport — adding the handbooks it publishes to the slot, with the url computed, not stored: docu.documentation.calculateExternalUrl() and docu.handbook._absoluteLocation()/handbook_url already resolve a documentation node or a handbook index to its public address, honouring the docu.sphinx_baseurl preference. If the handbook moves or the docs host changes, the links follow with no row and no application code to update.
  4. Update the slot lists of prepareBottom_std and prepareBottom_mobile accordingly.
  5. Migration note for applications that override the old hooks.

Out of scope

  • The two defects of the current code (KeyError: 'title' and the dead documentationcb) — #1302. That fix should land first: it is a crash present on both develop and master, and this redesign should start from working code.
  • The gnrsupport side — softwellsrl/gnrsupport#27, already done.
  • A mobile entry point for the SOS button (open follow-up on the gnrsupport side).
Technical Details / Notes
  • Extension mechanism. prepareBottom_std is @customizable, so a package adds its own controls with @oncalled plus sb.replaceSlots(...), as gnrsupport:helpdesk does. This is what docu should use; no new machinery is needed.
  • Icon. The slot currently asks for iconClass='iconbox help', which resolves to 16/help.png in resources/common/css_icons/retina/<theme>/icons.css (theme chosen by gui?css_icons, default retina/gray). A book icon has to be added; the newer inline-SVG mask mechanism (gnrjs/gnr_d11/css/gnrbase_css/18_gnr_google_icons.css + resources/common/css_icons/google_icons/, used e.g. by fi_slotbar_phonelink) is the preferred home for it, but the retina sets still back most iconbox classes, so the two have to be reconciled when choosing where the asset lives.
  • Backward compatibility. helpdesk_documentation() is overridden by real applications (three overrides in anaci_app alone, both at webapp and at single-page level) and those overrides return a JS callback, not a url. Whatever the new hook signature becomes, removal of the old names needs a deprecation step and a documented conversion, not a silent rename. It is worth deciding now whether the new hook should keep returning a JS string or return structured entries (title + url) and let the slot build the action — the latter composes with the docu and group_helpdoc sources, the former does not.
  • History. The ? slot dates back to 6600409a99 (2023-09-07, helpslot); the group documentation branch and the regression on the action were added in f13ddaaa10 (2024-01-12). It has had no working core implementation since.
Dependencies
  • #1302 — fixes the crash and the dead action in the same block; should land first
  • softwellsrl/gnrsupport#27 — removes the assistance side from this hook on the gnrsupport side
  • docu handbook url resolution (handbook_url, _absoluteLocation, calculateExternalUrl) is already in place
Acceptance Criteria
  • The core no longer exposes a hook for the assistance request; the only entry point is the one the implementing package installs
  • A dedicated manuals slot with a book icon replaces the merged ? menu, in both prepareBottom_std and prepareBottom_mobile
  • The per-group manuals from adm.group_helpdoc appear in that slot and open correctly
  • docu adds its published handbooks to the slot from its own package, with urls computed at render time
  • Renaming or moving a handbook, or changing docu.sphinx_baseurl, updates the links with no data or application change
  • Applications overriding the old hooks either keep working or get a deprecation warning pointing at the new API
  • Tests cover the resulting slot structure for the three sources (none, group documents, docu handbooks)
Dominant language
JavaScript
Stars
8
Forks
4
Avg merge
2d 59m
Merged PRs (30d)
118

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from genropy/genropy

All issues in genropy/genropy

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.