@JobV GitLab is like Hotel California ;)
Greetings everyone
An image tells a thousand words.
Visit GitLab.com issue or page without being logged in
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5397
The alignment is poor.
My OCD radar isn't firing.
In Summary
This bug happens on GitLab.com
Add m-auto
to the class of the li
<li class="nav-item m-auto">
Out of interest, what emails reference @troupe.co @MadLittleMods ?
Hi everyone :) ltns! Found a weird issue today.
Running Google Chrome on macOS with latest Adblock installed.
Visiting https://gitlab.com/gitlab-org/gitter/gitter-markdown-processor/blob/master/lib/processor.js
Results in Error loading viewer
(relevant GitLab code: app/assets/javascripts/blob/viewer/index.js#L158)
In the devtools console,
processor.js?format=json&viewer=simple:1 Failed to load resource: net::ERR_BLOCKED_BY_CLIENT`
Weirdly, it only happens on that particular file/page.
For example this page works just fine and AdBlock doesn't kick in.: https://gitlab.com/gitlab-org/gitter/gitter-markdown-processor/blob/master/lib/decoration-url-matcher.js
So, yeah, have fun figuring that one out @timzallmann @andr3 :)
@DouweM everything here is complete, right? Please re-open if not.
For GitLab 10.0, we should deprecate but not remove the support of private tokens in GitLab. While private tokens are not an immediate security vulnerability, personal access tokens are preferred from a security point of view.
Things we need to do:
/cc: @JobV, @DouweM, @mydigitalself, @timzallmann, @jschatz1, @briann
I think I had previously discussed this with the breadcrumb visibility with @DouweM and we felt it would be ok to show the parent group in a read-only mode that doesn't expose anything critical. I think there may already be precedent for this elsewhere?
Although the suggestion of collapsing to not show parents would also be a perfectly viable solution I think - you could do this both on the tree view of groups+projects as well as in the breadcrumb?
Agreed that the consistency would have been better. My reluctance to change this is, as you rightfully pointed out, is that changing the capabilities of an established security and permission model is probably a very bad idea.
We've dealt with something similar by allowing the option for developers to create projects in a group in https://gitlab.com/gitlab-org/gitlab-ee/issues/2534 as part of Flexible Permissions which is GitLab Premium emerging feature category. Perhaps if this particular feature request was to get more traction, it might be something to consider as part of this. Note this would mean the feature would not be free.
This was discussed last week with @sytses and @JobV during our monthly GitLab.com update.
There's little value in displaying the message banner during upgrades where we don't anticipate any downtime and it looks unprofessional for SaaS companies to do so. Some reference/feedback: https://news.ycombinator.com/item?id=16212336
@tiagonbotelho i've commented on the MR
Is there a script that gets run on install that doesn't get run on upgrade? If there was, couldn't that script change the configuration from "nil" -> "false".
Couldn't we also ship the default as "false" not "nil", this way new install will get a "false" value and the logic above wouldn't kick in at all?
Sorry, I don't entirely understand the ins and outs of how our settings, install & upgrade procedures work.
@tiagonbotelho what changes in 11.0 to make this doable?
In the current implementation, I assume then if we set it to false for new installs it would overwrite upgrades and set them all to false?
@DouweM ok, understood. @hazelyang maybe let's use the separate page for editing, sorry for the extra work.
cc @jramsay who will be taking this over as I am leaving at the end of the week