Bug 39281 - Provide a UCR glossary
Provide a UCR glossary
Status: NEW
Product: UCS manual
Classification: Unclassified
Component: General
unspecified
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: Docu maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-28 13:08 CEST by Michael Grandjean
Modified: 2020-06-26 11:25 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): External feedback, Roadmap discussion (moved)
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2015-08-28 13:08:42 CEST
We should have a glossary for all existing UCR variables. It should contain at least the following information:

* name
* category
* description
* default value
* possible values
* which templates / scripts / modules does it affect?
* to which package does it belong?

Vendors of third-party apps should be commited to provide a similar documentation of the UCR variables they use/create.
Comment 1 Philipp Hahn univentionstaff 2020-05-22 13:48:55 CEST
UCRV are not static, but changes all the time. It would be better to have a tool for that and/or extend the UMC module to display that information.

(In reply to Michael Grandjean from comment #0)
> We should have a glossary for all existing UCR variables. It should contain
> at least the following information:
> 
> * name
> * category

In UMC you can only search for it, but it is not displayed

> * description

Tooltip on mouse-over and displayed in the UMC edit dialog

> * default value

Currently we have many defaults:
- set via `debian/$pkg.postinst`
- also depends on version first installed as defaults change over time
- coded into individual templates
- ...
Bug #38938 tries to unify that into a new default layer.

> * possible values

UCR performs no syntax validation and possible values are only described in human readable text. For UCR everything is a "string", the "Type" annotations in UCR info files is nowhere evaluated.

> * which templates / scripts / modules does it affect?

Bug #16418 asked for `ucr commit --dry-run`, but got closed as WONT-FIX.

python -c 'import re
import sys
from univention.config_registry.handler import ConfigHandlers
ucrv = sys.argv[1]
all_handlers = ConfigHandlers()                                                                                                                                                                                                                                            
all_handlers.load()
the_handlers = set()
for reg_var, handlers in all_handlers._handlers.items():
  if re.compile(reg_var).match(ucrv):
    the_handlers |= handlers
for handler in the_handlers:
  for attr, txt in dict(to_file="File", script="Script", module="Module").items():
    try:
      print("%s: %s" % (txt, getattr(handler, attr)))
      break
    except AttributeError:
      pass
  else:
    print("Unknown handler: %s" % (handler,))
' 'ldap/base'

> * to which package does it belong?

UCRV do not belong to _one_ package only: Normally there is one package which provides the UCRV info file, but in may cases that is univention-base-files.

> Vendors of third-party apps should be commited to provide a similar
> documentation of the UCR variables they use/create.

The most sensible location for that would be the UCR info files as they already contain the description, Type (and in the future Default) information.
A tool to parse that and to generate a document from that looks more promising.
Bonus points for including that into the UMC module.