Skip to content

Commit

Permalink
fix conflict
Browse files Browse the repository at this point in the history
  • Loading branch information
andreadelrio committed Feb 12, 2020
2 parents f5c28e5 + 3d338c1 commit 374d752
Show file tree
Hide file tree
Showing 2,274 changed files with 61,812 additions and 38,763 deletions.
1 change: 0 additions & 1 deletion .eslintignore
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,6 @@ bower_components
/src/plugins/data/common/es_query/kuery/ast/_generated_/**
/src/legacy/core_plugins/vis_type_timelion/public/_generated_/**
src/legacy/core_plugins/vis_type_vislib/public/vislib/__tests__/lib/fixtures/mock_data
/src/legacy/ui/public/angular-bootstrap
/src/legacy/ui/public/flot-charts
/test/fixtures/scenarios
/src/legacy/core_plugins/console/public/webpackShims
Expand Down
10 changes: 3 additions & 7 deletions .eslintrc.js
Original file line number Diff line number Diff line change
Expand Up @@ -302,6 +302,8 @@ module.exports = {
'test/plugin_functional/plugins/**/public/np_ready/**/*',
'test/plugin_functional/plugins/**/server/np_ready/**/*',
'src/legacy/core_plugins/**/public/np_ready/**/*',
'src/legacy/core_plugins/vis_type_*/public/**/*',
'!src/legacy/core_plugins/vis_type_*/public/legacy*',
'src/legacy/core_plugins/**/server/np_ready/**/*',
'x-pack/legacy/plugins/**/public/np_ready/**/*',
'x-pack/legacy/plugins/**/server/np_ready/**/*',
Expand Down Expand Up @@ -353,13 +355,7 @@ module.exports = {
settings: {
// instructs import/no-extraneous-dependencies to treat certain modules
// as core modules, even if they aren't listed in package.json
'import/core-modules': [
'plugins',
'legacy/ui',
'uiExports',
// TODO: Remove once https://github.com/benmosher/eslint-plugin-import/issues/1374 is fixed
'querystring',
],
'import/core-modules': ['plugins', 'legacy/ui', 'uiExports'],

'import/resolver': {
'@kbn/eslint-import-resolver-kibana': {
Expand Down
5 changes: 4 additions & 1 deletion .github/CODEOWNERS
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
Expand Up @@ -69,9 +69,11 @@
# Canvas
/x-pack/legacy/plugins/canvas/ @elastic/kibana-canvas

# Logs & Metrics UI
# Observability UIs
/x-pack/legacy/plugins/infra/ @elastic/logs-metrics-ui
/x-pack/plugins/infra/ @elastic/logs-metrics-ui
/x-pack/legacy/plugins/integrations_manager/ @elastic/epm
/x-pack/plugins/observability/ @elastic/logs-metrics-ui @elastic/apm-ui @elastic/uptime @elastic/ingest

# Machine Learning
/x-pack/legacy/plugins/ml/ @elastic/ml-ui
Expand Down Expand Up @@ -146,6 +148,7 @@
# Kibana Alerting Services
/x-pack/legacy/plugins/alerting/ @elastic/kibana-alerting-services
/x-pack/legacy/plugins/actions/ @elastic/kibana-alerting-services
/x-pack/plugins/actions/ @elastic/kibana-alerting-services
/x-pack/plugins/event_log/ @elastic/kibana-alerting-services
/x-pack/plugins/task_manager/ @elastic/kibana-alerting-services
/x-pack/test/alerting_api_integration/ @elastic/kibana-alerting-services
Expand Down
1 change: 1 addition & 0 deletions .i18nrc.json
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,7 @@
"src/plugins/management"
],
"advancedSettings": "src/plugins/advanced_settings",
"kibana_legacy": "src/plugins/kibana_legacy",
"kibana_react": "src/legacy/core_plugins/kibana_react",
"kibana-react": "src/plugins/kibana_react",
"kibana_utils": "src/plugins/kibana_utils",
Expand Down
18 changes: 18 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,7 @@ A high level overview of our contributing guidelines.
- [Instrumenting with Elastic APM](#instrumenting-with-elastic-apm)
- [Debugging Unit Tests](#debugging-unit-tests)
- [Unit Testing Plugins](#unit-testing-plugins)
- [Automated Accessibility Testing](#automated-accessibility-testing)
- [Cross-browser compatibility](#cross-browser-compatibility)
- [Testing compatibility locally](#testing-compatibility-locally)
- [Running Browser Automation Tests](#running-browser-automation-tests)
Expand Down Expand Up @@ -553,6 +554,23 @@ yarn test:mocha
yarn test:browser --dev # remove the --dev flag to run them once and close
```

### Automated Accessibility Testing

To run the tests locally:

1. In one terminal window run `node scripts/functional_tests_server --config test/accessibility/config.ts`
2. In another terminal window run `node scripts/functional_test_runner.js --config test/accessibility/config.ts`

To run the x-pack tests, swap the config file out for `x-pack/test/accessibility/config.ts`.

After the server is up, you can go to this instance of Kibana at `localhost:5620`.

The testing is done using [axe](https://github.com/dequelabs/axe-core). The same thing that runs in CI,
can be run locally using their browser plugins:

- [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)
- [Firefox](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/)

### Cross-browser Compatibility

#### Testing Compatibility Locally
Expand Down
25 changes: 0 additions & 25 deletions NOTICE.txt
Original file line number Diff line number Diff line change
Expand Up @@ -218,28 +218,3 @@ LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

---
This product includes code that was extracted from angular@1.3.
Original license:
The MIT License

Copyright (c) 2010-2014 Google, Inc. http://angularjs.org

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

111 changes: 83 additions & 28 deletions STYLEGUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ recommended for the development of all Kibana plugins.
Besides the content in this style guide, the following style guides may also apply
to all development within the Kibana project. Please make sure to also read them:

- [Accessibility style guide](style_guides/accessibility_guide.md)
- [Accessibility style guide](https://elastic.github.io/eui/#/guidelines/accessibility)
- [SASS style guide](https://elastic.github.io/eui/#/guidelines/sass)

## General
Expand Down Expand Up @@ -45,10 +45,7 @@ This part contains style guide rules around general (framework agnostic) HTML us
Use camel case for the values of attributes such as `id` and `data-test-subj` selectors.

```html
<button
id="veryImportantButton"
data-test-subj="clickMeButton"
>
<button id="veryImportantButton" data-test-subj="clickMeButton">
Click me
</button>
```
Expand All @@ -74,6 +71,59 @@ It's important that when you write CSS/SASS selectors using classes, IDs, and at
capitalization in the CSS matches that used in the HTML. HTML and CSS follow different case sensitivity rules, and we can avoid subtle gotchas by ensuring we use the
same capitalization in both of them.
### How to generate ids?
When labeling elements (and for some other accessibility tasks) you will often need
ids. Ids must be unique within the page i.e. no duplicate ids in the rendered DOM
at any time.
Since we have some components that are used multiple times on the page, you must
make sure every instance of that component has a unique `id`. To make the generation
of those `id`s easier, you can use the `htmlIdGenerator` service in the `@elastic/eui`.
A React component could use it as follows:
```jsx
import { htmlIdGenerator } from '@elastic/eui';

render() {
// Create a new generator that will create ids deterministic
const htmlId = htmlIdGenerator();
return (<div>
<label htmlFor={htmlId('agg')}>Aggregation</label>
<input id={htmlId('agg')}/>
</div>);
}
```
Each id generator you create by calling `htmlIdGenerator()` will generate unique but
deterministic ids. As you can see in the above example, that single generator
created the same id in the label's `htmlFor` as well as the input's `id`.
A single generator instance will create the same id when passed the same argument
to the function multiple times. But two different generators will produce two different
ids for the same argument to the function, as you can see in the following example:
```js
const generatorOne = htmlIdGenerator();
const generatorTwo = htmlIdGenerator();

// Those statements are always true:
// Same generator
generatorOne('foo') === generatorOne('foo');
generatorOne('foo') !== generatorOne('bar');

// Different generator
generatorOne('foo') !== generatorTwo('foo');
```
This allows multiple instances of a single React component to now have different ids.
If you include the above React component multiple times in the same page,
each component instance will have a unique id, because each render method will use a different
id generator.
You can also use this service outside of React.
## API endpoints
The following style guide rules are targeting development of server side API endpoints.
Expand All @@ -90,7 +140,8 @@ API routes must start with the `/api/` path segment, and should be followed by t
Kibana uses `snake_case` for the entire API, just like Elasticsearch. All urls, paths, query string parameters, values, and bodies should be `snake_case` formatted.
*Right:*
_Right:_
```
POST /api/kibana/index_patterns
{
Expand All @@ -108,19 +159,19 @@ The following style guide rules apply for working with TypeScript/JavaScript fil
### TypeScript vs. JavaScript
Whenever possible, write code in TypeScript instead of JavaScript, especially if it's new code.
Whenever possible, write code in TypeScript instead of JavaScript, especially if it's new code.
Check out [TYPESCRIPT.md](TYPESCRIPT.md) for help with this process.
### Prefer modern JavaScript/TypeScript syntax
You should prefer modern language features in a lot of cases, e.g.:
* Prefer `class` over `prototype` inheritance
* Prefer arrow function over function expressions
* Prefer arrow function over storing `this` (no `const self = this;`)
* Prefer template strings over string concatenation
* Prefer the spread operator for copying arrays (`[...arr]`) over `arr.slice()`
* Use optional chaining (`?.`) and nullish Coalescing (`??`) over `lodash.get` (and similar utilities)
- Prefer `class` over `prototype` inheritance
- Prefer arrow function over function expressions
- Prefer arrow function over storing `this` (no `const self = this;`)
- Prefer template strings over string concatenation
- Prefer the spread operator for copying arrays (`[...arr]`) over `arr.slice()`
- Use optional chaining (`?.`) and nullish Coalescing (`??`) over `lodash.get` (and similar utilities)
### Avoid mutability and state
Expand All @@ -131,7 +182,7 @@ Instead, create new variables, and shallow copies of objects and arrays:
```js
// good
function addBar(foos, foo) {
const newFoo = {...foo, name: 'bar'};
const newFoo = { ...foo, name: 'bar' };
return [...foos, newFoo];
}

Expand Down Expand Up @@ -250,8 +301,8 @@ const second = arr[1];
### Magic numbers/strings
These are numbers (or other values) simply used in line in your code. *Do not
use these*, give them a variable name so they can be understood and changed
These are numbers (or other values) simply used in line in your code. _Do not
use these_, give them a variable name so they can be understood and changed
easily.
```js
Expand Down Expand Up @@ -325,19 +376,18 @@ import inSibling from '../foo/child';
Don't do this. Everything should be wrapped in a module that can be depended on
by other modules. Even things as simple as a single value should be a module.
### Only use ternary operators for small, simple code
And *never* use multiple ternaries together, because they make it more
And _never_ use multiple ternaries together, because they make it more
difficult to reason about how different values flow through the conditions
involved. Instead, structure the logic for maximum readability.
```js
// good, a situation where only 1 ternary is needed
const foo = (a === b) ? 1 : 2;
const foo = a === b ? 1 : 2;

// bad
const foo = (a === b) ? 1 : (a === c) ? 2 : 3;
const foo = a === b ? 1 : a === c ? 2 : 3;
```
### Use descriptive conditions
Expand Down Expand Up @@ -475,13 +525,12 @@ setTimeout(() => {
Use slashes for both single line and multi line comments. Try to write
comments that explain higher level mechanisms or clarify difficult
segments of your code. *Don't use comments to restate trivial things*.
segments of your code. _Don't use comments to restate trivial things_.
*Exception:* Comment blocks describing a function and its arguments
_Exception:_ Comment blocks describing a function and its arguments
(docblock) should start with `/**`, contain a single `*` at the beginning of
each line, and end with `*/`.
```js
// good

Expand Down Expand Up @@ -546,11 +595,17 @@ You can read more about these two ngReact methods [here](https://github.com/ngRe
Using `react-component` means adding a bunch of components into angular, while `reactDirective` keeps them isolated, and is also a more succinct syntax.
**Good:**
```html
<hello-component fname="person.fname" lname="person.lname" watch-depth="reference"></hello-component>
<hello-component
fname="person.fname"
lname="person.lname"
watch-depth="reference"
></hello-component>
```
**Bad:**
```html
<react-component name="HelloComponent" props="person" watch-depth="reference" />
```
Expand All @@ -564,9 +619,9 @@ Name action functions in the form of a strong verb and passed properties in the
<pagerButton onPageNext={action.turnToNextPage} />
```
## Attribution
## Attribution
Parts of the JavaScript style guide were initially forked from the
[node style guide](https://github.com/felixge/node-style-guide) created by [Felix Geisendörfer](http://felixge.de/) which is
licensed under the [CC BY-SA 3.0](http://creativecommons.org/licenses/by-sa/3.0/)
Parts of the JavaScript style guide were initially forked from the
[node style guide](https://github.com/felixge/node-style-guide) created by [Felix Geisendörfer](http://felixge.de/) which is
licensed under the [CC BY-SA 3.0](http://creativecommons.org/licenses/by-sa/3.0/)
license.
65 changes: 65 additions & 0 deletions docs/accessibility.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
[chapter]
[[accessibility]]
= Accessibility Statement for Kibana
++++
<titleabbrev>Accessibility</titleabbrev>
++++

Elastic is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience, and strive toward ensuring our tools are usable by everyone.

[float]
[[accessibility-measures]]
== Measures to support accessibility
Elastic takes the following measures to ensure accessibility of Kibana:

* Maintains and incorporates an https://elastic.github.io/eui/[accessible component library].
* Provides continual accessibility training for our staff.
* Employs a third-party audit.

[float]
[[accessibility-conformance-status]]
== Conformance status
Kibana aims to meet https://www.w3.org/WAI/WCAG21/quickref/?currentsidebar=%23col_customize&levels=aaa&technologies=server%2Csmil%2Cflash%2Csl[WCAG 2.1 level AA] compliance. Currently, we can only claim to partially conform, meaning we do not fully meet all of the success criteria. However, we do try to take a broader view of accessibility, and go above and beyond the legal and regulatory standards to provide a good experience for all of our users.

[float]
[[accessibility-feedback]]
== Feedback
We welcome your feedback on the accessibility of Kibana. Please let us know if you encounter accessibility barriers on Kibana by either emailing us at accessibility@elastic.co or opening https://github.com/elastic/kibana/issues/new?labels=Project%3AAccessibility&template=Accessibility.md&title=%28Accessibility%29[an issue on GitHub].

[float]
[[accessibility-specs]]
== Technical specifications
Accessibility of Kibana relies on the following technologies to work with your web browser and any assistive technologies or plugins installed on your computer:

* HTML
* CSS
* JavaScript
* WAI-ARIA

[float]
[[accessibility-limitations-and-alternatives]]
== Limitations and alternatives
Despite our best efforts to ensure accessibility of Kibana, there are some limitations. Please https://github.com/elastic/kibana/issues/new?labels=Project%3AAccessibility&template=Accessibility.md&title=%28Accessibility%29[open an issue on GitHub] if you observe an issue not in this list.

Known limitations are in the following areas:

* *Charts*: We have a clear plan for the first steps of making charts accessible. We’ve opened this https://github.com/elastic/elastic-charts/issues/300[Charts accessibility ticket on GitHub] for tracking our progress.
* *Maps*: Maps might pose difficulties to users with vision disabilities. We welcome your input on making our maps accessible. Go to the https://github.com/elastic/kibana/issues/57271[Maps accessibility ticket on GitHub] to join the discussion and view our plans.
* *Tables*: Although generally accessible and marked-up as standard HTML tables with column headers, tables rarely make use of row headers and have poor captions. You will see incremental improvements as various applications adopt a new accessible component.
* *Color contrast*: Modern Kibana interfaces generally do not have color contrast issues. However, older code might fall below the recommended contrast levels. As we continue to update our code, this issue will phase out naturally.

To see individual tickets, view our https://github.com/elastic/kibana/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3AProject%3AAccessibility[GitHub issues with label "`Project:Accessibility`"].

[float]
[[accessibility-approach]]
== Assessment approach
Elastic assesses the accessibility of Kibana with the following approaches:

* *Self-evaluation*: Our employees are familiar with accessibility standards and review new designs and implemented features to confirm that they are accessible.
* *External evaluation*: We engage external contractors to help us conduct an independent assessment and generate a formal VPAT. Please email accessibility@elastic.co if you’d like a copy.
* *Automated evaluation*: We are starting to run https://www.deque.com/axe/[axe] on every page. See our current progress in the https://github.com/elastic/kibana/issues/51456[automated testing GitHub issue].

Manual testing largely focuses on screen reader support and is done on:

* VoiceOver on MacOS with Safari, Chrome and Edge
* NVDA on Windows with Chrome and Firefox
Loading

0 comments on commit 374d752

Please sign in to comment.