Namespace license checks for squash and merge

Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/2335

Squash and merge (EES / Bronze)

1. Do not show checkbox on new merge request page Squash commits when merge request is accepted

2. Do not show checkbox on Accept Merge Request widget Squash commits

3. This is also hard to promote, we could show the checkbox disabled with a link to ugprade.

Implemented in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1024 by @smcgivern

mentioned in issue #2570 (closed)

Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/2570 and https://gitlab.com/gitlab-org/gitlab-ee/issues/2572

mentioned in issue #2572 (closed)

@smcgivern How much effort do you estimate it will take to find all places that touch squashing and add project.feature_available?(:squash_and_merge) checks to them (both on frontend and backend), so that this feature can be turned off for a specific project in its entirety by having that method return false?

mentioned in issue #2335 (closed)

@DouweM what happens to the API in that case, if you've already set an MR as squashable?

I think this would take half a day, but I don't know much about the front-end for the MR widget. In most places, I'd suggest defining a squashable? method / variable, which lets us wrap that check, and which we could also backport to CE where appropriate.

@DouweM what happens to the API in that case, if you've already set an MR as squashable?

@smcgivern Can we ignore that option if this feature isn't available? Basically have it function just like CE running with an EE DB.

@DouweM yes, fine, but I mean: you can still read and write the attribute through the API, right? It just won't do anything, or show in the UI.

@smcgivern Right, sorry, I missed the relevance of "API". I think the idea is that if you don't have access to the feature, the API behaves exactly like CE, where that attribute doesn't exist. Applications that interface with GitLab should already expect slight differences between CE and EE.

@DouweM I guess we could make a case for either option

As long as we all do it the same way, I think that's the important thing!

@smcgivern Since this is going to be used in "Making EE the default" so that even users who only need/want CE can install EE and just use it without a license, the goal is to get EE-without-license to behave exactly like CE would by itself. So I suggest not surfacing those attributes if the feature is not enabled.

assigned to @nick.thomas

mentioned in merge request !2249 (merged)

closed via merge request !2249 (merged)

mentioned in commit 842aebb9