Bug 8514

Apologies: I should have caught this one. We removed the conditionals that were hiding invalid controls in interactive mode. We need to bring them back to hide the 'new build' and 'new project' buttons in the top bar. 

Elliot's changes as part of bug 8231 should take care of the rest (I think).

gah, forgot the landing template: that will need a conditional as well. We can reuse the landing template from the fido release.

and of course this is growing legs: we will also have to hide / disable all other builds controls in any projects created in build mode:

1. The build form on the top right hand corner of the project builds, project configuration and import layer pages

2. The checkboxes and 'build selected recipes' button in the 'Most built recipes' section of the project configuration page

An alternative option would be showing only the command line builds project when you start toaster in analysis mode.

i like the alternative as it seems quicker. Also, it's the only thing you can have in analysis mode :)

While it's more complex, I think we have to selectively disable parts of the UI. 

This is because there may be use cases where you give different levels of access to a shared build database from different Toaster instances. For example, read-only access to build data from a public, analysis-mode Toaster instance; but write access from a second, private, build-mode Toaster instance.

(In reply to comment #5)
> While it's more complex, I think we have to selectively disable parts of the
> UI. 
> 
> This is because there may be use cases where you give different levels of
> access to a shared build database from different Toaster instances. For
> example, read-only access to build data from a public, analysis-mode Toaster
> instance; but write access from a second, private, build-mode Toaster
> instance.

If this is what you rather go for, the list of UI elements to disable would be:

* 'new build' button in top bar
* 'new project' button in top bar
* build form in top right hand corner of all project pages
* checkboxes in 'Most built recipes' section of project configuration page
* 'Build selected recipes' button in 'Most built recipes' section of project configuration page
* 'Build' buttons in image recipes table and software recipes table
* 'Build' button in the recipes table of the layer details page

Plus the custom landing page without a 'new project' button. 

I think this is all, although I could be easily forgetting something. If you spot anything missing, let me know.

I've thought about this some more, and I'm not sure it's feasible to switch off UI elements (in the short term): there are just too many of them. For example, the project configuration editing etc. is irrelevant in analysis mode, too, so we'd have to disable large amounts of the project config. page as well.

(Though the project can technically be edited in analysis mode, I'm not sure if we want to make that possible, as Toaster can't use the modifications to run a build anyway.)

I could go with Belen's original suggestion, and only show command-line builds when you are in analysis mode. This would involve filtering out all the non-command-line builds from the projects list. Though this would then mean that you couldn't have a read-only Toaster for viewing the output from bitbake builds triggered from a build-mode Toaster (which was my original reason for wanting to just modify the UI).

1. If we want to get this in quickly, I think Belen's is the only realistic option.

2. If we want to spend the time to do it properly (and miss 2.0), I could do a proper analysis to figure out which parts of the UI need to be modified.

3. Or we could just wait until we remove analysis mode, when all of this becomes irrelevant anyway. As this is the plan, (1) is probably the right short-term solution.

Submitted to bitbake-devel:
http://lists.openembedded.org/pipermail/bitbake-devel/2015-October/006600.html

In bitbake master.

Verified