As a user, I want to be able to view the items in my list on my mobile (phone type TBD) device, so that I can see all the issues that exist, for the MVP, while away from my laptop. This view will need to progressively scale up to a tablet and then desktop device (separate stories to follow).

Reference:

https://redhat.invisionapp.com/share/KY8LXF5QV

InVision Prototype:

• https://redhat.invisionapp.com/share/XB8HFYE6J
• https://redhat.invisionapp.com/share/798MZ3GG5#/185961156_AddAWorkItem-1-v3-

at the moment, the docker hub push request is based on individual user accounts, as a best practise - this should be removed and a role specific to the project should be setup so credentials can be shared and used as a part of automation in the deployment and test pipeline.

ng2-bootstrap module consists of native Angular2 components and directives, no jQuery or Bootstrap javascript

• Put all three files in one directory inside shared-component.
• Add an output event to handle it into the parent component.

Using the Angular 2 structure for components create a form that allows users to see a work item.

This design of the detailed display form https://redhat.invisionapp.com/share/HF86WI2GY#/screens/181584065

We need a list of what the screen size break points are that we are going to use in styles. Please list it here.

Using the Angular 2 structure for components we need a list view that matches the one in PatternFly. We should be able to take the HTML and CSS from the PF example to create a component.

Reference the designs at https://redhat.invisionapp.com/share/HF86WI2GY#/screens

Hi,

I was trying to connect to the UI to the core using the core's REST API endpoint. That is when I stumpled over the CardService.getCards() method which returns a Promise<Card[]>. There seem to be quite some disadvantages when using a Promise compare to an Observable.

Consider these points (taken from here):

1. Don’t hit the search endpoint on every key stroke.
   Treat the search endpoint as if you pay for it on a per-request basis. No matter if it’s your own hardware or not. We shouldn’t be hammering the search endpoint more often than needed. Basically we only want to hit it once the user has stopped typing instead of with every keystroke.
2. Don’t hit the search endpoint with the same query params for subsequent requests.
   Consider you type foo, stop, type another o, followed by an immediate backspace and rest back at foo. That should be just one request with the term foo and not two even if we technically stopped twice after we had foo in the search box.
3. Deal with out-of-order responses.
   When we have multiple requests in-flight at the same time we must account for cases where they come back in unexpected order. Consider we first typed computer, stop, a request goes out, we type car, stop, a request goes out. Now we have two requests in-flight. Unfortunately the request that carries the results for computer comes back after the request that carries the results for car. This may happen because they are served by different servers. If we don’t deal with such cases properly we may end up showing results for computer whereas the search box reads car.

This 7 minute video gives a nice overview of why wants to use Observables over Promises: https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises

I understand that his requires some changes to how card objects get filtered and passed around.

how do we handle that nodejs is not available on rhel in the version we use ?

This issue is just to track what we know about the situation - not to say we have use nodejs4, we got options.

@kbsingh did you have some context/info on what exactly is available ?

@joshuawilson is nodejs 6 a hard requirement ?

When #83 is completed, we need to externalize all existing static strings to the i18n lang file(s).

To get an idea of what I mean, press ? outside of a text editor on github:

The README is very basic and could use some Markdown niceness.

There should'nt be a seperate config set for development v/s production configs and machine setup - most of the content needed in developer only stages should be abstracted out into either a run time config or collected from defaults at build time.

site specific content should be stripped out in a way that the CI infra, the pre-prod infra, the prod infra and the developer environ can influence them opportunisitically.

There is no consistency in the URL design in the router. These are the URL end points in the code: login, work-item-list, board, quick-add/:id, detail/:id

For some inspiration of URL design, look at Github issue tracker where this issue is reported.

The work items have types and those types define what they will look like and what data they display.

Initially they should have:

• UserStory
• Task
• Bug

The login page should be a component version of the PatternFly style. We should be able to use the HTML and CSS in the PatternFly example.

Steps to Create -

1. Add long description
2. UI shows up all description on main page it should be formatted in some limited word wrap
   
   

What -

• Open the work item list.
• Open developer console to see the network requests.
• Click on the work item state.
• Change it to another.
• Goes through.
• Now again click on the state of the same work item.
• Try changing it to something else.
• It fails with a 500.

Fix -

• On the first change we are not updating the version of the work item.
• Therefore the failure response returns a version conflict error.

For now I have send a pull request (#41) to disable history API and use hash based routing.

But for a better URL navigation, we need to support History API.

Ref: https://developer.mozilla.org/en-US/docs/Web/API/History_API#The_pushState()_method

The index.html should be the default target for all request in the web app. We need a custom Nginx configuration to support this.

Ref. http://stackoverflow.com/questions/13812550/configuring-nginx-for-single-page-website-with-html5-push-state-urls

BTW, if we are going to implement #44 , I think the configuration will become much saner.

As a user, I want to be able to add a new item (quickly) to the list view, so that I can quickly add, one or more work items to the list, while not on my laptop. This needs to follow the mockups in the InVision prototype linked below, as well as the PDD (finalization to come).

• Initial InVision Prototype:
  https://redhat.invisionapp.com/share/K28FKIFTE#/184725156_AddAWorkItem-1-iPhone_5-

Once the design is finalized, this Issue will be updated.

• Two component class having same selector would throw an error. To be on safe side, we should always name the selectors as the class name, that way the chances of such conflict will be minimized.
• Also instead of using declarations at app.module.ts we can use directives in main components to include sub components. That will also help us to minimize the chances of conflict.

The error this problem produces, doesn't have any meaningful message. So, we need to be careful. This looks like a design problem of Angular2. I hope we never run across with a conflict between a selector from global module and local module. I couldn't find a proper solution yet, please post here if anyone can.

In PR #39 I quickly changed the defaults for some URLs and we might need to change this or fix the environment variable usage which was introduced by @nimishamukherjee . That doesn't seem to work.

Right now, various dependencies and dev dependencies are specified using both exact version and using caret:

"karma-mocha": "1.0.1",
"karma-phantomjs-launcher": "^1.0.0",
"karma-sourcemap-loader": "^0.3.7",
"karma-webpack": "1.7.0",

There are two ways how to unify that:

1. use only specific version (e.g. 1.0.1), this approach is easier but requires more commits for deps upgrading
2. use only caret prefix (e.g. ^1.0.1), this way some deps will be auto-updated, downside is that people might use different versions during development and build is not reproducible after some time, this approach should be coupled with using shrinkwrapping (https://docs.npmjs.com/cli/shrinkwrap)

We need a base set of acceptance tests to run against the app for use in the build, release process.

These tests would run after the app is built and pushed into the relevant pod, as a way to verify that the app is now promoteable to productoin loads.

What do you think about having a link in the UI that you can click at any time to create a github issue with pre-filled fields?

For instance, this link creates an issue pre-filled with some values like commit id, page URL.

https://github.com/almighty/almighty-ui/issues/new?title=%3CFILL_IN_PAGE_TITLE%3E&body=%23+Details%0A%20*%20Commit%20ID:%20COMMIT_ID%0A%20*%20URL%20ID:%20URL

Renders as:

Details

• Commit ID: COMMIT_ID
• URL ID: URL

We need to rebase the container build recipe to use https://hub.docker.com/r/centos/nginx-16-centos7/ in order to deploy the prod workload.

Having the id's added to the workitem lists (http://localhost:8088/#/work-item-list) is a big help - thx!

Can we also add id's for the individual details and delete buttons? It;s not difficult to access the buttons relative to their parent's id's:

workItemList_ViewItemDetailBtn = .//[@id='workItemList_OuterWrap_0']/div/div[1]/button[1]
workItemList_deleteListItemBtn = .//[@id='workItemList_OuterWrap_0']/div/div[1]/button[2]

But - it would be much easier to access the buttons could be accessed directly through their id's - for example, by embedding the parent's id digit in the button id. Thx!

Using the Angular 2 structure for components create a form that allows users to update or edit a work item.

This design is the display form and is the closest design we have for the editable form. Until we get a new design we can use it as a template. https://redhat.invisionapp.com/share/HF86WI2GY#/screens/181584065

the present codebase does not build for prod deployments.
$ git clone https://github.com/almighty/almighty-ui
$ export API_URL="http://demo.api.almighty.io/api/"
$ export PUBLIC_PATH="http://demo.almighty.io/"
$ npm install
$ npm run build:prod
is expected to produce a working app, however fails with :

npm ERR! Linux 3.10.0-327.18.2.el7.x86_64
npm ERR! argv "/usr/local/node/node-v6.3.1-linux-x64/bin/node" "/usr/local/node/node-v6.3.1-linux-x64/bin/npm" "run" "build:prod"
npm ERR! node v6.3.1
npm ERR! npm v3.10.3
npm ERR! code ELIFECYCLE
npm ERR! [email protected] build:prod: webpack --config config/webpack.prod.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build:prod script 'webpack --config config/webpack.prod.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the almighty-ui package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! webpack --config config/webpack.prod.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs almighty-ui
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls almighty-ui
npm ERR! There is likely additional logging output above.
npm ERR! Linux 3.10.0-327.18.2.el7.x86_64
npm ERR! argv "/usr/local/node/node-v6.3.1-linux-x64/bin/node" "/usr/local/node/node-v6.3.1-linux-x64/bin/npm" "run" "build:prod"
npm ERR! node v6.3.1
npm ERR! npm v3.10.3
npm ERR! path npm-debug.log.3697563534
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open

npm ERR! enoent ENOENT: no such file or directory, open 'npm-debug.log.3697563534'
npm ERR! enoent ENOENT: no such file or directory, open 'npm-debug.log.3697563534'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

Looks like it's from the renaming of Dockerfile:

dropbox/dev/almighty-ui  master ✔                                                                                                                                                                                                                                            5d  
▶ docker-compose up 
Creating network "almightyui_default" with the default driver
Pulling db (centos/postgresql-95-centos7:latest)...
latest: Pulling from centos/postgresql-95-centos7
3d8673bd162a: Already exists
a3ed95caeb02: Pull complete
5c79d4aadf0c: Pull complete
69056b94959f: Pull complete
Digest: sha256:f76760462eba4e1f7f88d5868ccf9ae4ea39d201042d451063bf5848f32afbe7
Status: Downloaded newer image for centos/postgresql-95-centos7:latest
Creating almightyui_db_1
Pulling core (almightycore/almighty-core:latest)...
latest: Pulling from almightycore/almighty-core
3d8673bd162a: Already exists
219d25306236: Pull complete
1535dcaab3de: Pull complete
Digest: sha256:c8134e550dfe9872e68cb2bfc9332cb7bf4a80be4c439cc9bc013d565ae8a490
Status: Downloaded newer image for almightycore/almighty-core:latest
Creating almightyui_core_1
Building ui
ERROR: Cannot locate specified Dockerfile: Dockerfile

Using the Angular 2 structure for components create a form that allows users to create a work item.

This design is the display form and is the closest design we have for the empty create form. Until we get a new design we can use it as a template. https://redhat.invisionapp.com/share/HF86WI2GY#/screens/181584065

Example of current known global errors:

• backend is not reachable

Example of local errors:

• required field not filled out
• validation errors

We have to find a way to use the Patternfly/Bootstrap JS code in UI. Many widgets we plan to use are utilizing this code (ex. also "basic stuff" like opening/closing dropdowns). At the same time, we have to make sure the code works nicely with Angular 2 and our implementation of it.

The frame should match the UX designs, including basic wireframing and responsive configuration.

In building a (very) basic POC UI automation test (see: #17) I noticed that the UI elements are not defined with unique IDs. as a result, the POC test relies on brittle xPath data to locate UI elements. For example:

public SelenideElement saveButton() {
return $(byXpath("//my-app/work-item-list/div/div/work-item-detail/div/button[2]"));
}

Having unique IDs for elements would make the test automation much easier and the tests more maintainable. Thanks!

We should test the code, ideally via unit tests at build time, and some integration tests to validate the api version matching /expected in the build, and finally deployment acceptance tests.

See current deployed v on http://demo.almighty.io/#/work-item-list

I noticed some odd renderings on mobile devices:

Sometimes the list view items overlap each other, sometimes space is wasted and sometimes the quick add form items are stacked vertically instead of horizontally.

I now, that we're in an early stage but I just wanted to guys let you know this.

iPad

Portrait

Landscape

There is too much space wasted on the right in iPad Landscape mode:

Nexus 5

Portrait

Landscape

This looks rather good I think:

iPhone 5

Portrait

Landscape

There are an unspecified number of states or stages between open and done. At a minimum the work item should show the state it is in and that state should be able to be changed from open to done.

See the design here of the state on the left side https://redhat.invisionapp.com/share/HF86WI2GY#/screens/181584053

Currently, the build outputs some warnings that should be examined:

npm WARN deprecated [email protected]: cross-spawn no longer requires a build toolchain, use it instead!
npm WARN deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

the code should be resiliant to api migrations, and be able to handle api unavilability gracefully for short periods, rather than need bin/wait-for-it.sh like scripts at powerup.

We need some way to visually link in a parent / child way workitems.

Experience 1603E131
A user with appropriate privileges obtains a definition file (for example via a web interface or a command line), edits the definition file which describes a work item link type between two work item types, and, associates it with the project (for example by uploading it via a web browser or using the command line). A default definition file is provided out of the box, and can be modified via this process.. Each link type must describe both the forward and reverse relationship (e.g. Parent/Child, Successor/Predecessor, Tested By/Tests, etc.) and also must also be one of four topologies: Network (undirected; circular relationships possible); Directed Network (directed; circular relationships possible); Dependency (directed; circular relationships prohibited); Tree (directed; circular relationships prohibited; one-to-many).

-- this is not end-user functionality for Pizza the Hutt.

Tod said at the Bangalore meeting, that the UI should have i18n support in place, even if we only support one language (English) for the forseeable time. We need to evaluate i18n solutions, choose one and integrate it in our project.

@kbsingh @kwk At some point of time we need to use separate sub-domain for static content serving except index.html and probably favicon.ico, robots.txt & humans.txt?.

Few reasons:
http://webmasters.stackexchange.com/questions/24955/why-insert-static-files-css-images-javascript-ecc-in-a-subdomain

The current implementation should be reworked to match the UX designs, including introducing the responsive base configuration.

The save button is being ignored - first spotted this late on September 25 - thx!