Move settings to config page as default?

[Brantone]

Wondering if it's worth moving the settings to the config page to be utilized as default, while still allowing settings to store cookies and override defaults?

Reason: I've had a few monitors set up, get them all configured to look pretty, then show it on a different computer and the columns/text-size is garbled again.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7546837-move-settings-to-config-page-as-default?utm_campaign=plugin&utm_content=tracker%2F580790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F580790&utm_medium=issues&utm_source=github).

[Brantone]

The implication of this is that JobView of function might need bit of retooling for all the parameters:
https://github.com/jan-molak/jenkins-build-monitor-plugin/blob/master/src/main/java/com/smartcodeltd/jenkinsci/plugins/buildmonitor/viewmodel/JobView.java#L30

[jan-molak]

Yeah, I agree, that's a good idea. There's quite a few things people would like to have configurable, so this would be tremendously useful.
Is this something you'd like to pick up? I'm happy to help out but might not have enough time over the coming weeks to drive it myself.

[Brantone]

Yup, can do. Just wanted to ensure it fit with your vision before getting too far in code changes.
The tricky part will be the JobView of functions and when they instantiate a new JobView and all permutations that it could take, so any ideas or insights would be useful.
Originally I was thinking rather than having a growing list of parameters, to reduce the configs down to simply JobView(job, new BuildAugmentor(), RelativeLocation.of(job), Date(), Array parameters) or something like that?

[jan-molak]

A Config object should do the trick: JobView(job, new BuildAugmentor(), RelativeLocation.of(job), Date(), Conifg config). I think it would be cleaner than using just a plain Map or List

You could then have a bunch of getters for all the configuration options:

• config.numberOfColumns()
• config.fontSize()
• config.showTestFailures(), etc.

In unit tests we could use a dummy implementation with some sensible defaults.

What do you think?

[Brantone]

Would it be worth having BuildAugmentor as part of the Config class object?

Also, any preference on folder for where Config.java would reside?

[jan-molak]

Hey @Brantone - no preference w/r to the Config's class habitat, maybe just the top-level package for now and we can move it when there's a need?

Not sure about the BuildAugmentor - it might be easier to have this conversation over code 😃

[drekbour]

I'd take one thing at a time.
PR1 A shared Config object passed into the *Views would make a bunch of things easier.
PR2 Allowing common config to be overlayed by cookie config is a neat idea too.
PR3? BuildAugmentor is another thing entirely.

I need PR1 so will add that and then use as part of #60

[Brantone]

@drekbour Thanks for taking a crack at this, other plugins have hijacked my focus :( I still have some uncommitted code that will be great to make use of this. 👍

[tcollignon]

I have submit the "PR2" like you said. Tell me if it's good for you.