You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently task documentation is mostly visible via the /taskmappings endpoint, which poses a number of problems:
long list of configured tasks, lack of overview/grouping
only displays tasks that are connected to a topic, not all available tasks
One of the goals is to have BPTL documentation available for non-technical people so they get an idea of which generic building blocks are available. A grouping of the tasks per topic/domain (the python packages are already structured this way!) in the presentation layer would provide a first improvement.
Other improvements are:
documentation (aspects) in Dutch
more textual and less technical documentation
A new documentation section should facilitate this. We can add this to the existing setup and gradually replace existing pages.
Acceptance criteria:
A new entrypoint/page for documentation
All available work units' documentation can be viewed, even if not connected to a topic
Work units are grouped per domain (ZGW, Camunda, ValidSign...)
Documentation is extracted from docstrings - limited to general descriptions.
Nice to have:
Improved documentation parsing/system to document work units. A decorator-like approach could be viable, something like:
@register@task.variable("zaakUrl", "URL reference to the zaak", required=True, type=str)defexample_task(task: BaseTask):
do_stuff()
return {}
but this could also be handled by function ArgSpecs or other formats (Sphinx arg docs for example).
The text was updated successfully, but these errors were encountered:
Currently task documentation is mostly visible via the
/taskmappings
endpoint, which poses a number of problems:One of the goals is to have BPTL documentation available for non-technical people so they get an idea of which generic building blocks are available. A grouping of the tasks per topic/domain (the python packages are already structured this way!) in the presentation layer would provide a first improvement.
Other improvements are:
A new documentation section should facilitate this. We can add this to the existing setup and gradually replace existing pages.
Acceptance criteria:
Nice to have:
Improved documentation parsing/system to document work units. A decorator-like approach could be viable, something like:
but this could also be handled by function
ArgSpec
s or other formats (Sphinx arg docs for example).The text was updated successfully, but these errors were encountered: