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:
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