musdb

Object overview

In the default tile view of the object overview page, hovering over an object image thus far revealed the object’s name. As object names are often too long to display fully and inventory numbers are the primary means of identifying an object in most museums, this preview text has now been extended to include the inventory numer.

User management

New Options for Managing User Accounts: Disabling Accounts & Setting Account Expiry Dates

Two new options on user editing pages allow disabling logins on an account and setting an expiry date for the account. Both can be useful for administration: If a new worker joins the museum for a project with a clear-cut limitation on funding and time, one can now set the account expiry at the beginning of the project to the end of it. The accounts will then automatically be deleted when the project ends. Similarly, colleagues that leave service temporarily but for a prolonged time (e.g. for a sabbatical) and will not need to use their accounts for that time can have their accounts disabled.

List of Terms of Use

A new tab on a user’s (own) account settings page provides the option to list all usage agreements / terms of use a user has agreed to in the context of their use of museum-digital / musdb and when they agreed to them.

Imports

Limiting Report Mail Size

When a user runs imports themselves using the WebDAV upload, the end of the import process – no matter if it is successful or fails – is marked by the sending of a report via mail. This report usually contains a list of noteworthy operations that happened during the import, e.g. which objects of which inventory number were imported to which object in musdb, identified by its ID. As imports grow, this list of operation grows. To not encounter issues sending the report, it is henceforth limited to a maximum of 2 MB or 10000 lines.

Dry-run Mode

Sometimes it is useful to try running an import to see if it will actually work but not actually process any data. This option has been available in the importer command line interface for a while, among others powering museum-digital:qa. It is now available in the import configuration for self-run imports as well using the setting dry-run. Enabling the setting accordingly stops the importer from actually writing the data into the database and changes the behavior if values that need to be mapped to values in controlled lists at museum-digital are encountered. Usually an import stops the moment such data is to be imported and not yet mapped. During a dry run, the error is collected and the import proceeds. All unmapped entries are listed together at the end of the import, allowing for a simpler mapping (possibly aided by concordance.museum-digital.org).

Dashboard

The first page of the dashboard, which for almost all users also means the start page of musdb right after the login process, was significantly reworked during the last month. The almost entirely unused notetaking features and discourse integration were removed in favor of a feed of recent blog posts. See also the section “Communications” in the respective blog post.

Annotations for the Vocabulary Editing Team

Each event, displayed as a tile on object editing pages, featured speech bubble icons behind each time / actor / place to provide additional comments and hints for the central vocabulary editing team. This positioning of the annotation feature led to confusion over the years, with some users using the feature to comment on the relationship between the entity and the object (for which the event notes should be used). We hence repositioned the links and moved them to the respective entity’s page (e.g. a place page for giving hints and comments on a place entry). The hinting / commenting feature for times has been altogether removed, as providing comments to clarify the meaning of e.g. a year never made much sense.

Smaller Updates and Bugfixes

• Fixed a bug in the HTML generated for listing other objects linked to an object. Links to the other object were broken and are not anymore.
• Image editing pages now embed the image directly instead of using the IIIF API. This reduces resource usage and increases stability at no cost.
• Removed option to manually trigger the rewriting of EXIF and IPTC metadata of object images. Rewriting takes place in the background whenever an image or a linked object is updated, making user-triggered updates obsolete.
• Re-introduce option to repeat linking to the last used linked object
• Updated Swagger UI to version 5.30.3

Frontend

As stated above and lengthily described in the previous blog posts (here, here, and here) we struggled with stability over the last month. This means that most changes in the frontend are aimed at improving stability.

Reworked Default Image Page

Thoroughly described in Updates, AI scrapers, and Resilience, we replaced the default view for single object image pages. While the default view was previously built around the IIIF viewer Mirador, the new default view uses OpenLayers and the unmediated image file for capabilities such as zooming. The new view also brings with it some new features, such as an option to reference specific sections of an image.

Serving Resource-Intensive Pages / Functionalities Only When Resources Are Available

PDF generation, the IIIF Image API, and the suggestions for alternative search queries on failed search pages are now limited to reduce their impact on the overall system stability. This follows two strategies:

• Suggestions on failed search pages and PDF generation will only appear if the overall load on the system is low. The threshold for when or when they are not provided is influenced by the user’s browser language: If a user uses a browser set to the primary language of a given instance of museum-digital (e.g. German in Hesse, Hungarian in Budapest), the threshold is much higher, meaning users will be able to access the pages at a medium server load. In the case of PDFs, high server load will forward users to the print dialogue for object pages instead of receiving a PDF generated on the server side.
• PDF generation and the IIIF Image API are served with a different PHP configuration and set of processes than the rest of the frontend. This configuration significantly reduces available resources for these two functionalities.
• The option to generate PDFs featuring all images of an object with between 10 and 40 images has been entirely removed. Given its constraints, the feature was hard to explain and rarely accessible anyway. The primary “users” were noticeably AI scrapers.

Image Search

The image search feature was refactored and reduced to further separate it from the primary object search. The number of available search options has been reduced to be more easily explainable and reduce possibilities for very resource-intensive queries.

Batch Export of Object Metadata / OAI

Updated the LIDO API to almost entirely match the LIDO as generated during exports from musdb

Smaller Updates and Bugfixes

• Improved performance of object search by tags and places by filtering searched entities to those who are actually linked in the given instance of museum-digital.
• Object groups with only one object are henceforth not displayed and linked on object pages anymore
• Fixed link in footer: Clicking on “museum-digital” should lead to the home / start page of the given instance of musdb.
• Updated Swagger UI to version 5.30.3

nodac

• User-provided comments / hints have been removed for times (see above)
• Tooltips for linked objects now display which institution an object belongs to
  • This is particularly important for vocabulary editors who do not have access to the museums’ data. This way they get a limited preview with the required information for unpublished objects despite their otherwise lacking permissions.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Version control

Until a few days ago, a central and sorely missed feature in musdb was a detailed version history of the data records. For example to be able to trace and restore data after an attempt at batch processing gone wrong or careless errors when deleting field contents.

Such a view of all previous versions of an object record since the start of recording (May 2024) can now be accessed via the “record history” tab when viewing and editing an object in musdb. A new “Open versioning” button appears right at the top.

Clicking on it opens an overlay in which the various versions are listed as a table. The various aspects of the object data set are divided into different tabs and therefore different tables, e.g. for basic information, administrative information, links to collections, keywords, etc.

Batch transfer

A second frequently requested feature – especially after importing – has been the option to transfer the content of one data field of object records to another. If, for example, the information previously stored in the non-publishable data field “object history” is to be stored in the “detailed description” in the future and published there, the transfer from one field to the other can now be carried out for hundreds of objects with the pressing of a few buttons. Like all other “Global Change” options, the batch transfer between different data fields always refers to the results of an object search. The function is available via the sidebar of the object overview once a search for objects has been executed.

The batch transfer between fields based search results can also be used via musdb’s API. For this, a new API route /object/transfer_by_search/{mode} has been added.

At museum-digital, there are four main centrally controlled vocabularies – actors, places, times, and tags. In more traditional collection management software however, the main field to control is usually the object type (is the object a helmet or a painting?). Simple tagging of the objects can serve as a rather good replacement for a controlled set of object types if one simply repeats the object type as a tag.

As long as one only uses simple tagging, it can however do so only to some extend. If the object is a painting that displays a hammer, the object would feature the tags “painting” and “hammer”. If the object is a hammer with an engraving of a painting, it would feature the very same tags. Take the first example: If one wanted to be able to express that “painting” is the object type and “hammer” is something displayed on the object, one would either need to skip using tags again and use the dedicated fields again – or one needs to be able to categorize tags.

We doubled down on tagging by implementing a categorization mechanism for object tags while streamlining the tagging process in musdb and making it faster and easier to use overall.

The new tagging overlay

When clicking the usual link for linking (new) tags with an object in musdb, one will now be presented with an overlay that replaces the previous page of the same functionality. The layout is rather similar to the previous page – new tags and simple links to actors, places, and times are usually be entered using input fields on the left of the overlay. By typing in the relevant input field, a drop-down list appears, from which entries to be linked can be selected. A new tag, actor, place or time entry can be entered by pressing the “enter” key after typing the name. A sidebar on the right of the overlay allows the simple repetition of the last 10 tags, actors, places, or times the user linked to objects.

The differences between the old page and the new overlay play out on two levels. First, there is the simple fact of the new implementation moving a lot of the logic to the client side, i.e. your browser. If one only selects entries from the drop-down menus, this means that all communication with the server runs in the background. Page reloads are thus only necessary when one enters a new, thus far unknown, tags etc. As the overlay does not close after linking a tag, multiple pre-existing tags can be linked quickly one after the other. In effect, this amounts to a much smoother experience in tagging objects than before.

On the other hand, the overlay unites the existing tagging-related functionalities in one. To do so, the currently linked tags, actors, places, and times are displayed in the overlay as small tiles and can be deleted from there using the trash can icon. Tiles for tags feature an additional select field for categorizing the relationship between object and tag. By default, the relationship is set to the generic “tag”. Alternative categorization options are currently:

• Object type
• Material
• Technique
• Display subject

By categorizing the tags in the appropriate way, one keeps all the advantages the controlled vocabulary for tags brings – multilinguality, links to norm data repositories, and findability using hierarchichal searches, while now being specific about the relationship.

Additionally, another icon (the arrow downwards in a hexagon) offers narrowing down the tag to a more specific version. If an object has for example been tagged as a “portrait”, pressing on the icon will open a sidebar suggesting to replace that tag with “self-portrait”.

Effects on search

Of course, categorizing the links helps little without the relevant search options. Hence, we added five new search fields in the extended search menu: Tags (object type), tags (material), etc.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Similarly located in the sidebar of the object editing page, musdb now features a timeline for all time-based information of an object. Primarily focused on providing an overview over said time-based information and hinting at less prominent data points like conservation / restoration measures and loans in the history, this new feature has proven to be located just right. Provenance researchers now use it to find blank spots in the object history that are to be further identified.

How to Use the Timeline?

A preview of the timeline is always visible in the sidebar of the object editing page in musdb, displayed as a simple line with colored indicators for any event, shipment, etc. that has been recorded as happening to the object.

By clicking on the timeline’s preview, the timeline opens in a full screen overlay, which shows the timeline in its full form – with markers for the year of the earliest and latest entry on the timeline (the end of the timeline is always the current year, unless a date in the future has been set for the object [e.g. the copyright expiration date]). Above and below each indicator for something taking place, there’s now also a textual representation of the type of event taking place.

Below the timeline, there is a table presenting the same information in a more orderly fashion. Hovering over an entry in the table highlights the same entry’s representation in the timeline and vice versa. A left click on the entry opens the object page at the respective position, so that one can easily access detailed information about the data point represented.

Finally, the overlay features two date pickers at the very top right. These represent the earliest and latest displayed date in the timeline and table. By updating the dates in these respective fields, one can “zoom” into the selected timespan.
This “zoom” may especially be useful if one works with very old objects like roman coins, whose history is largely unknown between their well-recorded minting and the entry to the museum. In such cases, the timeline may have many entries at its very start and its very end with a large blank spot of 2000 years in between. By appropriately scaling the timeline however, all events that have taken place since the object entered the museum would be so close to each other that they would practically be indistinguishable in the timeline without the zoom feature.

What Can Be Seen on the Timeline?

Now, let’s recapitulate. What can the timeline display exactly? All time-based data points means that the following fields and concepts are displayed:

• Events
• Acquisition
• Reservations
• Checks (for completeness or condition)
• Damages
• Restoration and conservation measures
• Loans
• Shipments
• Exhibitions
• “Periods”: Date any copyright on the object expires, freeze period, scheduled end of deposit, etc.

Additionally, there are some fields that may or may not provide legible information to display. These fields are historically free text fields that are however meant for recording date informations and that can be converted into date fields by enabling the respective strict modes. musdb attempts to parse the information provided in these fields as date information as best as possible, and will display the data points if the extraction of date information was successful. A full date like 2022-01-02 clearly is no proble. A year like 2022 would be parsed to a time span from 2022-01-01 until 2022-12-31. But a statement like “At the start of 2022” is practically illegible and will be ignored in the timeline.
The fields thus displayable only if they contain legible information are:

• Estimation of value
• Determination of insurance value
• Time of first registration in the museum
• Time of entry to the museum (this same information can however be parsed clearly from shipments and acquisition if the respective dedicated modules are used)

This content is licensed under a Creative Commons Attribution 4.0 International license.

To allow administrators and users to get acquainted with the updated design and new features ahead of time, a preview follows below. The update will be distributed on January 11th.

A slight redesign

Sometime in late 2020 or early 2021 – when the reworked dashboard was released – we introduced a new, different design to musdb. While the old design had sidebars with a margin to the window border, the dashboard’s sidebar goes all the way to the windows left end. Where the old design positioned all page contents (minus sidebars and navigation) directly on the background, the dashboard features clearly defined boxes for each section of a page.

Bit by bit, pages that had undergone major updates (e.g. the institution-wide settings page and the image editing page) or were newly added altogether (task management; calendar) also received the new page layout. That way, we could slowly phase in the new design and hopefully managed to warm up users to what musdb would look like in the future.

But keeping two different page layouts side by side also comes at the cost of a harder maintenance and (obviously) a less consistent user experience. With the update, the “new” page layout will hence be extended to all pages.

A few additional improvements beyond even what the dashboard suggested have been made however. Sidebars are now used for displaying additional, directly usable information gained from a given entity’s data much more frequently (e.g. a copy-pastable address block of a contact is now displayed on the contact / address book page). And sidebars of editing pages now (almost) always come with an indicator displaying where the user currently is (“collection”) and the ID of the given entity. This hopefully allows users to better reference the entities down the line – especially when integrating musdb with other applications like Nextcloud (see below).

The clearly distinguishable boxes for each section of a page are now also used on pages for adding or updating entities. Again, to allow users a quicker grasp of where they actually are, these pages also come with much more visible headlines.

In other news …

In November 2022 we introduced maps on which the location of a museum or an object’s closer, unnamed location (e.g. a finding spot of archeological objects) could be determined by a simple click on the map. The colleagues from Baden-Württemberg requested to be able to enter geo-coordinates directly into an input field that interacts with the map, as they already know the coordinates they were to select. The maps thus now come with a button on the top right that allows the user to open a dialogue, in which the location can be entered using pastable geo-coordinates.

User-Defined Reports in musdb

Thus far reports in musdb were exclusively pre-written and provided together with the rest of the software. But in the end, museums are often bound by local regulations or already have forms or reports that may be generally used for a given purpose. Users can now define templates for report formats themselves and generate reports based on a search result, an exhibition (and its objects) or a loan (and its objects) independently. This may e.g. be used for automatically generating loan contracts.

To define a report format, one needs to hold the user role “museum director” and navigate to the institution-wide settings page. At the bottom of the page, one can upload a report template with placeholders marking the spots where object information is to be filled in by the system.

To simplify the implementation and improve security on the server side, only plain-text reports may be uploaded. HTML may be the most useful format for textual information with formatting; CSV for tabular information.

Timed Generation of Reports and Exports

One feature that was often requested, but thus far hard to implement, is to enable museums to generate exports automatically and without user input. This is now possible, both for XML reports and the new custom report formats.

Timed reports and exports are configurable on the institution-wide settings page. Each timed report requires the setting of:

• a start date (when should the first report be sent?)
• an interval (weekly, monthly, annual)
• a selector; usually a search query, written in the query language for searching objects
• mail address of a recipient

Note: As musdb is used by many museums together, we had to set some limitation on this feature. If an export file size exceeds 10 MB (which is also a size that many mail servers simply would deny for attachments), the configuration for the automatic report is automatically removed and a warning mail is sent to the recipient.

Literature entries

Probably the aspect of musdb with the most requests for improvements is the handling of literature entries. Almost any request for making literature entries interoperable with other software (e.g. Zotero for bibliography management or library catalogues) essentially requires a field for defining the type of a given literature entry. The same goes for most common citation standards: Within a citation style, the way of citing for books differs from that for articles, for webpages, or for archival material.

We have now added that rather essential field and – as that is possible using the new field – display a BibTeX representation of the literature entry in the new sidebar of literature pages.

User-specific defaults for adding new Objects

Museums have specializations, and so do people. It’s not rare for people to almost always enter objects of e.g. a given object type, especially if they are working within the context of a project focusing on a given collection (“Digitize all paintings of the museum”). Similarly, all users in the museum likely use the same units for values and measurements of objects.

To speed up the data entry in the case of such fields with unchanging contents, users will now be able set default values for “direct” text fields of an object. Unfortunately, setting defaults for links [e.g. to collections or spaces] and repeatable fields is much harder to implement and not yet covered by this update. Default values for the form for adding new objects can be set in the personal settings.

Take note that defaults can only be set for fields that are displayed on the object addition page. The most basic and generally required fields aside, one can determine which fields are available on the object addition page in the institution-wide settings.

Loans

To be able to better represent the process of a loan in a museum – from the request to the discussion with insurers to the final sending of the objects – we have now added a concise but hopefully reasonably complete checklist of the steps a loan takes within a museum in the sidebar of the loans page. The checklist covers the most common steps within a loan lifecycle and allows simply marking a progress in working on the loan. The last user to update a given entry in the checklist is displayed if a field has been updated at one point to allow following the progress later on.

We were also notified of a very obvious, but thus far overlooked case: Loan requests that are denied. We added the missing field to cover this status of a loan.

Finally, it is now possible to links loans to exhibitions. All loans of an exhibition can be listed together on a tab of the respective exhibition page.

To return to the checklist for a moment: One of the more noteworthy selectable points in the loan checklist is “metadata exchanged”. Adding this point may be opinionated, but hints at the next steps. In November 2022 we added the option to import loan object information following the upcoming EODEM standard. We hope to be able to implement an EODEM export before the update is pushed to the production instances, so that at least museums using musdb can handle loans with minimal duplicate data entry.

Exhibitions

As mentioned above, loans can now be linked to exhibitions. A new tab on the exhibition page allows listing all loans that happened in the context of the given exhibition.

The list of objects of an exhibition is now also redesigned. When linking an object with an exhibition, it is now possible to enter the exhibition room in which the object will be displayed. If this information has been entered for the objects of an exhibition, the list of objects of that exhibition will be grouped by the objects’ locations.

Integration with Nextcloud

Keeping with the theme of allowing for a deeper integration of musdb into the actual everyday work of museums, we have added the option to integrate musdb with a museum’s Nextcloud instance. If the Nextcloud integration is activated, a new widget will be accessible in the sidebar of most editing pages (e.g. for loans).

This widget displays a reference ID of the entity (e.g. LOA-000000005 for the loan with the ID 5). If this ID is present in a folder or filename on Nextcloud (say, there is a folder for everything concerning the loan, which will then be named something like “2022 Loan Brisbane [LOA-000000005]”), musdb can identify the folder or file as belonging to loan and list it in the widget. If the ID is present in a folder name, the folder contents will be listed in musdb.

For this integration to work, musdb connects to Nextcloud using WebDAV (unfortunately we needed to use some properties exclusive to Nextcloud’s and likely OwnCloud’s WebDAV interfaces, which makes our integration incompatible to other storage solutions that also use WebDAV like Google Drive). And to connect via WebDAV, it needs the information to get an authorized access.

To configure the Nextcloud integration, one hence first has to set the base URL to an institution’s Nextcloud instance on the institution-wide settings page. This only has to be done once per institution and simply gives musdb the information necessary to locate the Nextcloud instance.
Once a base URL for the Nextcloud instance has been entered, the username and password for Nextcloud (ideally an app token [can be generated in Settings > Security in Nextcloud]) can be entered on the personal settings page in musdb. Once those are entered, the Nextcloud integration is activated.

Institution and contacts pages

The layout aside, institution and contacts pages have only been minimally changed. A simple but maybe useful small widget has however been added in the sidebars of these pages: An address block to quickly copy-paste the address to e.g. a letter head.

Objects

Finally: Objects. Objects have seen the addition of a lot of new fields, mainly for administrative purposes.

On the “administration” tab of object pages, one can now reserve an object. If an object is currently reserved or will be so in the next week, an indicator will appear in the sidebar.

For logging an object’s history within the museum, we added a number of logs for:

• Damages to an object (Tab: “Restoration”)
• Conservation and restoration treatments for an object (Tab: “Restoration”)
• Scheduled Checks (Tab: Administration). These checks cover e.g. condition checks, but also audits of whether the object information in musdb is complete. This section comes with a notification that can be sent if a check is upcoming.

Deaccessions can similarly now be covered in musdb.

Again reaching for the most practical applications, we have finally implemented linking an object’s actual / permanent location as a “space” rather than simply identifying it using a text field. This way, it is now possible to search for objects that are not currently in the location their expected permanent location.

We also added some simple text fields that are often present in imports and suggested by the Canadian Heritage Information Network’s software requirements checklist. Namely: sex of the object (for biological specimen), the color of the object, and form of the object.

Post image: Courtesy NASA/JPL-Caltech.

musdb

New fields

Other page

Batch updating object information

Instituion-wide settings and adding new objects

Notifications

In other news

• The calendar feature (accessible under the puzzle symbol in the main navigation) can now display tasks or make them subscribable via WebCal (thus implementing a “reminder” as had often been requested)
• PDF of all linked information is now in A4 and uses a two-column layout
• Ukrainian translation
• “Simple A5 PDF” now covers inventorization fields on rear side

md:term

• If two actors have been joined and one has an old links to the page of the actor now deleted, one is now referred onwards to the new, single actor entry. The same works with transferrals between vocabularies (an actor that was transformed into a tag, etc.).
• Ukrainian Translation

Frontend

• Ukrainian Translation
• JSON-based settings for specific institution pages have been removed
• Bulk download of object images
  • An overlay with a message from the museum can be displayed during batch downloads (see above)

CSVXML

• Almost completely rewritten
• The served page now is completely static and all checks and conversions run directly in the browser. This way, no uploads actually happen and the application is completely uncritical to the server’s security. On the other hand, this allows for installing CSVXML as a progressive web app and using it offline.
• We also added some explanatory texts did small updates to the design of the page. A footer now links to the source code and offers to refresh all cached contents of the page (this may be useful when visiting the page after a long time, as the whole application is cached in the browser for offline use).
• A new check also checks for the file encoding. A warning is provided if the data does not appear to be UTF-8-encoded.
• CSVXML is now released open source under the AGPL.

Importer

While the individual parsers for the different export formats are updated very often, the core scripts of the importer are very stable. November 2022 however came with a large update to these core sections, as more categories of data that had not before been covered by the importer (many of them new) can now be imported:

• Contact information (e.g. for object owners; loan partner institution)
• Object’s movement log
• Minimum and maximum temperature, humidity, and lux of an object
• Loans
• Events / Appointments

In terms of the parsers, we extended the LIDO parser to cover the new fields suggested by the upcoming EODEM standard for exchanging loan object information.

In musdb, our inventorization and museum management tool, however, the situation is more complicated. On the one hand, musdb is simply much larger in terms of the offered functionality. Many features have no public equivalent, while the whole question of updating the database is not present in the frontend. The tab-based user interface and the unfortunately often still rather tight coupling between user interface and loading of data from the database has been hindering the development of an API for musdb. A simple API design like the one in the frontend, where you can just add &output=json (or ?output=json) to a page’s URL to retrieve the page’s information in a machine-readable format is made largely impossible by that very architecture. Just adding &output=json to a URL in musdb provides that machine-readable information in an astonishingly high number of cases, but often it is incomplete or otherwise of limited use.

Finally, it is especially musdb where a well-designed API may become interesting to have in the future. It would be great if museums could use their inventory app of choice besides musdb – and any update to public objects would automatically be mirrored in musdb and the frontend of museum-digital in the background. Currently, the same objective can almost be reached using imports, but imports are limited to updates of the same type and do not happen in real-time.

Off to a Good Start: Updating Object Information Using musdb’s API

A first step towards a dedicated API for musdb has now been taken. For the start, all fields directly relevant to the management of objects have been made available using a new public (though obviously authenticated) API for musdb. Further functionalities will be added when the need arises.

Obviously, starting over and writing a whole new API offers a chance to implement things cleanly. Adding the new API required us to refactor the code considerably – and that in turn provided a good opportunity to write unit tests for all functions relevant to the API. The API is thus ensured to stay stable for the foreseeable future (extensions notwithstanding).

In designing and documenting the new API, we took the opportunity to write the documentation using the OpenAPI standard. A desciption of the API in machine-readable JSON can be accessed at /musdb/api in each instance, e.g. at https://hessen.museum-digital.de/musdb/api.

Using OpenAPI also opens the way to all those tools that build on OpenAPI in general. Hence, a human-readable interface for reading about and testing the API could be generated using Swagger UI (thanks!) and is linked in the German-language handbook. Since each musdb API is linked to its respective regional instance, the “try out” buttons do not work in the handbook, but working Swagger UI instances describing the musdb API can be found linked in the “tools” menu of the navigation of musdb.

Next Steps

Even though object information can now be read and updated using the musdb API, there are a lot of features not yet covered. Even a simple task like listing the collections available to the API user is still missing. As this hinders the finding of IDs for linking with objects, it is a natural next step for implementation.

Working with OpenAPI on the other hand has been a pleasure. We are looking forward to eventually (hopefully sooner than later) being able to provide an OpenAPI description of the frontend API as well.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Text blocks in musdb are managed on a per-field basis. The first step to using them is thus to select an input field, for which the text blocks are to be used. To do so, a klick into a given field is sufficient.

Klicking on an input field triggers an indicator at the bottom right of the screen to appear. This indicator features basic information about the field and the entered contents – e.g. whether it is a required field or the relation between entered characters and the maximum number of allowed ones. At the bottom of the indicator, there are however also buttons that lead to field-specific functionalities.

A click on the “repeat” symbol (or pressing CTRL+r on the keyboard while an input field is activated) opens a sidebar at the window’s right. This sidebar consists of a list of all available text blocks and – at its bottom – an input field for entering new text blocks.

Clicking on a text block or pressing its corresponding number inserts the text block into the previously selected input field. Inserting new text blocks doubles as a deletion and sorting function: for each input field one can only store up to nine text blocks. If a tenth text block is entered, the oldest one is deleted and the numbering adjusted accordingly.

This content is licensed under a Creative Commons Attribution 4.0 International license.