Closed rkzel closed 4 years ago
In case of read-only panels when they are opened from activity log in issue details
I discussed this with @javieralaves, and this is a bug. It makes no sense that you see a read-only panel based on where you open it from!
If you are allowed to review the thing you're looking at, you should be shown the editable version. If you're not allowed, you should see the read-only version.
Do you think it's a small enough change to fix this while we're here, or would you prefer to put it in a separate PR?
second applicant's address replaces the first applicants as assignee, but the applications itself remains accepted (because acceptance info is stored on IPFS). I'm not sure if it is a bug really, feature or side effect
Does this essentially have the effect of rejecting the previously-accepted application? This would mean that the initially-accepted applicant can no longer submit their work – right?
If that's the case, it seems like a bug to me. However, maybe waiting to fix it until we work on multibounties is the best path forward.
Thoughts on the commit message. Here's what it is currently:
feat: review panels, simple filtering added
Since it's marked feat
, it will show up in our changelog. And it's a feature! So people might actually care to read about it, as opposed to bugfixes, which are probably less interesting for users to learn about.
But I don't think I would understand what this feature is, just reading this description. Now that our commits are meant to be user-facing, let's actually think about how users will understand them!
How about something like this:
feat(projects): added filtering to review panels
When reviewing applications or work submissions, you will now be able to filter to see only those applications that need review, or only those that have already been reviewed.
Do you think we could clean this up if we modeled the relationship between the first dropdown and the second with an object?
{ 'Reviewed': [{ addr: '0x123', username: 'rkzel' }, { addr: '0xabc', username: 'chadoh' }],
'Need review': [{ addr: '0xdef', username: 'quazia' }],
}
Do you think we could clean this up if we modeled the relationship between the first dropdown and the second with an object?
Generally yes, but I ended up with 2D array - found that easier to use in DropDowns later. And yes, it simplified a lot :)
The idea is: Review Panels (work application, work submission) could have simple filters of reviewed/available for review type like this:
and this:
In case of read-only panels (panels present read-only information (no forms, no review buttons)) when they are opened from activity log in issue details. RO panels looks like this:
There are 3 possible states for a submission to be in, which is reflected in what appears in the first DropDown:
There is also a difference between work applications and work submissions: there is no limit to applications. Until work has been submitted unlimited number of applications can be created - and they can all be accepted. Accepting second application has the following effect: second applicant's address replaces the first applicants as
assignee
, but the applications itself remains accepted (because acceptance info is stored on IPFS). I'm not sure if it is a bug really, feature or side effect - it can be used by someone with enough privilege to accept applications only, and possibility of accepting multiple applications will be useful in the near future anyway, for multibounties. Work submissions are limited (to one) in non-open-submission mode, and for open-submission mode there is limit of accepted submissions - currently one (but there was some initial work done in preparation for handling multiple submissions for multibounties).