Display all user activity on contribution calendar regardless of permission scope.
Display all user contribution counts from both private and public as activity.
- Be aware that I'm not a Ruby dev (Golang/PHP), I have followed existing code examples but please help me ensure standards are met.
- Confirm performance impact on returning all records a user has contributed to. Memory consumption should increase, but execution should be less due to straight select without filtering.
Why was this MR needed?
VCS profiles are used more and more as reference points and resumes for both contributors and recruiters. The current behaviour of Gitlab is to suppress contributions made to private projects from the public domain via the contributions calendar, eg https://gitlab.com/kylehqcom. But that doesn't give a true sense of a users activity. In this context, "activity" should be based on any contributions to a project, private or public.
Of course this does not mean that details of private projects should be returned to the public. The code included in this MR simply returns contribution counts as user activity for both private and public projects. Only public project commit details are displayed as normal, but all count values are returned. This behaviour is respected on specific date selecting also.
Existing non authenticated view
New non authenticated view
Note the No public contributions found addition.
New authenticated view
Note the so-private commit entry which is returned in the auth'd view and is the source to the contribution count of the non auth'd view.
Does this MR meet the acceptance criteria?
-
Changelog entry added -
Documentation created/updated -
API support added - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master
(if it does - rebase it please) -
Squashed related commits together
What are the relevant issue numbers?
Please refer to https://gitlab.com/gitlab-org/gitlab-ce/issues/14078 for comments and +1's to this feature request.
Thanks, Kyle