Folder view matches look of job view

[strangelookingnerd]

Comparing the view of a folder vs. job I noticed some minor differences this PR aims to fix by adapting the definitions in AbstractFolder/view-index-top.jelly to the core.

Most notable changes:

• same size of text and icon
• same display of the "full name" in case a folder is nested

See the following screenshots for comparissions:

Before

Job	Folder

After

Job	Folder

One thing that gave me a hard time is the description - there seem to be multiple of those for the folder and the views? Is that intented? I will need some clarification on this before merging to not introduce regressions.

Proposed changelog entries

• Entry 1: Folder view matches look of job view

Submitter checklist

• JIRA issue is well described
• Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change).
  * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
• Appropriate autotests or explanation to why this change has no tests

[strangelookingnerd]

Maybe someone from @jenkinsci/sig-ux could also provide feedback

[timja]

The ideal would be to reuse core and use that instead so that changes automatically get adapted.

If its possible to adapt here / core / both that would be the best solution.

If its not then what you've done here looks good UX wise (I've not tested it manually).

The main changes I saw were:

• moving description control to the app bar
• smaller icon
• full project name being added

[jtnord]

this has removed the system message from folders. (not tested anything else)

stale

[jtnord]

One thing that gave me a hard time is the description - there seem to be multiple of those for the folder and the views? Is that intented?

You mean a folder has a description and a view can also have one, so when using a view for the folder you have potentially 2 conflicting descriptions?
This is the case for Jenkins core (where jenkins has getDescription() returning the system message yet the view for it also has a description. In this case both are shown.
if that is correct / desired behavour I am not sure. Could probably be argued either way (and possibly depends on the view in use), but one thing is for sure, without a request to change it someone will be relying on the existing behaviour and a change without justification will be a terrible regression for them :)

[strangelookingnerd]

One thing that gave me a hard time is the description - there seem to be multiple of those for the folder and the views? Is that intented?

You mean a folder has a description and a view can also have one, so when using a view for the folder you have potentially 2 conflicting descriptions? This is the case for Jenkins core (where jenkins has getDescription() returning the system message yet the view for it also has a description. In this case both are shown. if that is correct / desired behavour I am not sure. Could probably be argued either way (and possibly depends on the view in use), but one thing is for sure, without a request to change it someone will be relying on the existing behaviour and a change without justification will be a terrible regression for them :)

As I understand it the AbstractFolder has a description field inherited from AbstractItem - this field can be configured but is only visible on the configuration page and nowhere else.
Then the AbstractFolder has a View that has its own description field which is actually shown in the overview and can only be edited there - but not on the configuration page.

I agree, introducing regressions is not my intent, therefor I left it as-is.

[jtnord]

One thing that gave me a hard time is the description - there seem to be multiple of those for the folder and the views? Is that intented?

You mean a folder has a description and a view can also have one, so when using a view for the folder you have potentially 2 conflicting descriptions? This is the case for Jenkins core (where jenkins has getDescription() returning the system message yet the view for it also has a description. In this case both are shown. if that is correct / desired behavour I am not sure. Could probably be argued either way (and possibly depends on the view in use), but one thing is for sure, without a request to change it someone will be relying on the existing behaviour and a change without justification will be a terrible regression for them :)

As I understand it the AbstractFolder has a description field inherited from AbstractItem - this field can be configured but is only visible on the configuration page and nowhere else.

I see it in the folder page.

Then the AbstractFolder has a View that has its own description field which is actually shown in the overview and can only be edited there - but not on the configuration page.

👍

I agree, introducing regressions is not my intent, therefor I left it as-is.

from master I see both descriptions when set

[strangelookingnerd]

from master I see both descriptions when set

Well, now that's embarassing - sorry for the confusion 🤭
I'll try and fix it.

[strangelookingnerd]

Restored the original description beavior in 1a781ba - edited the PR description.

[jtnord]

@strangelookingnerd is this complete from your point of view before i merge?

[strangelookingnerd]

@strangelookingnerd is this complete from your point of view before i merge?

Yes, thanks for taking care of it 👍🏼