FAQs

  1. In the Liquid State platform, are document-level and page-level tags the same as one-another? Or are they separate tags?
    They’re seperate tags

  2. If I tag both a document and a page with "abc", is there one tag in the back-end that relates to both the document and page? Or are there two tags: one "abc' at the document-level, and another "abc" at the page-level?
    They’re seperate as well. On each document and on each page - the tags are seperate.

  3. Are tag case sensitive? i.e., are "abc" and "ABC" considered to be the same tag or different tags?
    Yes the tags are case sensitive, they are different tags

  4. Within the JSON for a document or page's metadata, the tag entered via the CE UI always seems to include two fields: Label and Term, their values seem to always be exactly the same.
    Is there any difference between these two fields, and would you recommend using one or the other as the source of truth for tags in DocHub?
    Label' is supposed to be a human readable term for the tag, and ‘Term’ is supposed to be for the programmatic systems to read and confirm that the same tag is being used. So the source of truth should be ‘Term’. This should help with programmatic updates for documents. To simplify the UI of Carbon - we treat the ‘Term’ and 'Label’ as the same.

  5. There is a field that sometimes appears within the metadata: scheme. I noticed that although there is an area for this when you are viewing tags in the CE UI, it is always empty.
    By creating a tag via the CE UI, the scheme field is not included in the metadata JSON for that document/page. If you create a tag in Ubiquity, the scheme field is included in JSON but is empty.
    Is this feature current/relevant? Would you recommend including it in our design or ignoring it?
    Just like ‘Label’ is supposed to be for human reading and ‘Term’ is for programmatic system to read the tag, ‘Scheme’ is for content management to set a specific meaning for the tags. This is only to be used if your system design has a need for it. This would only be applicable for Programatic updates and for the sake of simplicity CE UI doesn’t account for it. If you do not have a need for ‘Scheme’ - you should ignore it.

  6. Are the fields within document-level readonly metadata always the same?
    Yes, they are generally the same. It is possible we would add new fields as the system grows but the fields already there won’t be removed or have their change of meaning. If a new field is added - it will depend on case per case basis how it impacts the metadata and we would inform you of the same.

  7. Are the fields within page-level readonly metadata always the same?
    Yes, they are generally the same. It is possible we would add new fields as the system grows but the fields already there won’t be removed or have their change of meaning. If a new field is added - it will depend on case per case basis how it impacts the metadata and we would inform you of the same.

  8. Is it possible to link to an automated document rather than a page within a document?
    No, while you can publish the automated document and then link to the first page where the users could scroll through, you can’t automatically create a table of contents and link to a page within a document.

  9. Is line breaks to paragraph fields supported in Carbon Editor?
    No, Carbon editor is not a html editor, adding line breaks to paragraph fields is not supported, each paragraph should be a single <p> tag and simple styling applied through the editor controls, not through editing the html directly. These limitations are essential for us to support the multiple export formats that we do by limiting the structure of the input in the first place.
    Potential issues -

    1. Adding links in tables and lists using ckeditor

  10. Problems with linking a page to another page?
    Troubleshooting checks -

    1. embedded-id values of Documents should be unique within the Space, so Carbon Editor can match the expected Document.
      We currently do not enforce this for the sake of testing and experimentation, and it is left to you to ensure your Documents don’t have duplicate embedding-id values in Spaces meant of production. As uniqueness is not enforced, there needs to be an algorithm to pick a matching Document when there are duplicate values. The algorithm is to pick the Document that was last created (again, to facilitate experimentation without having to delete/change previous content).

  11. Problems with HTML export extraction?
    Troubleshooting checks -

    1. Please try to use a “proper” zip file extraction software like 7-zip on Windows

  12. Italicised text in PDF export not rendering?
    Troubleshooting checks -

    1. Please double-check that the filenames used in the CSS code are exactly identical to the filenames uploaded, then re-try.

  13. Why does automated documents not update when source advanced search is updated?
    If a Document newly created or edited match a pre-existing Saved Search, they won’t automatically be included in an Automated Document Configuration based on this Saved Search. Advanced Searches are a tool to get a list of Documents/Pages at a given time, they are not meant to be re-evaluated in the background by Carbon Editor, at least not currently. Automated Document Configurations are only triggered automatically when a new Document Version is created, as it is the only (API or) user-created action that signifies content as it currently exists, and is exported/published. To include new Documents and/or Pages, you can edit the Saved Searched and Automated Document Configuration.

Unless otherwise indicated in the Overview page of this WIKI the information contained within this space is Classified according to the /wiki/spaces/ISMS/pages/739344530 as

INTERNAL