Conflict Analysis on Claim Review

[YashKumarVerma]

Fixes #260
Follow up of #279 as tree became too messed up.

• Shows tab wise
  • List of claims which submitted the same issue
  • List of claims which submitted the same PR
  • List of claims which submitted both items same.
  • Three separate tabs with numbering to inform about linked claims
  • Tabs don't show when no linked/conflicting claims present.

---

Underlying Idea

With #390 sent, now we can create a more robust conflict view.
Reasons:

• There are multiple PRs sent for the same issue. we need to list them.
• Shows number of PRs for single issue submitted on BOSS portal
• 
• There are
  • 100 claims which have the same URL submitted for both handles.
  • 140 claims which have different URLs submitted

Only displaying claims which submit the same issue and same PR may not provide full context.
Admins must have a complete view of where all were the issues and pull requests submitted

---

UI

Zoom

[YashKumarVerma]

@hereisnaman

[thenamankumar]

To merge this PR the one I asked for earlier has to be merged first. This PR doesn't take care about different url formatting. Secondly you are pulling all the data upfront when only some part of it is required.

[YashKumarVerma]

To merge this PR the one I asked for earlier has to be merged first. This PR doesn't take care about different url formatting.

Thanks for the review.
The reason that it does not accommodate the irregularities (ending hash, spaces, slashes) is that once the pr which fixes the URLs is done, no new occurrences of any such irregularity would arise, and the older ones would be fixed too.

Secondly you are pulling all the data upfront when only some part of it is required.
Can you please elaborate this one? is it about getting all details of the claims on the view ?

[thenamankumar]

To merge this PR the one I asked for earlier has to be merged first. This PR doesn't take care about different url formatting.

Thanks for the review.
The reason that it does not accommodate the irregularities (ending hash, spaces, slashes) is that once the pr which fixes the URLs is done, no new occurrences of any such irregularity would arise, and the older ones would be fixed too.

Secondly you are pulling all the data upfront when only some part of it is required.
Can you please elaborate this one? is it about getting all details of the claims on the view ?

On a re look it seems fine to have the current clause.

About loading data. In getConflictsReport I can see you are loading data for issues, pull and both. When you are only consuming partial data from that.

[YashKumarVerma]

To merge this PR the one I asked for earlier has to be merged first. This PR doesn't take care about different url formatting.

Thanks for the review.
The reason that it does not accommodate the irregularities (ending hash, spaces, slashes) is that once the pr which fixes the URLs is done, no new occurrences of any such irregularity would arise, and the older ones would be fixed too.

Secondly you are pulling all the data upfront when only some part of it is required.
Can you please elaborate this one? is it about getting all details of the claims on the view ?

On a re look it seems fine to have the current clause.

About loading data. In getConflictsReport I can see you are loading data for issues, pull and both. When you are only consuming partial data from that.

Consuming partial data as in ? The view renders the array that the queries return. If they return an empty array, the views don't display anything.

Are you referring to making 3 queries (a separate query to get both) ?
I'm sorry I'm unable to grasp 😢

[prathambatra]

Fixes #260
Follow up of #279 as tree became too messed up.

• Shows tab wise

  • List of claims which submitted the same issue
  • List of claims which submitted the same PR
  • List of claims which submitted both items same.
  • Three separate tabs with numbering to inform about linked claims
  • Tabs don't show when no linked/conflicting claims present.

Case 2 and 3 are not required at all. mainly conflicted claims are those where there is same issue and multiple PRs (both pull or new issue case) are there. I haven't seen any rejected claim where a person has used someone else's pull request URL and that too on some not-related issue. That's too impractical to happen in real scenario.

[YashKumarVerma]

I think Case 2/3 will be triggered when someone submits the two URLs interchanged, i.e. pull request in issues column, and issueUrl in the pull request column. That would trigger case 1 as well, no doubts to that. It's just a method to specifically point it out.

With the inputs and history URLs clean, I think we can remove it.

[prathambatra]

I think Case 2/3 will be triggered when someone submits the two URLs interchanged, i.e. pull request in issues column, and issueUrl in the pull request column. That would trigger case 1 as well, no doubts to that. It's just a method to specifically point it out.

With the inputs and history URLs clean, I think we can remove it.

Yes, This check should be at add page. We shouldn't allow incorrect claims in any way.

[YashKumarVerma]

I think Case 2/3 will be triggered when someone submits the two URLs interchanged, i.e. pull request in issues column, and issueUrl in the pull request column. That would trigger case 1 as well, no doubts to that. It's just a method to specifically point it out.
With the inputs and history URLs clean, I think we can remove it.

Yes, This check should be at add page. We shouldn't allow incorrect claims in any way.

thanks for pointing out 😄

[thenamankumar]

To merge this PR the one I asked for earlier has to be merged first. This PR doesn't take care about different url formatting.

Thanks for the review.
The reason that it does not accommodate the irregularities (ending hash, spaces, slashes) is that once the pr which fixes the URLs is done, no new occurrences of any such irregularity would arise, and the older ones would be fixed too.

Secondly you are pulling all the data upfront when only some part of it is required.
Can you please elaborate this one? is it about getting all details of the claims on the view ?

On a re look it seems fine to have the current clause.
About loading data. In getConflictsReport I can see you are loading data for issues, pull and both. When you are only consuming partial data from that.

Consuming partial data as in ? The view renders the array that the queries return. If they return an empty array, the views don't display anything.

Are you referring to making 3 queries (a separate query to get both) ?
I'm sorry I'm unable to grasp 😢

You are making 3 queries and after fetching checking which one to use.