asl-19 / civicdr Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 1.0 259 KB

License: GNU General Public License v3.0

JavaScript 79.53% CSS 19.69% HTML 0.78%

civicdr's People

Contributors

Watchers

Forkers

seamustuohy

civicdr's Issues

Export files should have .json extension

For example, when an SP clicks “Download data” when they have tickets selected, they get a file named “Tickets”. The file should be named “Tickets.json”.

Admin view: text in ticket's Notes and IP/SP thread sections

Logged in as admin to the platform.
Opened a ticket. Started typing under Notes section. The text shows up under IP Thread and SP Thread. The same behaviour for text being typed in IP Thread or SP Thread.
This is very error prone and pose a risk of mistakenly sending a comment to wrong target, for example sending an internal note to IP or SP.

SP language & availability

SPs can have multiple staff with different spoken languages. The level of hours that a SP has available to work with an IP can differ depending upon the language that is required of the SP. We should track this as we move forward to see if it should be addressed within the platform somehow.

Users shouldn’t be able to create blank comments on tickets

If a user presses the “Comment” button when the comment text field is blank, the interface should display a validation error rather than submitting a blank comment.

New Site URL redirecting back to staging.

We need to change the staging.js file to use the current address.

Notes section needed on IP and SP pages

There should be an admin only Notes section on IPs and SPs in order to store unstructured notes that are relevant for interacting with that IP and/or SP.

Ticket titles don't show properly

Logged in as admin. Clicked on one of the partners. Showing Tickets for partners: The tickets for that partner showed but the titles are partner's name as oppose to ticket titles.
The creation date for those tickets also shown as today instead of the actual creation date.

secure channel option "adium/pidgin" should be changed to OTR-enrypted messaging

In the secure messaging options for IPs and SPs we list "adium/pidgin". These are clients that support OTR encryption, but they do not necessarily provide OTR encryption. We should be more explicit about what we are asking here.

We should probably survey the users as we move forward on all the secure platforms that they can communicate with so that we can improve and extend this list over time.

No email to IP when ticket is assigned

As per the documentation about email, IP should get an email when the status of ticket is changed. It works when admin changes the status. It does not work though when status is changed automatically upon assignment of a SP. Was that per design or it is a bug?

Should we move from organizational accounts to individual accounts?

User accounts (IP & SP) on the CiviCDR platform are “organizational accounts” instead of traditional “user accounts.”

Only a single implementing partner and service provider pair are allowed to be assigned to a single ticket within the CiviCDR platform. Tickets can be re-assigned to different users within the system. Multiple implementing partners cannot monitor a single ticket. This removes the ability for multiple users who belong to a single organization to collectively monitoring a ticket.

This was met with two main concerns by the participants.

For these types of accounts to work, IPs will need to be provided guidance on how to properly use an organizational account within their existing workflows.
- This is not a common set-up for online applications and IPs will be unfamiliar with it.
- Setting up multi-factor authentication on multiple devices is rarely done. It is a more difficult process that is largely undocumented. IPs will need assistance in doing this correctly.
There are additional security concerns that come with the use of shared accounts.
- The more users who have credentials for an account the more opportunities for that account to be compromised.
- The shared nature of the accounts means that an organizations tickets will not be able to be split across accounts. Therefore there will be a larger set of ticket information in each IP organizations accounts than a single user account would have.

With proper guidance and hands-on support by the CiviCDR team it is likely that IPs and SPs will be able to use the current workflow. The platform will likely have to be changed in the future to allow for shared tickets so that it can accommodate a more traditional individual user account setup.

Handle connection refused from API

If the API doesn't respond after login, the whole app doesn't load. We should flash an error somewhere

This is still relevant, after switching from our login modal to Auth0's. This happens if for example the API is down, nothing gets loaded.

We should pop up a modal that prevents login if the API is down

Something like the following

Create this new file

app/assets/scripts/components/api-status-modal.js

'use strict';
import React from 'react';

var StatusModal = React.createClass({
  render: function () {
    return (
      <section className='modal modal--medium delete-modal'>
        <div className='modal__inner'>
          <div className='warning__group'>
            <h2 className='inpage__title heading--small'>The API is currently unavailable.</h2>
            <p className='inpage__description'>Please check back later.</p>
          </div>
        </div>
      </section>
    );
  }
});
module.exports = StatusModal;

Add the following lines to this file.

app/assets/scripts/views/tickets.js

Add in the top

import StatusModal from '../components/api-status-modal';

add this StatusModal line in the following section (indicated with a plus);

    const ticketsToDisplay = tickets.filter(this.filterTicket.bind(this));
    const checked = tickets.filter(t => t.checked);
    return (
      <section className="section">
+      <StatusModal/>
        <div className="dashboard">
          <header className="inpage__header">
            <div className="inner">
              <div className="inpage__headline">

Layout of navigation menu is broken at mobile viewport sizes

The navigation menu layout that kicks in a viewport widths of 990px and below is broken:

It looks like #nav-block-browse isn’t entirely moved into the viewport – it ends up with a right value of -2rem. The layout of the icon and links also doesn’t look finished.

Server-dependent actions silently fail if associated requests fail

(This is sort of a meta-issue, since AFAIK it probably encompasses changing the logic of several controllers.)

If the user performs an action and the associated request fails, the site should display an explanatory error message.

In the context of an SP, these actions include:

Submitting a comment
Deleting a comment
Submitting the “Edit Provider” overlay form (this one is more significant because the overlay disappears as it would if the request succeeded; if the user doesn’t notice that the underlying screen hasn’t changed, they won’t realize that the submissions failed, and will probably navigate away and lose their changes)

This could happen if their token has expired, their network connection has dropped, or the server fails to respond for some reason.

Steps to reproduce

Open a ticket page
Delete the id_token localStorage entry
Attempt to submit a comment

Actual result

Nothing happens. The error console contains the following:

[Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (messages, line 0)
[Error] Unhandled Promise Rejection: Error: Request failed with status code 401

Expected result

Error message should appear, and if applicable any associated state change or navigation should be cancelled. This could be an in-page error message, or even a simple alert().

CDR-02-002 HSTS configuration could make the website inaccessible (Info)

It was found that the current website currently deploys an HSTS header with the preload flag. This will protect CiviCDR users against MitM attacks on their first visit to the website, because browsers are informed about the HTTPS certificate to accept for this domain. However, this could also result in making the website inaccessible to CiviCDR users when the certificate (created: July 24, 2017, expires in October 22, 2017) is renewed. At the time of writing the max-age is 63072000 which corresponds to 24 months, while the certificate will expire in only 3 months.

There is also a related backend issue.

This issue can be verified by observing the HTTP headers returned by the website as the main URL is being visited:

    Response:
    HTTP/1.1 200 OK
    [...]
    Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
    X-Frame-Options: DENY
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Accept-Ranges: bytes

The same applies to the herokuapp API backend, although in this case the certificate renewal will be performed by Heroku:

    Response:
    HTTP/1.1 304 Not Modified
    Server: Cowboy
    Content-Length: 0
    Connection: close
    X-Powered-By: Express
    Access-Control-Allow-Origin: *
    X-Frame-Options: DENY
    X-Content-Type-Options: nosniff
    Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
    X-Xss-Protection: 1; mode=block
    Etag: W/"284-I38gnx5u1UipH8mPTM4anVXNrRQ"
    Date: Tue, 08 Aug 2017 04:03:24 GMT
    Via: 1.1 vegur

It is recommended to ask for removal from the preload list (if such request was made) and to remove the preload flag from the HSTS header. While users will be unprotected against MitM attacks on their first website visit, possible certificate renewal errors will not result in making the entire website inaccessible to all CiviCDR users.

There are no platform notification preferences for SPs

Currently SPs do not have notification preferences in their profiles. As such they cannot control if they receive platform level notifications. The same options available to IPs should be added to the SP interface.

When adding SPs, an entirely blank search field does not show all SPs

How to duplicate:

An admin clicks "assign to service provider" button on a ticket. Admin does not modify any of filtering fields. Admin clicks on service provider drop down.

What I thought should happen:

A list of all SPs in the system is shown

What did happen

Only a subset of SPs was shown.

Setup production build to setup the production server

We are currently building production by hand. We should integrate production deployment into the CI process. This would likely look like the following:

Add a "production" section to the circle.yml file that pushes the master branch to our production machine. Something along the lines of:

  production:
    branch: master
    commands:
      - npm rebuild node-sass
      - DS_ENV=staging yarn run build
      - scp -r dist username@hostname:/path-to-static-file-location/

Create a user on the production server that is locked down to only be able to add files to the static code directory.
Add an SSH key and configure permissions so CircleCI can push to the production server as the locked down user
Modify the current staging build rule to build from a development branch.

Service providers can’t change their passwords via the web interface

It appears that the only way for a service provider (and presumably an implementing partner) to change their password is to trigger a password reset via the Auth0 interface. This seems like something that should be possible directly within the interface.

Site has many accessibility issues

The site has many accessibility issues, including:

Focus outlines are hidden, which makes keyboard navigation impracticable. If the browser/OS has keyboard navigation enabled (on OS X, System Preferences -> Keyboard -> Shortcuts -> Full Keyboard Access), the user should be able to navigate the site using Tab, Shift-Tab, Space, Return, and the arrow keys.
Actions that modify the view state don’t move the focus or notify the user that the state has changed. Navigating without visual context (e.g. with a screen reader like VoiceOver) is impracticable. e.g.:
- In the header, the profile icon link registers as “Link: Profile”. If non-sighted user clicks on this, they would be correct in assuming this would navigate to a profile page. Instead, nothing happens – they would have to manually navigate around to realize that clicking the link caused the “View Profile” and “Logout” links to appear. The site should focus the first menu item when the menu opens, and capture/retain the focus while it’s open.
- If a user finds the “View Profile” link and clicks it, again, nothing happens from their perspective. The main view changes, but if they can’t see it, the only way for them to know would be to navigate around the page and notice that the content has changed. Their focus remains on the “View Profile” link, and they get no feedback. Instead, the site should focus a descriptive <h1> when the view loads.
- If a user clicks the “Edit” button on the profile page, nothing happens. To access the overlay, they would have to navigate back/up, since the overlay appears before the “Edit” button in the DOM, and even if they reached the overlay, it wouldn’t necessarily be clear to them what it is, or why they’re suddenly backing into “Cancel” and “Save” buttons.
The alt text for the main logo (inside the header <h1>) is “logotype“. It should be “Civil Society Centre for Digital Resilience”. The same applies to other images on the site, if applicable.
The structure and flow of the login page is awkward without visual context, especially if 2FA is enabled and the user isn’t fully familiar with it. I figure the Auth0 stuff might be outside of your control though.

This is only what I’ve found on the first few pages on the service provider UI. Accessibility may be outside of the development scope at the moment, but I figured I should document it so it’s on the radar in the future.

Mobile navigation menu remains open after navigation is triggered

The mobile navigation menu should close when an item is clicked and navigation is triggered.

For example, as an SP, if I open the menu and click “View Profile”, the menu should close as the profile page opens, rather than remaining on-screen and covering up view content:

Site silently fails to load on many browsers

The browser compatibility is pretty limited at the moment. Based on some quick testing, the site only seems to work on the latest versions of Chrome (and Chromium-based browsers), Firefox, Safari, and Edge.

Notably, it doesn’t load on the following browsers:

All versions of Internet Explorer, including 11.
All versions of Android WebKit. This was the default browser and web view engine on Android until 5.0, and the basis for some skinned manufacturer-bundled browsers. Even if these users install and use Chrome, Android WebKit is (to my knowledge) still used to render web views in other apps, including social media apps that people could be referred to CiviCDR from. In our experience the 4.4 browser (roughly equivalent to Chromium 30) and to a much lesser degree the 4.1 browser (roughly equivalent to Chromium 12!) are still out there.
All versions of Samsung Internet until 5.0, which only started getting bundled with Samsung phones this year. There are a ton of popular Samsung devices out there that shipped with earlier versions, and a lot of them can’t update to 5.0. Samsung Internet is essentially just a wrapper around Chromium – you can see a rough breakdown of the equivalent versions here.
Opera Mini in proxy (“Extreme”) mode. This browser isn’t popular in the west, but it’s overwhelmingly popular in a lot of the developing world. Probably pretty difficult to support since it has pretty severe JS restrictions due to the proxy architecture, but would be nice to have all things being equal.

When I say the site doesn’t load, I mean that there’s a blank white screen with no explanation (I’ve attached a few screenshots). This means that a non-trivial percentage of potential IPs (who I think it’s safe to say won’t necessarily be using the latest devices or browsers) are going to hit a brick wall.

The immediate cause of all of these failures seems to be that the affected browsers don’t support ES6 Object.assign, but I’m guessing there are other incompatibilities if you’re using ES6 features.

I’m not familiar enough with React to get into the code and evaluate how difficult expanding the browser compatibility would be, but I assume it wouldn’t be easy to cover a lot of these browsers without fundamentally rewriting a lot of stuff and possibly changing the underlying framework. I’m also not sure if evergreen-only browser compatibility was formally decided.

At the very least, there should be a default message (baked into the SPA base index page) informing users that their browser isn’t supported if the site fails to bootstrap/load, and prompting them to send us an email if they don’t know how to proceed.

IE11 on Windows 10:

Android WebKit on stock Android 4.4:

Samsung Internet on a Galaxy S7:

SP are allowed to change ticket status, but it will not actually change.

SP's only have their name, contact, and the ticket status as options in the edit ticket section. But, their modifications to the ticket status are not saved in the interface. If they are supposed to be able to change ticket status the changes should stay, if they are not supposed to be able to change the status they should not have the option in the interface.

After a ticket is assigned to a service provider, the provider is able to change the state of the ticket (eg to resolved etc.). By examining the requests, it can be seen that the server accepts the state change but as soon as the status of the ticket is fetched from the server again, it has still its old value. The only way to change the status of a ticket seems to be via the admin account.

inconstant field names in partner forms "new" vs. "update"

The name of the notification fields are inconstant between the new partner form and the form to edit partner information. I don't know what impact this might have on the back-end. But, the duplicate names in the new profile form do make functionality testing somewhat difficult.

Typo in 'Create Partner Profile' page

On 'Create Partner Profile' page, we have:
Notification Preferences
Which informational notifications would you like to receive from CiviCDR? (These do not include platform notifications which can be turned off below.)

The platform notification setting is located above this section, not below.

Incident duplication

After submitting an incident by clicking "save", if a user clicks on the save button more than one time, the incident will be reported as many time one clicks the "save" button.

Add partner agreement to the partner creation and edit pages

CiviCDR partners have to sign and agree to a "partner agreement." This agreement should be linked to // available in the CiviCDR platform.

Improve “Filter Tickets” component overflow styling

The current styling of the “Filter Tickets” component is odd:

Why not remove the internal scrolling and show the full list of selections? This would really improve the UX on mobile, where scroll gutters are hidden (so the overflow might not even be perceptible) and internal scrolling can be a really awkward interaction.

If you want to keep the scrolling, it would look better if you set overflow-y: scroll rather than overflow: scroll (and added some padding-right):

CDR-01-001 Web: Complete lack of HTTP Security headers

It was found that the frontend and backend websites fail to deploy HTTP Security headers. This unnecessarily exposes CiviCDR users to Clickjacking, XSS, TLS channel downgrade attacks and other similar client-side attacks. The issue can be replicated as one navigates to the website and backend URLs provided next. Note to observe the returned HTTP headers.

It is recommended to change the above header composition to something like the following. Please note that fixing the headers on the amazonaws.com subdomain will require employing a web server other than Amazon S3 since the S3 does not allow custom HTTP headers.

Clear React deprecation warnings

Quell them if we get a chance:

Won't break the product, though, since we'll never go above React v15.

Copy-editing & spell checking needed on service-type descriptions.

For instance misspellings of constituents as constitutants.

Site always loads home view at init, regardless of URL

If I navigate to a non-home page then reload the page, the app returns to the homepage.

e.g. As a service provider, if I click “View Profile” then reload the page (or duplicate the tab, open a bookmark, etc.) the site loads the homepage and changes the URL path to /#/.

This seems to have something to do with the login/auth process. The site seems to briefly navigate to /#/login/ when it initializes. If this process is intrinsic to the Auth0 implementation, maybe the initial URL path could be stored then restored after login?

CDR-01-002 Web: Lack of TLS on main page enables MitM attacks

It was found that the main CiviCDR page is served over clear-text HTTP. While the actual login HTTP requests are performed over TLS to the backend server, an attacker could change the frontend website to ensure that user-credentials are leaked over clear- text HTTP. Given this premise, an attacker would be able to take over user-accounts.

It is recommended to implement a permanent redirect from clear-text HTTP to HTTPS and to deploy adequate HTTP security headers as proposed under CDR-01-001. This would help mitigate the channel downgrade attacks.

IP: profile cannot be viewed right after creation

Logged in as IP for the first time and successfully created the profile. Then clicked on View Profile (under user logo at the top right). This takes me to this URL with no profile shown. The page is blank:
http://www.civicdr.org.s3-website-us-east-1.amazonaws.com/#/partners/undefined

The profile can be viewed properly when the user logs out and logs back in. Seems the problem happens only when you try to view the profile in the same session you created it.

User can bypass mandatory fields in ticket by typing space

I was able to create a ticket without mandatory fields such as Description of Issue or Steps Taken by typing space. The ticket can be created with minimum information.

CDR-01-004 Web: Amazon S3 Bucket name vulnerable to Cookie Bomb

It was found that the frontend website hosted on Amazon S3 uses a bucket name that could be vulnerable to a Cookie Bomb attack. An attacker can set up a malicious website that is also hosted on the same region and cause a Denial of Service for the users who visit it.

Since anyone can set up their own bucket under the shared s3-website-COUNTRY-REGION-1.amazonaws.com domain, an attacker can prepare a website that sets a significant amount of cookies on the shared domain. This can affect other websites on the same domain, including CiviCDR. As a result, the server will reject every incoming request as it contains a large header.

It is recommended to change the bucket name. The new name should not contain the dot character, so that a transition would mean moving from civicdr.org to civicdr-org, for example. This way no other websites can influence the cookies on the domains as they are protected by the Public Suffix List 2 . Ideally, it should be considered to move the website away from Amazon S3 in order to globally resolve the issues noted in CDR-01-001 and CDR-01-002 as well.

SP Profiles won't allow modification without Admin rating them.

Because of the new error checking it will throw an error. This needs to be fixed before the SP on-boarding. I think this should be made optional anyway.

Add "business days" to SP "start time" field

The CiviCDR platform provides a “start time frame” profile element that represents the speed at which an SP is able to start new cases once they have been accepted. The equivalent term in many other ticketing systems is the “service window.” The options provided (within hours, within days, within a week, etc.) do not include the standard “within X business day(s)” that is included in many of these interfaces.

We should add an equivalent value to the interface.

Admin users cannot delete tickets

I currently cannot delete user tickets from an admin account. When I try to the response is {"error":"Server error!"}

This started when I attempted to delete a user who had a ticket open for them. The system would no longer let me delete that user, and it would not let me delete that ticket. Furthermore, it won't let me delete any other tickets.

@MayaAvaz Could you try to delete a ticket from an admin account to confirm that this is not working?

Site can enter an infinite router loop, possibly when token expires during a session

Steps to reproduce:

Sign in to the site
Delete the id_token local storage entry (in Chrome DevTools, you can do this in Application -> Local Storage)
Perform any action that triggers a router navigation

The site will end up infinitely ping-ponging between /#/ and /#/login. In Chrome and Safari, this freezes the tab and saturates every CPU core:

Chrome won’t offer to kill the tab – I had to use the Chrome Task Manager to kill it.

This method is arbitrary, but both I and a coworker have run into the same scenario organically, presumably when a token expired. Repeating this in Android Chrome causes the entire app (including the browser UI) to stop responding and the phone to rapidly heat up until the system offers to kill Chrome.

Allow Admins to edit ticket titles

Per our earlier conversations even though tickets should be given a auto-generated title admins should be allowed to edit the title of a ticket to make it more intuitive. The current "edit" interface for a ticket does not have a field for ticket title.

New IP login and be taken to the new profile
IP paste paste the base url into URL bar and click enter
IP will be on the list tickets page
at this point an admin can login and look at partners list. IP will not show up.

Add license

The LICENSE is currently empty. The current decision is between an MIT or GPLv3 license.

Problem with updating tickets

Log in as admin
Click on Ticket1 belonged to IP1 and click on Edit
Another window opens showing Ticket1 details
Without changing anything there, click on Cancel
Back to home, click on Ticket2 belonged to IP2 and click on Edit
The new window pops up but shows the details from Ticket1 instead
Change something in the Ticket2 and click on Save
A new ticket now is created under IP1
IP2's ticket (Ticket2) is gone now. IP2 doesn't have any ticket anymore

We need to see if the behaviour is the same for IP or SP.