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

I think I wasn’t clear enough with the context and explanation as to why we have a problem. So here’s the rationale:

  • Right now, all panels are supposed to be editable and our UI clearly shows it when you go the Panels application (see the edit action on all panels):
  • If you try to edit a panel you’re getting a scary warning:
    image

Thus something is off. We have various solutions:

  • Option 1: we consider that all panels are editable and their wiki pages should all be of type customizable. With this, we can keep the “Edit” action in the Panel app home page.
  • Option 2: we consider that panels are not supposed to be edited and we remove the “Edit” action in the Panels app home page LD. We replace it with a new action: “Copy to customize”. (optional) We also remove the Quick Links panel which is not used by default and acts more as a demo. It’s not really needed since it’s possible to create such as panel easily if you need it.
  • Option 3: we consider that some panels are supposed to be edited while others aren’t. This would mean adding that info into the Panel XClass and using it to decide if there should be an “Edit” action in the LD or not.

I personally think that option 3 is the worst of all. If you take the example of the “Recently Modified” panel (which is what brought this discussion), the need was not really to edit it, but to configure it to adjust the number of elements displayed. A better solution for this would be to introduce a configuration option for that panel. It’s going to be impossible to take all cases into account about what users will want to do with a panel and why they’d want to edit it. Thus for me the best option is to go with either option 1 or 2.

I have a preference for option 2 as I think we should consider panels like any wiki page belonging to an extension, i.e. supposed to NOT be modified.

WDYT?

Thx

Would this also apply to panels that were created by the user, i.e., that aren’t part of an extension or do you suggest to only disable the edit action for those panels that are part of an extension? What about panels that are part of an extension but are explicitly marked as customizable?

Good point. Indeed it could be solved by checking if the panel page is part of an extension or not. This would be logical since the initial idea is to not have the warning when editing, and this would avoid it.

Another good point. We could decide to not show an “Edit” action if the panel is part of an extension and if it cannot be edited (i.e. not of type customizable, configuration and demo).

Thx