expandorg / worker-app Goto Github PK

Things to improve:

1. Add a placeholder text on the inbox that says ethereum address
2. Instead of saying Assign, we should say something so the user knows they are signing a text with metamask. I could see a situation where the user clicks assign after they type in their ethereum address. Maybe instead of saying Assign next to save, we make assign a full length button above the input box that says "Use Metamask Address". Underneath that button it will say or enter your address manually.

Task onboarding is the step before the user can complete a task.
We may want to tell the user they need to complete a test before they can join a task.
We may want to tell the user to agree to an NDA.
We will want to explain to the user what the task is.
We will want to give the user additional information.

In #41 we introduce the first iteration on these screens. It would be helpful to make this generalized in some way so that we can mix/match screens and provide the right data to them similar to what we are doing on the frontend.

Thoughts @jaschaephraim @sslava @DeerBeer ?

The /deposit and /withdraw API endpoints will now only respond with the transaction hash, omitting updated user object:

{ "tx": "" }

Upon receiving this response, the frontend should subscribe for the user object update:

const url = `${process.env.BACKEND_ADDRESS}/users/${userId}/subscribe`;
const source = new EventSource(url, { withCredentials: true });

source.addEventListener('open', () => {
    // connection has opened successfully,
    // handle if you like
});

source.addEventListener('user', (e) => {
    // userResponse is a typical user response, of the form { user: {} }
    // this will include the user's updated state with their new balance

    const userResponse = JSON.parse(e.data);
    source.close();
});

source.addEventListener('error', () => {
    // an error event will always occur when the backend closes the connection,
    // so this is not necessarily an error

    source.close();
});

Please let me know if you have any questions!

After you click deposit it takes a second before metamask balance is determined. In the interim text is displayed. We should show a loading icon until it is ready instead of text and then show the full text

When I got to localhost:3000 I see a ui flash. Ideally it wouldn't flash.

We could put a skeleton of what the site looks like and a loading icon until it is loaded

Steps to reproduce:
Join a job, navigate away from task page back to jobs page.

Desired outcome:
Under the text that says "You have already joined this task", we could put a link on the jobs page that says go to task now and that takes you to the jobs page.

Low priority for now :)

In the deposit dialog, we refer to both the amount of Gems a user owns and the amount of Gems a user has deposited as their "balance". We need to clarify :)

Steps to reproduce:

1. Create account with out confirming email, but it has GEM Tokens
2. Go to jobs
3. X out modal
4. Join the job

Issue:
A user could join a job with an email that isn't confirmed

This isn't a priority right now. I'll comment when we should add this

Steps to reproduce:
Create an account with metamask that has Gem tokens
Add a password
Logon on a different computer with a different metamask
Try to deposit
It will show you the balance of your other metamask (the one you signed up with) but you wont be able to deposit.

This will be solved when we switch from a metamask only deposit system to a system where users can send gems from wherever. For now we should log if this error happens and give a more user friendly error if possible like 'Your ethereum address x is no longer connected to your metamask'

Cursor on Safari is too large
Also a number of elements appear highlighted on safari

Low priority

The screenshot was removed now when you go to join the trivia you see this:

We should make the carousel bigger (see above)/scale up when the user's screen is larger

I tried creating a job without a funding requirement -> anyone can join the job regardless of how many gem tokens they have. On the frontend side the user still couldn't join unless they had tokens, and their token balance showed tokens go to reserve. We should make sure this is implemented correctly on the frontend. Jobs without funding requirements in the db under the jobs table funding_module column saynoop as opposed to requirement.

Pinging @jaschaephraim @sslava

Depends on https://github.com/gemsorg/backend/issues/40

#81 - here is a first attempt to implement onboarding survey :)

The word 'My Tasks' is not clickable so it shouldn't highlight when you hover over it. Alternatively we could nest the assigned tasks under the Jobs link.

Branch: dev
Scenario:
User has no ethereum address but wants to withdraw. They click withdraw and assign their ethereum address with metamask. The window then closes and they have to click withdraw again. The window should stay open and ask how much they want to withdraw.

If a user goes to withdraw gems but their metamask isn't set to mainnet there will be an issue https://github.com/gemsorg/backend/issues/46#issuecomment-399562607

We should inform users withdrawing that they should set metamask to mainnet

If you attempt to assign an ethereum address that belongs to another account the backend will error but no error is shown to the user.

I changed the logout endpoint to POST

Let's make 0 GEMS Reserverd for tasks 1 line. Right now people think it says there balance is 0

On portal.gems.org, I recommend adding "completed tasks" as a button users can click on so they have a record of seeing their work.

On the nav bar I see a 0 randomly.

Deposit minimum should be 500, withdraw minimum should be 1500.
This prevents people from continuously depositing and withdrawing and draining our ether reserves needed to do the transactions.

Right now I go to join task, I see agree and continue, I click agree and nothing happens. From inspecting console I can see this error:

{"error":"User is already assigned a task from this job."}

We should send the user right to the task if they already have 1 completed. I'm not sure if this is better to implement on the backend by returning the correct task, or the frontend by first checking if the user has been assigned a task before showing them the accept modal.

If the user doesn't have gems, but they click withdraw could we open the edit your ethereum modal? This way the user knows they can't withdraw because they don't have an ethereum address. Thoughts?

Right now the task frontend is hardcoded for the trivia task. We should create a second task with a different interface.

So, we need to set-up google tag manager events. And define user's actions we want to track. :)
i've started with simple implementation #71 which tracks user's page views.
@kieranoreilly let's define here list (with names and params) of actions we want to track.

i would suggest to start with following:

• page views + ({ event: 'pageview', url: '/...'})
• login/signup (both: email and metamask)
• successful deposit
• successful withdraw
• join job
• finish task

Thoughts?

What happens after someone clicks forgot password? If they misclicked, is there a way for them to get back to the login screen?

My thought is we could add login to the navigation sidebar

Let's change the request body when updating password from:

{
  currentPassword: <string>,
  password: <string>
}

to:

{
  oldPassword: <string>,
  newPassword: <string>
}

The Trivia question task submission is responding with a 404. I think the endpoint may have to be updated. Also the format of the submission needs to change to match the new backend. Adding this here to keep track of the progress

We should add this on the login page with

If user has no ethereum address, lets display a placeholder text that says "No ethereum address found"

On the account page, after registering with email/pass I see an account address of 0x2. The account address is supposed to be the ethereum address. Since I didn't use metamask my account address should be blank. We should say no address found

If a user has no gems to withdraw we currently show them this when they click withdraw:

I think in the place of the disabled form we could show them a text that says you have no gems to withdraw. Same thing for deposit.

This way the user knows to come back and click the button when they want to withdraw and that they just can't now.

Thoughts?

I have 500 gems, but 0.1 reserved in a task. I can only withdraw 499.9 gems, but I have the option to withdraw 500.

We should prompt the user to confirm their email address before letting them do tasks

When i refresh the page gem-nav-placehoder-bg isn't moving. However, if I disable js and refresh it moves nicely. I wonder why it doesnt move if js is enabled but I refresh the page

I have 0.1 gems pending (unwithdraw-able see #43), but it shows a really large number pending.

Scenario:
User tries to register with an email that already exists
User tries to edit their email to an email that already exists (that isn't their email)

Desired result:
We tell the user that email already exists

Current result:
On the backend we will error, but I'm not sure what the error is.

I'll try this out at some point and post what happens :)

We have a backend constraint limiting withdrawals to 100k gems

Branch: dev
Steps to reproduce:

1. Join task
2. Click agree
3. You are taken back to the page that says you have already joined this task

Not sure how this will work with #41

After submitting your email you see this screen

There is a small typo where it says 'yo' instead of 'to'.
Can we add a link underneath that says 'return to signin'?
Can we add extra bottom padding to the white box so it has the same padding top and bottom?

The icon for the gem here should just be the logo. It shouldn't say Gems.

Steps to reproduce:
Register with an email that is not confirmed
Go to account page
Click edit by the email

Issue:
It will prompt you to confirm your email. Say you had mistyped your email and are now trying to edit, you will not be able to do so unless you notice the back button

Solution:
Edit email should prompt to edit the email. Confirm email should be a separate banner at the top of the page. I imagine the banner would be similar to the error banner we currently have, except not bright green and it says confirm your email

React polymorph separate monolithic React components into:

Component (logic) - Only handle UI logic, do not render markup.
Skin (markup) - Only render the markup, delegate to component.
Theme (styling) - Only concerned about styling your skin.

https://github.com/input-output-hk/react-polymorph

It might be interesting for our modules (generic task ui's)

Not a high priority on the roadmap right now, but thought I'd make a discussion about it and any potential benefits it could have

Benefits I see:

1. We could have many different type of components off the bat
2. Modules can have different styling