Export
we have just deployed a couple of significant changes when it comes to handle
exports, in particular to handle many many many export jobs.
Talking about export functionalities – in case you haven’t seen it – we have recently published a short tutorial blog post on how to automate exporting. Worth to read
as soon as you want to automate.
But now – here more details on the changes of the Export Forms and Templates as
well as the Export Jobs handler!
Regards – your Coreon Team
Towards a Manageable List of “Recent” Export Jobs
Imagine you are creating export files every night to publish into – say – Acrolinx or Congree for terminology checking. You are further creating every week a set of pdf glossary files … that makes, say, 15 export files per week, i.e. 60 exports per month … after couple of months we have a couple of hundred smaller and larger files around…
Should Coreon play the role of a file / document repository, with filtering or searching functionalities, with features to select and batch delete “mine”, “this-user’s” or “all jobs older than: ” etc. Hmm?
When considering this – see above – valid requirement we decided to go with a slightly more pragmatic and simpler solution: namely to purge the jobs list while allowing to keep recent and also selected important files.
That means: By default, the system is now removing “older” job files automatically when a new export job starts. Thus the list remains pretty short and the most recent ones are kept.
There are two exceptions to this rule:
- The ten most recent ones are always kept.
- You can mark an export file to be excluded from purging. Then it will never be removed.
Note: embedded transformations of an export job are not counted as a job on its own. The behaviour above applies only to the “root” of an export job.
Export Form: Re-Layouted “Selector” Section
The selector which concepts and terms (via a filter) and also which
languages, properties, relations are to be exported has been reworked.
Particularly when working in repositories with many languages and many
properties it was not so intuitive to pick right the desired items that
should go into an export and to exlude the undesired ones.
The presentation UI and interaction has been reworked:
- A clean summary view what exactly will be in the export file.
- A drag’n drop based control to move languages, properties, relations in or out.
- For Excel export: the given order of the languages will be taken into account when writing the spreadsheet columns.
Miscellaneous
You may also notice couple of UI embellishments and clean-up in the dashboard,
the export forms and their controls.
Besides these export related functionalities, two further noteworthy fixes made it
in:
- Unique siblings rule: The repository model rule for “unique siblings” was in some circumstances not applied. This has been fixed.
- Access control rules: Rendering of children and children-of-children concepts failed in the concept map, namely when one of the broader concepts was forbidden to be accessed. Then the map couldn’t be drawn. This has been fixed: The complete map is drawn, even when you lack access to one of the “inbetween” concepts. For these ones a meaningless node is shown to guarantee the appropriate rendering of the graph while hiding, as configured, any confidential information contained in that concept.
