We typically include fa-external-link with links that include target="_blank". For consistency, it seems we would want linkify to behave the same way. @spadgett, agree/disagree?

the toArray filter should probably just be:

.filter('toArray', function() {
return _.toArray;
})

the hashSize filter should be deprecated and replaced with a size filter:

.filter('size', function() {
return _.size;
});

Character count is exact match for truncate, so . is removed, ... and See All is added.

Clicking "See All" restores the .

I ran npm install before grunt build.

Might be related to #133

$ grunt build
>> Local Npm module "grunt-cli" not found. Is it installed?
Loading "grunt-karma.js" tasks...ERROR
>> TypeError: Cannot read property 'prototype' of undefined

Running "build" task

Running "clean:all" (clean) task
Cleaning "dist/less"...OK
Cleaning "dist/origin-web-common-services.js"...OK
Cleaning "dist/origin-web-common-ui.js"...OK
Cleaning "dist/origin-web-common.css"...OK
Cleaning "dist/origin-web-common.js"...OK
Cleaning "dist/origin-web-common.min.js"...OK
Cleaning "dist/scripts"...OK

Running "ngtemplates:dist" (ngtemplates) task
File dist/scripts/templates.js created.

Running "concat:ui" (concat) task
File "dist/origin-web-common-ui.js" created.

Running "concat:services" (concat) task
File "dist/origin-web-common-services.js" created.

Running "concat:dist" (concat) task
File "dist/origin-web-common.js" created.

Running "copy:main" (copy) task
Copied 12 files

Running "ngAnnotate:dist" (ngAnnotate) task
>> 1 file successfully generated.

Running "less:production" (less) task
>> 1 stylesheet created.

Running "uglify:build" (uglify) task
File "dist/origin-web-common.min.js" created.
Warning: Task "karma" not found. Use --force to continue.

Aborted due to warnings.

cc @cdcabrera

Working on a fix for this.

Initially may be that karma + deps are all outdated.

Currently these filters are duplicated in console and catalog.

DataService get and list could both deal with a null/undefined/"" URL coming back by resolving its promise as an error.

But watch doesn't have a way to resolve something as error today, so if a watch failed on this issue there is nothing it can do to alert the controller.

There's a lot of code in this directive for handling other types and then special handling for projects. I wonder if we shouldn't have a separate, simpler directive just for projects and leave the other in origin-web-console.

This probably just needs to default to normal or be explicitly set to normal in NotificationService.

We often do:

var foo = data.by('metadata.name');
// foo = {name1: {}, name2: {}, name3: {}}

Which seems to assume that each key will be a single object. But:

var foo = data.by('metadata.namespace');
// should be able to create arrays:
// foo = {namespace1: [many], namespace2: [many], namespace3: [many]}

But instead the last object will win, clobbering all of the previously assigned objects.

var foo = data.by('metadata.namespace');
// should be able to create arrays:
// foo = {namespace1: {oops}, namespace2: {oops}, namespace3: {oops}}

The simple fix that would break all of our code (yay, all the things!) would be to always return an array:

var foo = data.by('metadata.name');
// foo = {name1: [{}], name2: [{}], name3: [{}]}
var foo2 = data.by('metadata.namespace');
// foo = {namespace1: [{}], namespace2: [{}], namespace3: [{}]}

I'm not sure if there is a realistic way to fix this. If not, an alt might be to update it to something like data.byName() & eliminate the implication that it should be able to sort by any key (but even that would be a big refactor).

@spadgett

In order to use the notifications service in mock mode, the service needs to be in the openshiftCommonUI module rather than the openshiftCommonServices module. The openshiftCommonServices module should be limited to services which interact with the backend.

If the service instance is not provisioned correctly, the service should not be considered bindable.

See comments from openshift/origin-web-console#1961

The notification service leaks memory because it keeps all notifications even after they're no longer displayed.

Also, isNotificationVisible should return false if it's drawer only. The intended use of this function was to avoid showing two toast notifications.

Some additional comments by @spadgett:

"I think it would be better to just not keep an array of notifications. Notification service addNotification just broadcasts a message and is done then the toasts notification component can make sure it's not showing the same one twice and drawer tracks current notifications and if they've been cleared itself"

Another issue is that there is now way for user to 'restore' permanently hidden notifications.

Need to investigate if we can use label filter to exclude old replication controllers in the DataService.list call when retrieving applications. If you're not pruning old deployments, you can potentially have a lot of old replication controllers for previous deployments. It would be nice to exclude these using the API rather than filtering on the client.

This prevents origin-web-common-services from being used separately since APIService depends on this constant.

cc @jeff-phillips-18

While converting in-page alerts to toasts, I noticed that some alerts have an onClick action that references the controller $scope. This will prevent $scope from ever being garbage collected since NotificationsService holds on to the notification object indefinitely. We need to find a way to avoid memory links while still having onClick support.

We don't have any instances of this yet, but it's preventing switching some alerts to toasts and could be an easy mistake to make.

@jwforres @jeff-phillips-18 FYI

We should remove input-lg and btn-lg styles now that the form is only in a dialog?

input-lg (current):

Without input-lg:

If you pass alerts to the delete-project component, it shows both a toast and an in-page alert.

If you don't pass alerts, it results in a runtime error.

It makes sense to me to use the alerts when they're passed in and use toasts when they aren't.

@jwforres @jeff-phillips-18

The web console currently doesn't handle subresources that have a different group than the parent. For instance, the apps/v1 API resource list has a scale subresource from autoscaling/v1.

GET https://127.0.0.1:8443/apis/apps/v1
...
    {
      "name": "deployments/scale",
      "singularName": "",
      "namespaced": true,
      "group": "autoscaling",
      "version": "v1",
      "kind": "Scale",
      "verbs": [
        "get",
        "patch",
        "update"
      ]
    }

cc @jwforres @liggitt @benjaminapetersen

/assign
/kind bug
/priority p2

We need to get Travis passing so we can validate PRs aren't breaking anything.

Per this comment originally, if possible lets match DataService API when we create new services to abstract away logic:

// example:
DataService.get(resource, name, context, opts)
// current:
BindingService.bindService(context, name, application)
// ideal:
BindingService.bindService(name, context, opts) // where application prob could be part of context or opts, depending on its internal usage 

I'm a fan of these services to keep controllers, directives, etc clean, just want to make sure we maintain consistency.

@jwforres @jeff-phillips-18

Several places are now retrieving the 'applications' in a project. This should be made into a common service.

Prob just login & list some resources would be sufficient initially & would help encourage us to write tests, etc.

NPM scripts for Common Grunt tasks

The parameter should make it clear that it expects the project's display name so that someone doesn't try to use it later as the unique name for something