[Libreoffice-bugs] [Bug 138883] Revise implementation of the Category system in Template Manager, including automatic refresh when categories are changed

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Wed Dec 16 20:42:39 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=138883

--- Comment #16 from sdc.blanco at youmail.dk ---
(In reply to sdc.blanco from comment #14)
>> strongly disagree with the mixture of internal and file system operations.
> Could "category" be a custom <meta> tag in a template? 
Using groupuinames.xml is better than custom meta tag.  Separates physical
filesystem from "categories" of TM; does not require document modification.

Here is a sketch for how to separate TM internal system from file system,
building on already existing features of internal system.  

( "sketch" = some proposed steps that might stimulate/motivate others to
develop further or to inspire a more promising direction )

Internal TM system has to handle at least following cases when rename/delete
category is used.

1. If a category (subdirectory) has templates, then "delete category" should
offer (require) user to select a new category for the templates (which, on the
backend, moves template files from one directory to another) (and probably
"refreshes" what template manager has loaded in its memory)

2. If directory for deleted category is empty, then (on backend, silently
delete the subdirectory,  otherwise subdirectory continues to appear as
category). (Should not be a problem to delete an empty directory, even if added
manually outside of TM). (and "refresh" memory)

3. If directory for deleted category is still not empty (after case 1, where
templates have been moved), then leave the directory.  (It leaves an "orphaned"
directory, but seems better than "deleting", especially if a user has manually
changed an .ott to .ott.bak or something like that, then the directory is not
deleted, even though the category is deleted and the valid templates are
moved.)

NB.  If case 3 is used, then seems better to use groupuinames.xml for
determining appearance of ALL categories in TM, not just when category name is
changed to be different from directory name.  Would require TM to check for new
subdirectories when opening (in case user has added one manually), and to
"write" all subdirectories in groupuinames.xml (even if subdirectory and
category name is the same). --  (with this approach, groupuinames.xml would
also have to record "orphaned" subdirectories so that they do not (re)appear as
a category, but allow a "new" category to be created with the same name as an
"orphaned" category, taking over again the subdirectory with the same name).  


Case 4.  Make 2 user paths (e.g., the default 4/user/template, and, for sake of
example, mytemplatedir).  Create a category B in TM, where userprofile is
default path.  Manually create a subdirectory B to mytemplatedir.  Now TM shows
all templates in both directories.  (in effect, replicating the operation of
MyTemplates, but now with a subdirectory, rather than the path directories).  

One problem (also now) is that it is impossible to rename the category, even
though it shows all templates in both directories.

The other problem (also now) is that in deleting the category, the directory
(and its contents) in the default path IS deleted, while the other subdirectory
(in the non-default path) remains, and the user interface says "cannot delete
category", even though it did delete the default path, and the change can be
seen in TM).   

This case, multiple directories with same category name, could be handled with
same rules as the previous three cases.  Need to update the groupuinames.xml in
each directory, if groupuinames.xml is used to control all category names,
including those names that are identical to directory names.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201216/2635d5ef/attachment.htm>


More information about the Libreoffice-bugs mailing list