Age | Commit message (Collapse) | Author |
|
|
|
|
|
POC: Updated contrib calendar
In an effort to cut down the JS file size - i've removed the heatmap calendar used for the contributing calendar on users profiles. We already have d3 on the page so why not use it instead of using a library which uses it?
![Screen_Shot_2016-04-27_at_11.08.41](/uploads/64c40f0c766f800fd0e33ac8be7f9644/Screen_Shot_2016-04-27_at_11.08.41.png)
cc. @jschatz1
See merge request !3944
|
|
|
|
Added loading icon to selected date box
|
|
This aligns the boxes correctly with the day on the left side of the calendar
|
|
|
|
|
|
issue_15572_snippets_tab_under_user_profile
|
|
|
|
issue_15572_snippets_tab_under_user_profile
|
|
|
|
Remove unused .contributed-projects class
While working on #13401 and trying to add a new tab to the user profile
page, I came across this. I noticed that the `contributed-projects`
class was only being used in order to select the div in the tests. For
consistency with the other tabs, I decided to remove this class and use
the div's id for the selector.
See merge request !3945
|
|
|
|
While working on #13401 and trying to add a new tab to the user profile
page, I came across this. I noticed that the `contributed-projects`
class was only being used in order to select the div in the tests. For
consistency with the other tabs, I decided to remove this class and use
the div's id for the selector.
|
|
I'm not entirely sure if this project uses the `js-` prefix for
classes that are for js purposes only. But as I was working on a
feature, I noticed that these classes were those kind of classes.
|
|
Closes #13943
|
|
Resolves #14668. [ci skip]
|
|
medium screens
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Separates the User page bio from the username and account creation
date.
- Separates the pseudo-selector adding a Middle Dot out from the
`profile-link-holder` class and into a `middle-dot-divider` class.
Resolves #13406.
See merge request !2827.
|
|
By simply loading the first event from the already sorted set we save
ourselves extra (slow) queries just to get the latest update timestamp.
This removes the need for Event.latest_update_time and significantly
reduces the time needed to build an Atom feed.
Fixes gitlab-org/gitlab-ce#12415
|
|
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
|
|
Closes #5908
|
|
A limited number of pages have defined their own descriptions, but
otherwise we default to the Project's description (if `@project` is
set), or the old `brand_title` fallback.
The image will either be the uploaded project icon (never a generated
one), the user's uploaded icon or Gravatar, or, finally, the GitLab
logo.
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
Instead of using MAX(events.updated_at) we can simply sort the events in
descending order by the "id" column and grab the first row. In other
words, instead of this:
SELECT max(events.updated_at) AS max_id
FROM events
LEFT OUTER JOIN projects ON projects.id = events.project_id
LEFT OUTER JOIN namespaces ON namespaces.id = projects.namespace_id
WHERE events.author_id IS NOT NULL
AND events.project_id IN (13083);
we can use this:
SELECT events.updated_at AS max_id
FROM events
LEFT OUTER JOIN projects ON projects.id = events.project_id
LEFT OUTER JOIN namespaces ON namespaces.id = projects.namespace_id
WHERE events.author_id IS NOT NULL
AND events.project_id IN (13083)
ORDER BY events.id DESC
LIMIT 1;
This has the benefit that on PostgreSQL a backwards index scan can be
used, which due to the "LIMIT 1" will at most process only a single row.
This in turn greatly speeds up the process of grabbing the latest update
time. This can be confirmed by looking at the query plans. The first
query produces the following plan:
Aggregate (cost=43779.84..43779.85 rows=1 width=12) (actual time=2142.462..2142.462 rows=1 loops=1)
-> Index Scan using index_events_on_project_id on events (cost=0.43..43704.69 rows=30060 width=12) (actual time=0.033..2138.086 rows=32769 loops=1)
Index Cond: (project_id = 13083)
Filter: (author_id IS NOT NULL)
Planning time: 1.248 ms
Execution time: 2142.548 ms
The second query in turn produces the following plan:
Limit (cost=0.43..41.65 rows=1 width=16) (actual time=1.394..1.394 rows=1 loops=1)
-> Index Scan Backward using events_pkey on events (cost=0.43..1238907.96 rows=30060 width=16) (actual time=1.394..1.394 rows=1 loops=1)
Filter: ((author_id IS NOT NULL) AND (project_id = 13083))
Rows Removed by Filter: 2104
Planning time: 0.166 ms
Execution time: 1.408 ms
According to the above plans the 2nd query is around 1500 times faster.
However, re-running the first query produces timings of around 80 ms,
making the 2nd query "only" around 55 times faster.
|
|
|
|
For example view: shared/issuable/_context
CoffeeScript: 190ms
JavaScript: 19.7ms
|
|
* add separator between tabs
* show project avatars
* fix tooltip offset on user calendar
* remove gray hover for tabs
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|