Should we expect Panels to be modified

Hi devs,

Context: see Recently modified documents panel - adjust # of entries?

I think we need to decide if we wish that all panels are of demo or customizable types (see https://extensions.xwiki.org/xwiki/bin/view/Extension/XAR%20Module%20Specifications#HCurrentFormat), or not.

Also, right now the Panels App UI is offering specific buttons to edit the panels (https://extensions.xwiki.org/xwiki/bin/view/Extension/Panels%20Application#HPanels27shomepage) so we have some inconsistency if we consider that they’re not supposed to be edited.

My POV is that we should expect them to be edited or even deleted and thus be considered demo pages. This means they’re upgraded when no changes is made to them but as soon as a user makes a modification, they’re not upgraded anymore.

WDYT?

I don’t think this is an all or none answer. Like any other wiki page some plugins are meant to be modified (like the quicklinks panel which even have an edit link on it) and some are complex pages which are not meant to be modified.

Quicklinks is an obvious one (the only obvious one probably) but this brainstorming was going further than that with the idea of discussing whether all panels (except maybe edit ones which should be deprecated soon probably but that’s another matter) be content supposed to be modified by users if they need to customize them.

I see 2 options:

  • Either we say they are all customizable and we make them demo
  • Or we say they’re not and users need to copy them as new panels if they need to customize them in which case we remove the “Edit/delete” actions in the Panels app (maybe replace “edit” with “Copy” or “Customize by copying”).

I understood that, and I think I did answer: we simply can’t have a common rule for all panels IMO.

I’m changing my mind. So my new proposal is:

  • List panels that should be editable. Personally I don’t know any except QuickLinks.
  • Modify Panels app to have the LT action columns display:
    • “Edit” for modifiable panels
    • “Copy to customize” for non-modifiable panels
  • Also remove the “delete” action from the Panels LT.
  • Ancillary question: Do we have a script service API to know the XAR type of a given page?
  • Introduce a ConfigurableClass xobjects for panels which expose configuration options. Such as the number of entries to display for panels displaying entries.
  • Introduce a new “Panels” menu category in the admin menu. Then either leave the current “Panels” menu entry under “L&F” or move it under the new “Panels” entry as the first entry under a “General Configuration” entry or something like that.

WDYT?

That’s a lot of sub proposals :slight_smile:

We do but here I think what we really want to know is more if the current user is allowed to edit/delete a specific panel page and that’s:

$services.extension.xar.getEditSecurityLevel($xcontext.userReference, $panelPageReference)
$services.extension.xar.getDeleteSecurityLevel($xcontext.userReference, $panelPageReference)

Another possibility is to show/hide this action based on

$services.extension.xar.getDeleteSecurityLevel($xcontext.userReference, $panelPageReference)

Would you be making a distinction between “editable”, such as quicklinks and customizable, such as the # of entries to show in “recently edited pages”.

One allows for editing the actual content, while the other is just a configuration setting.

Yes.

Editable:

Configurable:

1 Like