unee-t / frontend Goto Github PK

Btw our MongoDB's provider https://cloud.mongodb.com has the login details stored in SSM (account 812644853088):

• MONGODB_WEB_LOGIN
• MONGODB_WEB_PASSWORD

Guessing something to do with MONGO_CONNECT and https://docs.mongodb.com/manual/reference/program/mongodump/#bin.mongodump

https://cloud.mongodb.com/v2/5a051ba44e65816eb3676f6c#clusters/commandLineTools/Dev has some instructions.

Aka https://dev.case.unee-t.com/ Carrying on from the discussion on #42 (comment)

Currently the process is:

1. Create a new login
2. Associate the right permissions in https://dev.dashboard.unee-t.com/ using an Administrator account depending on what resource is accessed

Today the list of user invited to a case is as such:

It would be good if we could differentiate the users based on their relation to the case and to the unit:

• Relation to the case:
  • Reporter: the user who created the case
  • Assignee: the user who is in charge of doing something about it
  • CC: another user in the loop
• Relation to the unit:
  • Tenant (may also be an occupant)
  • Landlord (may also be an occupant)
  • Agent
  • Contractor
  • Management Company

Only on deploy.sh -p

Today in PR41 each user is displayed with a different color code.
This works well and is useful

A interesting way to use color code would be to have the same color code for each user in the same role for the unit (ex: blue for all user with a property management role for the unit).

This is not key for the MVP but would be a nice additional feature as we move forward.

Messages are displayed with time information but no information about the date of the comment

In the MEFE, when we tap on a attachment picture, the picture is shown in full screen (expected behavior).

When we tap on the 'back' arrow, the picture preview is closed and we are sent back to the top of the conversation, we have to scroll back to where the attachment was in the convo.

A better behavior would be:
When we tap on the 'back' arrow, the picture preview is closed and we are sent back to the place in the conversation where the attachment is.

So the build deploy stage was breaking due to the JSON. Stringified still seems to make YAML croak.

But looking at:

       - CLOUDINARY_URL=https://api.cloudinary.com/v1_1/unee-t-staging/image/upload
       - CLOUDINARY_PRESET=ABC
       - COMMIT=a876254
       - METEOR_SETTINGS="{ \"public\": { \"CLOUDINARY_URL\": \"https://api.cloudinary.com/v1_1/unee-t-dev/image/upload\", \"CLOUDINARY_PRESET\": \"XYZ\"
} }"

Why do we have 2x CLOUDINARY_URL & 2x CLOUDINARY_PRESET that are different!?

Can we please keep to just KEY=VALUE type environment variables? 😁

Case description is truncated with no possibility to expand this.

We need to re-route all http traffic to the https version of the site.

use 24h time format instead of AM/PM

The default Time Zone for the BZFE installation will be UTC.

When we create a user in the BZFE, we need to make sure that we record the TimeZone preference of the user in the BZFE.

In the BZFE back end, this is a parameter which is controlled by the user in Preferences > General Preferences > Timezone used to display dates and times.

When adding a new comment from the MEFE, the time zone of the comment seems to be incorrect when the comment is viewed in the BZFE.

Using the COMMIT variable, which is the short hash of the git repo revision its on.

kaihendry@3290af3

The test:
In the MEFE, as user franck go to claim 12345.
This claim is accessible and modifiable for franck.
In the MEFE, using FF on a desktop, create a new comment.
Post the comment.
The comment is posted.
After a short period of time the additional comment disappear in the MEFE.

Once the browser is refreshed the comment re-appears again.

New comment is visible on the BZFE too (good, this was expected)

URL to access cases in the MEFE is
http://dev.case.unee-t.com/claim/xxx
it should be
http://dev.case.unee-t.com/case/

Via https://github.com/unee-t/frontend/blob/master/.travis.yml & travis script deployment master branch commits will be automatically deployed via ecs-cli to the 812644853088 ECS cluster into the meteor service.

AKA https://dev.case.unee-t.com/

@nbiton PR53 displays the list of cases as centred.
It would be best to align left.

I posted here about it https://forums.meteor.com/t/traverse-node-type-is-not-a-function/38842

I'm on shaky ground here. Perhaps a bug should be filed at meteor? Though we would need a reduced example as requested by https://github.com/meteor/meteor/blob/devel/Contributing.md#reporting-a-bug-in-meteor

PR #77
On a case https://unee-t-pr-77.herokuapp.com/case/55273 on the DT version the scrolling is not working on Firefox

Consequence: Not able to see the add comment block

As part of the MVP, we know that some interactions will be triggered in the Bugzilla Front End / BZFE first (the Unee-T dashboard).

The first thing we need to do is to send an alert to the relevant user(s) of the MEFE (email and/or SMS) each time a bug/case is updated in a product this MEFE user has been invited to.

We need to better understand how we can do that.

This is a show stopper: we can't have the BZFE user invite anyone to use the Unee-T MEFE (case.unee-t.com) without this.

@sebdeckers that'll be cool if you can have a go at this :-)

Today when we create a "simple" (Cloudinary) attachment after the picture is taken we need to:
1- click on OK to go back to the Unee-T conversation screen
2- click on the Unee-T 'send' arrow to save the picture.

It would be best to avoid step 2 altogether and have the 'OK' button in Step one post the picture directly

One authentication method to access the BZ installation is to user the user credentials for the rest API (login/password).

A more robust way to do this is to use the API key for the user. The benefit is that we won't pass the login/password anymore: these could be used to access the BZFE directly.

In order to do this we need to create the API for each user in the BZFE and make sure the MEFE has this API too.

This issue it to discuss when and how we could do that

For example in case where an environment variable changes, we can currently looking forward to a 15 minute deployment time via Travis CI.

@nbiton suggested maybe meteor's entry point sets up the environment variables instead of deploy.sh creating a static task definition.

We need to add to https://github.com/unee-t/bugzilla-customisation/blob/master/aws-env.dev#L1
the cloudinary keys.

We'll have different accounts for staging & production. Proposal:

• CLOUDINARY_ACCOUNT (can be public)
• CLOUDINARY_PRESET (probably should be secret)
• CLOUDINARY_ACCESS_KEY_ID (public)
• CLOUDINARY_SECRET_ACCESS_KEY (secret!)

In PR58, the list of case works and could be the default 'go to' page for the mobile interface.

We need to have an easy way to navigate back to this page (list of open cases) when we are on a 'case' page.

Maybe we could make the Unee-T logo and make it clickable to do that...

• Discussion https://unee-t.slack.com/messages/C6YDJ9X3K/
• Mockups https://share.proto.io/TAPKWL/

• Should be accessed on the '/case' route
• Should list all the units which have relevant cases
• Should list the accessible cases under each listed unit
• Should list the dependent cases under each case
• Should have a search feature (TBD)

UI design mock: https://projects.invisionapp.com/d/#/console/12250377/258606425/preview

on the page where the case are listed, if there are more cases than possible to display on the screen it is not possible to scroll down the list of cases.

Tested on Galaxy S8 and on firefox.

A lot of valuable information are stored in the 'solution' (field [cf_ipi_clust_1_solution]) and 'next_step' (field [cf_ipi_clust_1_next_step]) fields.
We need to add more field in the MEFE (read only is fine at first if read/write is too complex...

The Description and Comments fields are not useful enough to be able to interact meanigfully with a case.

We are not using my account: [email protected]

I guess we are using yours Franck? Can you put the username / password into SSM?
https://ap-southeast-1.console.aws.amazon.com/ec2/v2/home?region=ap-southeast-1#Parameters:sort=Name

email addresses are too long.
Display public user name instead of email address

The color code of the left side of the box for 'Solution' and 'Next Step' are the same today.

We should use different color codes for 'Solution' and 'Next Step'

When a case has both a solution and a next step, the expected behavior is to display BOTH the solution and the next step in the main screen for the case.

Today it only displays the solution.

See case 54178 for an example of that

The container that display the date separator between messages sometimes display time.

When time is displayed, it's not using a 24 hours format (the standard we chose to display time information).

In some scenario we need to reset the user password.
Example:

• New user is created for the first time in Unee-T, instead of sending a password, the user just use the 'reset password' procedure to generate a new password.
• User forgets his/her password

We need to have an interface to reset the user password in the MEFE.

There are 2 subtlety to this:
1- In the MVP, if the user resets his/her password in the MEFE, we may NOT want to change the BZ password. If the MEFE also changes the BZ password the user will NOT be able to login to the BZFE...
2- If a user changes his/her password in the BZFE, then the MEFE is not able to connect to that BZ installation anymore.
This should NOT be a concern as the number of users using the BZFE should be very limited. We need a solution (even a manual solution) to handle this if this happens...

On the page http://case.unee-t.com/signup

When I try to create a user in the MEFE and link it to a user which already exists in the BZFE the 'Submit" button does not work. Nothing happens.

Tested on:

• DT:
  • Firefox
  • Internet Explorer
• Mobile
  • iPhone browser

URLs in the MEFE are http.
We need to route all http URL to the https version of the URL

Currently, only the case actions trigger Epics, but we should change all actions to work like that and prune the redux-thunk dependency

https://voice-memos.appspot.com/ is a nice example to draw inspiration from and should be working from Safari 11.

After successful login to the MEFE as of today we are sent to the page:
http://dev.case.unee-t.com/unit/new

This page is not live yet.
A more useful behavior would be to send the user to a page where we ask the user
'enter the case number you want to see'.

After the MEFE user submits this simple form he/she's sent to the page:
https://dev.case.unee-t.com/case/xxx
(formerly http://dev.case.unee-t.com/claim/xxx - see issue #25 and issue #24 too)
Where 'xxx' is the case number that has just been entered.

Expected behavior:
If the BZFE user associated to this MEFE user has credential to see this case, the user will be sent to the case and will be able to interact (based on his/her privileges as defined in the BZFE) on this case (see and add comment, etc...)

This screen should behave similarly to the details screen and show a preloader until the data (in this case, the list of cases) is loaded

By default the list of cases is limited to the first 20 open cases.
We need a way to
1- Toggle between the list of open case only and the list of open and closed cases (all cases)
2- display the list of the other cases if there are more than 20 cases on the list

Each participant's avatar and name should be assigned a color that remains unique in the context of the current case. This should match these designs:
https://projects.invisionapp.com/d/#/console/12250377/266322188/preview
https://projects.invisionapp.com/d/#/console/12250377/266321280/preview#project_console

In the Heroku version of PR41 I am able to log in as franck.boullier

When I try to go to a specific case (case 12345) the page is ever loading.
This error appears on

• FF 57.0.2 (64bits) on a W10 destop
• Chrome on Android (Galaxy S8)

On Galaxy S8 (Android) when trying the MEFE interface to capture "simple" attachment it is possible to take a picture.

When a picture is taken with the phone held vertically, the picture appears rotated 90 degree in the preview.

Also, a white screen is shown for too long if the user is not logged in, but navigating to one of the routes which require authentication, before being redirected to the "Login" view on '/'.
Both are symptoms of the same issue

Blocks #50

For test purposes we may need to log in with different user profiles.

We need a way to log out of the app so we can log back in as another user.