Built-in templates cannot be edited or renamed. Enhancement: Context menu items should not be active for built-in templates.
Agree. Shouldn't be too difficult... sfx2/source/doc/templatedlg.cxx
https://gerrit.libreoffice.org/c/core/+/107611
Vert D committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/86f3fa919a6de6767177193d5b7714f8f6dbd5c4 tdf#138246 Disable edit rename delete contextmenu items for built-in templates It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #3) > Vert D committed a patch related to this issue. > Affected users are encouraged to test the fix and report feedback. LGTM. "system" templates only have "Open" and "Set as Default" in context menu (which exhaust the permissible actions), while user-defined actions have the full set of possible actions in the context. Appears properly both in Thumbnail and List View, and all commands work as expected.
*** Bug 134140 has been marked as a duplicate of this bug. ***
*** Bug 103620 has been marked as a duplicate of this bug. ***
(In reply to Commit Notification from comment #3) > Affected users are encouraged to test the fix and report feedback. @Heiko -- iirc -- your preference is that context menus should show all possible actions, but grey-out those actions which cannot be applied. The present patch simply eliminates showing the controls for predefined templates. Perhaps you would prefer that they are visible, but deactivated?
(In reply to sdc.blanco from comment #7) > (In reply to Commit Notification from comment #3) > > Affected users are encouraged to test the fix and report feedback. > @Heiko -- iirc -- your preference is that context menus should show all > possible actions, but grey-out those actions which cannot be applied. > > The present patch simply eliminates showing the controls for predefined > templates. > Perhaps you would prefer that they are visible, but deactivated? Absolutely. Disabling means that they are greyed out. If they were removed, then the change is not correct.
Thought set_sensitive() does exactly this, disabling the entry.
I think for gtk3 set_sensitive disabled greys out the item, for win, x11, qt5 it is removed.
Here is where this is made so: https://opengrok.libreoffice.org/xref/core/vcl/source/window/menu.cxx?r=cf730619#2903
Confirming the different behavior in gtk3 and qt5 VCL plugins on Ubuntu 20.04. Start LibreOffice with qt5 VCL plugin: SAL_USE_VCLPLUGIN=qt5 ./instdir/program/soffice.bin then go to Templates > Manage Templates. In gtk3, 'Edit', 'Rename' and 'Delete' buttons are grayed out, but in qt5, these buttons are removed.
Re-evaluating the EasyHack in 2022 This enhancement is still relevant. The behavior in Qt5 is still different.
This regressed in 7.3 - now the Edit items is enabled and visible in all backends and sadly causes a crash in current builds! This happened in 06d063a9de41a24922f15cd3aa47411b61d30c23 tdf#138906 prevent built-in category deletion Maybe looking into that can still be done within the context of this hack.
Here is my patch: https://gerrit.libreoffice.org/c/core/+/197335 I have disabled the edit option for built-in templates in template dialog view but clicking on the edit option for user defined templates still causes a crash. Few things that I noticed are: 1) If we open a file and then open the template manager using File->Templates->Manage Templates, we do not get a crash on trying to edit a template. 2) The 'Edit' option for built-in templates is available in template default view as well, i.e., if we go to 'Templates' directly instead of File->Templates->Manage Templates. In my opinion, it should also be disabled. Should I try to do this?
(In reply to Tejas Shukla from comment #15) > Here is my patch: https://gerrit.libreoffice.org/c/core/+/197335 Nice > 1) If we open a file and then open the template manager using > File->Templates->Manage Templates, we do not get a crash on trying to edit a > template. I cannot reproduce the crash on Linux/Qt. The default path is ~/.config/libreoffice/4/user/template and there should be no blocker for user actions. > 2) The 'Edit' option for built-in templates is available in template default > view as well, i.e., if we go to 'Templates' directly instead of > File->Templates->Manage Templates. In my opinion, it should also be > disabled. Should I try to do this? File > Templates > Edit Template is .uno:OpenTemplate. I don't think we can disable that (no idea how edit vs open work at all). But there is also an Edit in the start center's context menu.
(In reply to Heiko Tietze from comment #16) > > 2) The 'Edit' option for built-in templates is available in template default > > view as well, i.e., if we go to 'Templates' directly instead of > > File->Templates->Manage Templates. In my opinion, it should also be > > disabled. Should I try to do this? > > File > Templates > Edit Template is .uno:OpenTemplate. I don't think we can > disable that (no idea how edit vs open work at all). But there is also an > Edit in the start center's context menu. Start Center's context menu is exactly what Tejas was talking about. Edit edits the source template while Open creates a new document based on the template. Tejas: do you get the crash on Windows?
Created attachment 205084 [details] GDB trace of crash Strange that Heiko is not seeing the crash. Here's a backtrace. Arch Linux 64-bit Version: 26.8.0.0.alpha0+ (X86_64) Build ID: d30a759567c437b501101099fc3786ea87691e15 CPU threads: 8; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 17 January 2026
(In reply to Buovjaga from comment #18) > Created attachment 205084 [details] > GDB trace of crash #7 0x00007f97a9a0af2c in SfxTemplateManagerDlg::run (this=0x7fff11297320) at /home/user/libreoffice/sfx2/source/doc/templatedlg.cxx:262 The patch that caused the crash modified SfxTemplateManagerDlg::updateMenuItems (renamed from createDefaultTemplateMenu). Within the function indicated in the backtrace, a call to updateMenuItems() was added.
(In reply to Buovjaga from comment #18) > Strange that Heiko is not seeing the crash. Perhaps because running on Qt/X11. But even starting with VCL=gtk3 it doesn't crash. And loading a template from //usr/lib/libreoffice/share/template/common/ shows the read-only infobar - I still can edit but need to save under a different name/location, of course. Version: 25.8.4.2 (X86_64) / LibreOffice Community Build ID: 580(Build:2) CPU threads: 32; OS: Linux 6.18; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 25.8.4-3 Calc: threaded
(In reply to Buovjaga from comment #17) > Tejas: do you get the crash on Windows? Yes, I do get a crash on Windows but it should be noted that the crash occurs only when you are at the Start Center, then go to Files > Templates > Manage Templates and try to edit a template. No crash occurs if you already have a file open and then go to Files > Templates > Manage Templates to edit a template.
(In reply to Heiko Tietze from comment #20) > (In reply to Buovjaga from comment #18) > > Strange that Heiko is not seeing the crash. > Perhaps because running on Qt/X11. I do get the crash on Qt/X11 as well, so I wonder how you are testing it. 1. Launch into Start Center 2. File - Templates - Manage Templates (Ctrl+Shift+N) 3. Right-click on any template, even your own custom one and click Edit
Created attachment 205085 [details] Screencast (In reply to Buovjaga from comment #22) > I do get the crash on Qt/X11 as well, so I wonder how you are testing it. Strange
(In reply to Heiko Tietze from comment #23) > Created attachment 205085 [details] > Screencast > > (In reply to Buovjaga from comment #22) > > I do get the crash on Qt/X11 as well, so I wonder how you are testing it. > Strange Sorry for my misleading comment earlier. The crash itself actually appeared in 26.2 with 8ce2cf3973ecd428eb8d0290930791ee1c771626 tdf#41777 Add window size and position for each document So please test with master to see the crash.
(In reply to Buovjaga from comment #24) > So please test with master to see the crash. Yes, it does crash with 26.8.
I reported the crash as bug 170399
(In reply to Tejas Shukla from comment #15) > 2) The 'Edit' option for built-in templates is available in template default > view as well, i.e., if we go to 'Templates' directly instead of > File->Templates->Manage Templates. In my opinion, it should also be > disabled. Should I try to do this? Wonder if we need to disable edit if the bug is fixed. But in the end it should be easy to open a built-in template and save under a different name/location as a template. The start center context menu is shown per TemplateDefaultView::createContextMenu(). You need to figure out how to check if the object is an internal template. Probably with IsInternalTemplate() like at SfxTemplateManagerDlg::CreateContextMenuHdl.
(In reply to Heiko Tietze from comment #27) > (In reply to Tejas Shukla from comment #15) > > 2) The 'Edit' option for built-in templates is available in template default > > view as well, i.e., if we go to 'Templates' directly instead of > > File->Templates->Manage Templates. In my opinion, it should also be > > disabled. Should I try to do this? > > Wonder if we need to disable edit if the bug is fixed. But in the end it > should be easy to open a built-in template and save under a different > name/location as a template. > > The start center context menu is shown per > TemplateDefaultView::createContextMenu(). You need to figure out how to > check if the object is an internal template. Probably with > IsInternalTemplate() like at SfxTemplateManagerDlg::CreateContextMenuHdl. Heiko: do you mean you would not do anything in the context of comment 10? That the state at comment 10 is fine, with only gtk3 showing the items as disabled and others not showing them at all?
(In reply to Buovjaga from comment #28) > Heiko: do you mean you would not do anything in the context of comment 10? > That the state at comment 10 is fine, with only gtk3 showing the items as > disabled and others not showing them at all? Whether disabled menu items are visible or not (which is wrong IMO) is a different question than the question about edit internal templates. The expert setting DontHideDisabledEntry controls the visibility - and a few tickets pop up for this keyword.
Hmm, studying DontHideDisabledEntry I found commit 1ac7350a7032a760be22cce845eab7efe435827d tdf#158101 Make non-gtk backends context popup menu item visibility behavior like gtk
(In reply to Heiko Tietze from comment #27) > (In reply to Tejas Shukla from comment #15) > > 2) The 'Edit' option for built-in templates is available in template default > > view as well, i.e., if we go to 'Templates' directly instead of > > File->Templates->Manage Templates. In my opinion, it should also be > > disabled. Should I try to do this? > > Wonder if we need to disable edit if the bug is fixed. But in the end it > should be easy to open a built-in template and save under a different > name/location as a template. > > The start center context menu is shown per > TemplateDefaultView::createContextMenu(). You need to figure out how to > check if the object is an internal template. Probably with > IsInternalTemplate() like at SfxTemplateManagerDlg::CreateContextMenuHdl. I have disabled edit option for built-in templates in start center's context menu as well in this patch: https://gerrit.libreoffice.org/c/core/+/197335
Tejas Shukla committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cca3498787f5657986eec61411d5b2ae6f1f1098 tdf#138246 Disable edit contextmenu item for built-in templates It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With the commit, Edit, Delete and Rename are shown as disabled also in qt-based UIs, as expected.