For the moment, when one clicks an instance in the console, its state is diplayed and user actions are displayed as buttons. As an exemple, for a not deployed instance, a user can either deploy or deploy and start. Two buttons. For a deploying root instance, only undeploy is available, and only for a root instance.

Besides, depending on the screen size, the button text sometimes overlaps its border.
These buttons should be replaced by a drop-down menu. More generally, the UI will have to be revisisted once it includes debug and diagnostic features.

Delete actions should be added for applications, application templates and instances.

The filtering icon should not be visible in the preferences.

• Create an application with several instances and display them in the web admin.
• Click an instance. A detailed block appears on the right.
• Invoke the REST API (or use the autonomic) so that this clicked instanced is removed.

The instance will disappear from the list in the web admin.
But the detailed block will still be visible, displaying information of an instance that does not exist anymore.

This would have prevented a bug we had during all 2014, and this would also prevent some regressions.

We need a light Gulp task to package our application for Karaf.
Something that won't download the entire internet...

npm install --production

... is what we need.
However, we do not want to run all the Gulp plug-ins we use in dev mode. For Karaf packaging, only minification and dependencies injection should be applied. So, we should move the associated Gulp plug-ins in the normal NPM dependencies.

We might also update our Gulp tasks to prevent code duplication.

There should be an undeploy action on root instances that are in the deploying state.

There should be a dialog in the console to create new instances.

• Try to update an application that contains errors.
• You should see some error messages then.

But the way they are displayed look awful.
An effort should be done on this.

In the web administration, create 20 root instances with children.
Click one at the bottom of the page. You cannot see its properties. You have to scroll up to see them.

They should be positioned statically (CSS position: fixed).

We should be able to filter application templates with a search field.
Currently, we are blocked because the search field and the listing are handled by 2 different controllers.

Create an action that allows to create a copy of an instance (and its children) in a single clic.

The web administration should be internationalized.
There are several solutions that work with AngularJS for this.

See Angular Translate.
This is what Linagora uses in other applications.

The settings page will have to be updated as well, so that users can change the language from the web interface.

Make sure an application has instances in the undetermined state.
List all the applications. No warning is shown for this application.

This is because the info field is warn and not nr, as written in the web administration.

I try to deploy my roboconf application on Docker containers.

If the target docker is not installed in the Roboconf DM, I'm not able to deploy my VMs without explanations from the Roboconf web-console. The error about the missing deployment target is only logged in Roboconf log files.

Please add an error displayed by the Roboconf web-console about the missing deployment target when loading the application template.

Given that #15 may result in preventing users from uploading a new application, a safety page (or alternative Angular route) should be added to the web administration. If the main page bugs, we will be able to use this other page.

This page will list the targets associated with every scoped instance.

The message server cannot be initialized anymore from the web application.
A workaround for the moment is to set it manually in the DM instance before launching it.

A new instance state was recently added: unresolved.
The web administration should support it.

Add a page to list commands for a given application.
Execution of a command should also be handled in the page.

The Gulp tasks for development work quite well (although we might improve the regeneration). However, we should complete the distribution tasks to...

• ... check quality (done).
• ... minify all OUR js files and group them into a single file (partially done).
• ... group all OUR css files into a single one.
• ... generate a new index.html with the right file paths.
• ... create a Gulp task called watch-dist, quite similar to the watch-dev one.

There is a dedicated page to upload new application templates.
However, to prevent too many clicks, this operation should also be feasible from the new application page.

When we create a new application, we should be able to list the existing templates and create a new application from it.

• Remove commands links, as commands will not be supported for this version.
• Re-add the polling function that updates the instances.

It will be replaced by a web socket in the next version.

• Root instances have 2 main states: deployed_started and not_deployed.
• Other instances have 3 main states: the two previous ones and deployed_stopped.

Now, let's consider the following hierarchy of instances.

instance of VM {    # target
   instance of Docker {  # target
       instance of App {   # ...
              # whatever
       }
    }
}

The console should display the same options for Docker and VM.
It is not the case for the moment. Docker is considered like any instance while it is equivalent to a root instance (scoped instance).

Depending on the system and tools versions (eg. bower, npm ?), the build is not reproductible - and may produce different files, some inducing runtime errors.
That makes the bug itself difficult to reproduce (sic).

In the same way we want to filter application templates, we should be able to filter instances.

There should be a page to test the connection between the DM and the messaging server.
It should also allow to test the connection between the DM and a given agent.

There is a REST API for this (that may need to be completed).

If so, we need different HTML pages, different interactions. We cannot only rely on CSS3 mechanisms. We need a standard version and a mobile version of the web administration.

This may be manageable at the router level in Angular.

In the mobile version, the first page should only list applications, name and qualifier, no description. Touching an application would lead to another page with the description, global action and the list of instances. Clicking an instance would lead to another page with details and action buttons.

We really need different HTML and JS files, since the interactions are radically different. The mobile version must reduce the amount of displayed things, and use more transitive pages.

1. Stop the DM.
2. Refresh the web admin. An error is shown.
3. Start the DM.
4. Check the web admin without refreshing.

The poller function displays instances while the initial error is still visible.

As reported here: roboconf/roboconf-platform#111
There is a red line at border left.

The associated css is in the file app/css/style.css at line 214: border-left: 2px #b23e4b solid;

Complete the dynamic menu with user actions.
User actions may vary from page to page.

Add icons in the files packaging in order to display them in GUIs (web, eclipse, ...) and automatic documentation generation.

the icons could be located side by side with scripts
for instance:
...
roboconf-examples/apache-tomcat-bash/graph/Apache/scripts
roboconf-examples/apache-tomcat-bash/graph/Apache/icons

the icons could have several sizes
roboconf-examples/apache-tomcat-bash/graph/Apache/icons/16x16
roboconf-examples/apache-tomcat-bash/graph/Apache/icons/32x32
roboconf-examples/apache-tomcat-bash/graph/Apache/icons/64x64
...

and each icon could represent a state in the lifecycle
roboconf-examples/apache-tomcat-bash/graph/Apache/icons/32x32/unknown.png
roboconf-examples/apache-tomcat-bash/graph/Apache/icons/32x32/starting
roboconf-examples/apache-tomcat-bash/graph/Apache/icons/32x32/started
...

Instead of invoking directly Restangular, create an angular service that will manage REST invocations.
Example:

RoboconfRestAPI.shutdown();

When updating the state of an instance, the edited instance should be highlighted.
Sometimes, despite the instance name being written in the right part, we do not know which instance is being edited.

Sometimes, an instance will remain in the starting state because one of its dependencies is not there. Sometimes, we would like to be able to determine which one is missing. We should update the console to perform such a diagnostic and display its result.

Some other times, we may want to check how dependencies were resolved.
So, we should in fact be able to display how imports are resolved. This is not easy at all, because we know what an agent references for a given instance, but not what the scripts really use. We should do our best about this.

Application templates are used in the application templates module and in the applications module.
So, a service should be created to share them and prevent duplicated code.

Get the web administration.
Click an instance whose parent is not deployed and started.

Action buttons are shown.
But it does not make sense. Instead, a message should be displayed and indicating the parent is not deployed and started.

In the application/template listing, the displayed icons are coloured variants of the Roboconf logo.
However, when an template archive contains (e.g.) a application.png image in the root directory, it is not taken in account by the web-admin. Same thing if the image is copied in the app/template working directory.

Worse: the platform IconServlet which is supposed to find the app/template icon is never called, which means the web-admin is missing something.

In the same way we want to filter application templates, we should be able to filter applications.

Currently, every time a file changes in the watch-dev task, we delete the target directory and recopy everything. We should improve this by only updating the files that changed.

See https://github.com/sindresorhus/gulp-changed

Everything is in the title.

When one creates an application from a template, the description should be pre-filled with the description of its template.

Store all the used URL and allow to switch from one to another.

Add a page to upload a target.properties file and check it can create and/or delete a VM.

Use if( obj != 'undefined' && obj != null )

As reported here: roboconf/roboconf-platform#112
When one clicks on an instance's button (start, stop, etc), there is not direct feedback for the user. Displaying a spinner on the clicked button would make the application more responsive.

By default, root instances are sorted alphabetically.
It would be great to be able to sort them by state (put started VMs at the top, and not deployed at the bottom).

There should be two new global actions: Sort by Name and Sort by State.

Currently, the application sorts instance paths for display.
However, sometimes, it does not work correctly.

Example: Tomcat_VM and Tomcat_VM2.
Instances from the first are displayed under the second.

Same thing with vmec2tomcatrubis1 and vmec2tomcatrubis10.
This is not up to the client to do this, but to the server. Consider some one wants to create its own client.