office-gobmx/configmgr
Stephan Bergmann abd630e81b Allow all hierarchical path segments to be ['...'] quoted
...and not just set elements.  <https://gerrit.libreoffice.org/c/core/+/151660>
"tdf#104005 Don't allow changing finalized properties" found that some existing
property names include "/", which makes them unusable with e.g.
getPropertyByHierarchicalName.

The most obvious solution is to allow ['...'] quoting (without a leading
template name, though) for all kinds of hierarchical path segments.  (In theory,
that would cause backwards incompatibility, as e.g. a property named ['foo']
could no longer be referenced by a ['foo'] path segment (it would need to be
referenced by a ['[&apos;foo&apos;]'] path segment instead).  But in practice,
that path segment ['foo'] would have been rejected in the past anyway, as it did
not reference a set element.)

To make this work, the meaning of the setElement out-parameter of
configmgr::Data::parseSegment is changed to only be true if the segment uses
['...'] notation including a leading (non-empty) template name.

What this change does not (yet) address is writing out such quoted (group or
set) names in the hierarchical paths written out in configmgr::writeModFile,
where necessary.  (It never writes out names of properties as parts of
hierarchical names, so this wouldn't be an issue for the existing problematic
properties containing "/" in their names, anyway.)

Change-Id: I635d823c7bbb6b8ac5869c7e0130ba8cfd329599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151673
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-11 16:49:00 +02:00
..
inc/pch update PCHs 2021-04-08 17:23:08 +02:00
qa Allow all hierarchical path segments to be ['...'] quoted 2023-05-11 16:49:00 +02:00
source Allow all hierarchical path segments to be ['...'] quoted 2023-05-11 16:49:00 +02:00
CppunitTest_configmgr_unit.mk loplugin:logexceptionnicely in configmgr..connectivity 2019-06-14 11:05:59 +02:00
IwyuFilter_configmgr.yaml Recheck modules [a-c]* with IWYU 2022-01-13 08:26:15 +01:00
JunitTest_configmgr_unoapi.mk Simplify and fix Java UNO API test makefiles 2018-11-09 07:37:00 +01:00
Library_configmgr.mk Clean up color scheme migration 2022-09-15 14:27:31 +02:00
Makefile switch to include-based build rather than sourced-based build 2012-02-05 19:34:05 -06:00
Module_configmgr.mk tdf#46723 - enable configmgr unit tests 2015-02-11 10:00:32 +01:00
README.md Updated README.md files to represent current code / use Markdown format 2021-04-07 17:47:16 +02:00

UNO Services to Access the Configuration Database

Functional Overview

This code parses the settings that are described in the officecfg directory, and provides a UNO API that code can use to set and get settings.

Source Overview

configurationprovider.cxx
configurationregistry.cxx
defaultprovider.cxx
services.cxx

UNO service implementations.

access.cxx
childaccess.cxx
rootaccess.cxx

UNO objects passed to clients.

components.cxx

Central singleton that aggregates all data (reads in the XML files, manages modifications and global notifications).

groupnode.cxx
localizedpropertynode.cxx
localizedvaluenode.cxx
node.cxx
propertynode.cxx
setnode.cxx

Internal representations of data nodes.

parsemanager.cxx
parser.hxx
valueparser.cxx
xcdparser.cxx
xcsparser.cxx
xcuparser.cxx
xmldata.cxx

XML file reading.

modifications.cxx
writemodfile.cxx

Modification management.

broadcaster.cxx

Notification management.

additions.hxx
update.cxx

Extension manager interface.

data.cxx
lock.cxx
nodemap.cxx
partial.cxx
path.hxx
type.cxx

Utilities.

Some Implementation Notes

Mandatory Set Members

  • A set member can be marked as "mandatory," meaning that a member of that name must always be present in a set.

  • The above definition implies that calling replaceByName on a mandatory set member is OK.

  • The XCU format can contain oor:mandatory attributes on nodes. (The XCS format does not support them. In the registrymodifications file, oor:mandatory attributes should never be needed, as being mandatory cannot be controlled via the UNO API.) The XCU reading code only evaluates the oor:mandatory attribute for set members, and ignores it everywhere else.

  • Only true sets support mandatory members. A localized property for the "*" locale, though acting much like a set, does not support mandatory members.

  • The LibreOffice Registry Format document claims that group extension properties are implicitly mandatory, but at least the new configmgr code does not treat them like that (i.e., they can be removed again).

  • For simplicity, setMandatory/getMandatory are available as virtual functions at the base Node, even though they can only make sense for GroupNodes and SetNodes that are set members. The default getMandatory implementation returns NO_LAYER, meaning oor:mandatory is not set to true in any layer. (Returning NO_LAYER simplifies the code, e.g., removeByName does not have to check whether getMandatory is called on a member of a true set to decide whether to forbid removal.)

  • When committing changes (made through the UNO API), the "mandatory" status of inserted nodes must be updated (in case the insert is due to a replaceByName, or the "mandatory" flag was added by a concurrent modification of a lower layer). Also, for to-be-removed nodes, removal is ignored for (newly; due to concurrent modification of a lower layer) mandatory nodes (but still recorded in registrymodifications, so may take effect once the lower layer addition is removed again---whether or not that is a good idea).

XcuParser Modification Recording

  • XcuParser records modifications when reading user layer data (valueParser_.getLayer() == Data::NO_LAYER).

  • oor:finalized and oor:mandatoryattributes cannot be set via the UNO API, so it is assumed that user layer data does not contain them (for one, they are not written bywriteModFile; for another, the logic to record modifications expects a locprop(modify,fuse)to be followed by one or morevalue(fuse,remove), which would not necessarily be true if the locprop` were only present in the user layer data to flag it as finalized).

  • The logic to record modifications considers the top of the XML element stack. In the following list of all possible cases, items marked with an asterisk are recorded:

      ... group(modify,fuse) - group(modify,fuse) - ...
      ... group(modify,fuse) - set(modify,fuse) - ...
      ... group(modify,fuse) - *prop(modify,fuse,replace) - value(fuse)
      ... group(modify,fuse) - *prop(remove)
      ... group(modify,fuse) - locprop(modify,fuse) - *value(fuse)
      ... group(modify,fuse) - locprop(modify,fuse) - *value(remove)
      ... group(modify,fuse) - *locprop(replace) ...
      ... set(modify,fuse,replace) - group(modify/fuse) - ...
      ... set(modify,fuse,replace) - *group(replace/fuse) - ...
      ... set(modify,fuse,replace) - *group(remove)
      ... set(modify,fuse,replace) - set(modify/fuse) - ...
      ... set(modify,fuse,replace) - *set(replace/fuse) - ...
      ... set(modify,fuse,replace) - *set(remove)
      Legend:
          "...": zero or more further items
          "- ...": one or more further items
          "modify,fuse" etc.: any of those operations
          "modify/fuse": a modify or a fuse on an existing member
          "replace/fuse": a replace or a fuse on a non-existing member