-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Added progressbar for issues (#1146). #3171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: modmew8 <[email protected]>
Why stored the percent? I think it's unnecessary. |
I could not locate any arithmetic operations in the templates, so I assumed it is task of the models to handle these operations. As alternative to arithmetic in the templates using go, we could also use css calc(): The calculation would be on the clientside this way. |
Updating master
Updating progressbarForIssues with latest master
…dded the issue task progress to the user/dashboard/issues. Signed-off-by: modmew8 <[email protected]>
Signed-off-by: modmew8 <[email protected]>
Removed the percent variable and changed the progress bar to use calc(). |
Signed-off-by: modmew8 <[email protected]>
models/issue.go
Outdated
Labels []*Label `xorm:"-"` | ||
MilestoneID int64 `xorm:"INDEX"` | ||
Milestone *Milestone `xorm:"-"` | ||
Tasks int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're adding new columns to the issue
table, then we need a migration.
However, I think the case could be made that we shouldn't store tasks/tasksDone in the database, but instead just calculate them from the Content
field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about leaving the parsing to the clients? Then we would not have to store anything on the server, and the only files being changed would be the template files (and the css rules). Since it is just a cosmetic addition, the clients could determine the progress themselves upon viewing the issue list - but the server has to provide the content for the clients to parse (additional network load).
I would realize this as a javascript function in the issue list and in the user dashboard issue list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ethantkoenig I don't think so. If the page has 10 issues. We have to parse all the 10 issues' markdowns on the browser one time. And also we need add a javascript markdown library. I don't think this is a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lunny We don't need to render the issue content as markdown, we just need to look at the raw string (which we load from the DB anyway). The regexps in this PR would not work if the issue contents were rendered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ethantkoenig and another thing, we didn't transfer issue content to client on issue list. If you want client to parse that. We have to transfer the contents. This will also reduce the load speed of the page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not suggesting we send the issues' content to the client. That was @modmew8's comment.
I am proposing that we calculate the number of tasks server-side; this can be computed easily with regexps, and does not require rendering the contents as markdown. If our regexps are pre-compiled, I don't think this will be very expensive, since (as I mentioned above) we already load the contents from the DB.
I am hesitant to add new columns to the issue
table because I'm afraid that if we will add new columns for every new feature, our schemas will eventually become very complicated and confusing.
models/issue.go
Outdated
MilestoneID int64 `xorm:"INDEX"` | ||
Milestone *Milestone `xorm:"-"` | ||
Tasks int | ||
Tasksdone int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TasksDone
models/issue.go
Outdated
@@ -740,7 +743,16 @@ func AddDeletePRBranchComment(doer *User, repo *Repository, issueID int64, branc | |||
func (issue *Issue) ChangeContent(doer *User, content string) (err error) { | |||
oldContent := issue.Content | |||
issue.Content = content | |||
if err = UpdateIssueCols(issue, "content"); err != nil { | |||
|
|||
regExpTasks := regexp.MustCompile(`(^\s*-\s\[[\sx]\]\s)|(\n\s*-\s\[[\sx]\]\s)`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is duplicated code, please consider refactoring.
Also, it would be nice if we didn't have to compile the regexp every time.
…tea-master Merged less changes and updated index.css using make generate-stylesheets.
Merge current Master into fork
Merge pull request #4 from go-gitea/master
Codecov Report
@@ Coverage Diff @@
## master #3171 +/- ##
==========================================
- Coverage 34.82% 34.82% -0.01%
==========================================
Files 277 277
Lines 40263 40271 +8
==========================================
+ Hits 14023 14025 +2
- Misses 24181 24186 +5
- Partials 2059 2060 +1
Continue to review full report at Codecov.
|
…d regexp. Signed-off-by: modmew8 <[email protected]>
I implemented the changes @ethantkoenig suggested, now without new variables in issue, with precompiled regexp and computation on demand when accessing either the issue list or the dashboard issue list. |
I restarted the build in Drone. |
LGTM |
@ethantkoenig needs your approval. |
@lunny LGTM |
Hi there,
my pull request adds the progressbar for issues as requested in issue #1146. It basically adds three variables to issue.go that hold the information, how many tasks exist, how many are done, and the percentage of the progress.
The values are updated upon creating a new issue and modifying the issues content. The content is parsed using regular expressions, collecting the amount of valid tasks and valid completed tasks.
The style is github-alike.
I hope I made everything correct - this is the first pull request in my life :) (please be merciful).
Best regards
modmew8