Would you be open to PR with this improvement? Would it be possible to give pointers what would be the best way to tackle it if open to merging?

(btw. the attached mock screenshot seems to be gone?)

The screenshot may get lost during an upgrade issue in past versions of OneDev.

As to the compact list, it is only about saving screen estate? I don't see other value and would like to consider if more users are voting it.

The screenshot may get lost during an upgrade issue in past versions of OneDev.

Has this been fixed? Are there any guards for data loss during upgrade?

As to the compact list, it is only about saving screen estate? I don't see other value and would like to consider if more users are voting it.

Well, screenshot would help here to visualise :-)

For me it's more about ease of navigation and "scanning" the issue list while looking at it. I find typical, tabular view with consistent columns easier to scan without mental switching context - currently in the first column you have issue number + title and then on next line tags. Putting the tags on the same line would allow avoid this switch. Apart from that, with current defaults (25 issues on the page) it require scrolling to see whole list while we have virtually about half of the screen wasted as white, empty space.

(funny thing: Firefox "Take screenshot" -> full page doesn't capture complete page but only visible page)

1-minute toying - adding float: left to div.primary.d-flex.mb-3 and float: right to next row and completely removing:

(obviously it requires more love to look better: tags could be aligned in single column, authors possibly as well, etc)

The image lost issue should have been fixed. It can not be reproduced anymore.

As to displaying issue in single line, it seems sub-optimal to me pushing important info to the right. It is not obvious that if the issue is of critical priority, or if it is a bug or new feature.

And in which state the issue is in.

As to displaying issue in single line, it seems sub-optimal to me pushing important info to the right. It is not obvious that if the issue is of critical priority, or if it is a bug or new feature. And in which state the issue is in.

Hmm... I think we touched on another issue - the labels/tags/states are mixed all together. I would argue that there is little difference if the information is below issue or on the right as the information is simply lost in the "tag soup".

Maybe separating priority from state (those could be displayed next the issue title on the left, ideally as fixed state button/pill) from rest of the labels/tags (left as free-form-tag-soup on the right) would be an option.

On the other hand - "which state it is" - by default only open issues are visible and I argue that displaying state in this view makes no sense -- possibly hide it if it's filtered out?.

Hmm... I think we touched on another issue - the labels/tags/states are mixed all together. I would argue that there is little difference if the information is below issue or on the right as the information is simply lost in the "tag soup".

They are all custom fields in OneDev. User may order/show/hide them via fields&links setting. Separating them into groups require additional setting and I think it is not necessary for now.

State can also be customized. OneDev actually do not know what Open means internally. The issues are by default filtered via query "State" is "Open", and the query can be something else such as "Assignee" is me. Omitting state will cause confusions for many queries.

Hmm... I think we touched on another issue - the labels/tags/states are mixed all together. I would argue that there is little difference if the information is below issue or on the right as the information is simply lost in the "tag soup".

They are all custom fields in OneDev. User may order/show/hide them via fields&links setting. Separating them into groups require additional setting and I think it is not necessary for now.

State can also be customized. OneDev actually do not know what Open means internally. The issues are by default filtered via query "State" is "Open", and the query can be something else such as "Assignee" is me. Omitting state will cause confusions for many queries.

I'm aware that 1dev is quite flexible and those are custom ones, just offered a suggestion how it can be improved if state and priority are critical (I'd still argue those are difficult to fish out no matter where those are located!).

As for the compacting, userCSS to the rescue - it's not perfect but fine enough for couple of minutes of tinkering and (IMHO) improves readability a lot:

tr.issue td div div.primary {
    float: left;
}

tr.issue td div div.secondary {
    float: right;
}

.issue-list > div > .body table > tbody > tr > td {
	padding: 0.2rem;
}

.issue-list > div > .body table > tbody > tr > td.row-selector {
	padding-top: 0.2em;
}

.last-update {
	min-width: 350px;
}

I'm wondering - maybe add option to upload "custom css" per installation?

I think a table layout with each column representing a custom field will be more appropriate for large screen. That needs re-construction of the page. Will do that if there are more requests for this.

I think a table layout with each column representing a custom field will be more appropriate for large screen. That needs re-construction of the page. Will do that if there are more requests for this.

Fair enough :-)

OT:

Attachment got lost again!?

Attachment got lost again!?

This issue is fixed via #1633. It only happens for issues ever losting attachments before, as the permanent attachment storage is not being recreated, so attachments included in subsequent comments also gets lost after nightly temp storage cleanup.