UI overlap within Library > Packages when using lengthy ID/ Version Number for Packages

[reecewalsh]

Octopus Version:

Tested and replicated in Octopus version 2018.3.7

Issue:

When navigating to the Built-in Package Repository via Library > Packages, the UI experiences an issue with the Package Description field overlapping the Package Indexing area, when a package exists that has a lengthy ID or Version Number.

Replication Steps:

1) Create and upload a package with a lengthy ID or Version Number

2) Navigate to Library > Packages

Before Introduction of the lengthy package;

After Introduction of the lengthy package;

Workaround:

This issue is not apparent when using the V3 UI, this can be used by replacing app# with oldportal# in the Octopus URL.

Source:

https://secure.helpscout.net/conversation/549467861/25351?folderId=1661945

[pawelpabich]

UI overlap within Library > Packages when using lengthy ID/ Version Number for Packages

[TomPeters]

This problem happens for all columns in this table. The core problem is that the parent element of the div has a width and we want this width to be inherited by the table (we are trying to do this with a width: 100%). However, tables ignore this width constraint, presumably because they have no way of enforcing this width on their columns.

In order to fix this, we need to provide the table cells with some way of constraining their width.

One option is to do a word-break: break-all, but this will look ugly because we want to only break on spaces, not character.

A better way might be to add the following styles to a table cell:

max-width: 0;
text-overflow: ellipsis;
overflow: hidden;

This will start showing ellipsis if a table cell becomes too long, while still allowing the table columns to resizing based on the available space.

Because we are showing an ellipsis, we probably also want to show a tooltip.

One downside is that this changes the way that column widths are calculated, so we will probably also want to add a width: [x]% to each table column as well in order to control their relative widths, but this is feels reasonable.

This problem is not isolated to the packages table, but may affect most or all of the tables in the app. It certainly seems to affect most usages of the PagingDataTable component. For example, here is the release table:

So we should try to find a generic way of fixing this problem, but we should also try to avoid breaking encapsulation by passing classes down to PagingDataTable or similar. Maybe we need to re-think some of our table based abstractions?