Q.wiki 6.1

— Reading time: about 7 minutes

v6.1
Auf Now! verfügbar
Für Enterprise verfügbar
All content is automatically translated

Note: We have ironed out some more weaknesses in the previous release. You can find a complete listing in the updated release notes of Q.wiki 6.0!

With Q.wiki 6.1 you get an optimized file management! In addition to the familiar attachments that you can delete and re-upload directly in edit mode now, we are introducing the new file pages. These file pages allow you to manage and share files detached from your wiki pages.

New file page

Until now, you could only provide files on wiki pages, for example in a process description or work instruction. This meant that the file always had exactly the same metadata as the wiki page and could only be shared together with it. On the new file page, you now upload your file to Q.wiki all to yourself - independently of a wiki page. Here you then equip your file with your own metadata and control the sharing of the file. This makes it even easier to manage a file and link it to multiple wiki pages.

New file page

New attachment

We have also optimized the attachments for their actual use case: providing files that are only needed within a wiki page. From now on you can manage attachments directly in edit mode. This means: If you want to update attachments, you replace them directly in edit mode and don't have to use the lower attachment list in read mode anymore. Changes to attachments are thus integrated into the normal page history like all other page changes - there is no longer a separate attachment history. This also makes the attachment list outside of edit mode a thing of the past. To neatly separate attachments from file pages, you can no longer link attachments outside the current page. Instead, transfer the attachment to a file page as needed and link it to the desired wiki pages.

New attachment with convert button

What happens to existing attachments?

All existing attachments that only exist on a single page are automatically converted to new attachments with this release. Attachments that are linked on multiple pages are automatically converted to file pages. The timing of the automatic conversion depends on the status of the wiki page that has the multiple linked attachment:

  • Wiki page is in draft status or released status with no open proposed change: the multiple linked attachment is automatically converted to a file page immediately.
  • Wiki page is in released status with open proposed change: The multiple linked attachment will be automatically converted as soon as the open proposed change is discarded or released.

In both cases, the automatic conversion takes place identically:

  • The responsible, area of application, permission settings are transferred from the wiki page to the new file page.
  • The file page takes over the last approval and the last approver and starts approved in version 1.
  • The history of the file remains at the wiki page to which it was attached before the conversion and cannot be transferred. The file page thus starts a new history.
  • The parent page of the file page is the origin wiki page.

Attachments that have not yet been converted can be recognized by the red warning triangle. If a change is necessary, you have two options: Either convert the affected attachment manually or release or discard the affected change proposal and thus start the automatic conversion. Afterwards you change the desired file arbitrarily via the file page. In this way, you ensure that all links remain intact.

Translated with www.DeepL.com/Translator (free version)

Warning for multiple linked attachments

Further improvements

  • When you create a new page, you can now select the page type "File page" and receive an explanatory tooltip if required.

New page creation dialog

 

  • We have reimplemented and redesigned the collapsible paragraphs so that misconfigurations are reliably prevented. You can now additionally change the title of the collapsible paragraph directly in the text. Existing misconfigurations are not automatically corrected by the update.

New collapsible paragraph

Bug fixes

  • Through an accelerated release process, we have added bug fixes already in Q.wiki version 6.0. For a complete listing, please see the updated release notes of Q.wiki 6.0. Also, check this release note regularly for future additions and bug fixes for Q.wiki version 6.1.
  • The app management is now displayed to all users in the KeyUserGroup, even if other groups have been used in it.

 

Discontinuations

  • The separate attachment list outside the edit mode has been removed and replaced in different ways:
    • File type, file size and upload date are now displayed directly on the attachment in read mode.
    • The information "Uploaded by" is now visible in the history of the page.
    • Alternatively, you can add a "comment" in the comments field when sharing the page.
    • The "Edit in Microsoft Office" (WebDAV) feature is now possible on file pages, but no longer on attachments.
    • The "Upload new version" function is replaced by "Delete" or "Upload again" in edit mode or by the corresponding function on the file page.
    • The "version management" is no longer necessary, because the history of attachments is now integrated into the page history. File pages have their own page history.
    • You can now move and rename attachments either directly in the edit mode (Delete/Re-upload) of the wiki page or on the file page in the three-point menu.
    • "Delete" is also possible directly in the edit mode or on the file page.
    • The "Edit comment" function is replaced by comments in the approval workflow.
    • The "Search for references" function is unnecessary for attachments without a linking option. On file pages, it has been replaced by "Dependencies" in the three-dot menu.
  • Attachments only exist in the context of the wiki page on which they were uploaded. Linking to other pages is only possible via file pages. This means that the link type "Q.wiki attachment" is also no longer available. File pages are linked via the link type "Q.wiki content" in the same way as wiki pages.

Additional improvements Q.wiki 6.1.4

  • The last author is now also displayed in the change proposal.
  • When adding links to Q.wiki content, the respective process area is initially searched in app items or tasks instead of the current app.
  • The addition of an extra field in the document header can now be configured per area instead of system-wide.

Additional improvements Q.wiki 6.1.6

  • The glossary interface has been redesigned to match the new look.
  • In the search, attachments are now also marked if they originate from a change proposal.
  • Supported file formats are no longer provided with a .txt extension on file pages. Unfortunately, a retroactive correction of this is not possible. However, by downloading and removing the .txt extension, the original file can be manually corrected and uploaded again.

Additional improvements Q.wiki 6.1.7

  • New key users will now receive an email with the most important information about their new role.
  • The primary action in the configuration mode of applications is now "Update application" or "Publish application".

Preview following releases of Q.wiki 6

In the third release of Q.wiki 6, we focus on relieving you of as much work as possible when converting attachments to file pages. For this purpose, the most of the attachments already marked with warning triangle will be migrated to file pages. The metadata as well as the release status of the original page are transferred, so that attachments that have already been released as file pages do not have to be released again. The attachment history is not transferred to the file page. Instead, the attachment history remains in the page history of the original page. The file page automatically starts a new history following it. The links to the migrated attachments remain intact and then point to the corresponding file page instead.

 

Do you have feedback?

 

 

Contact us

Make an update appointment now!

 

 

Book appointment