-
Notifications
You must be signed in to change notification settings - Fork 472
Conversation
To do:
|
Fixed by raising the default puma workers. This is really ugly, but it looks unavoidable on a raw puma setup. In order to improve this for |
It totally makes sense. This could also be applied when deleting a repository too. 👍 |
@@ -52,6 +52,16 @@ def create? | |||
(APP_CONFIG.enabled?("user_permission.create_namespace") || user.admin?) && push? | |||
end | |||
|
|||
def destroy? |
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 allowing any namespace to be destroyed if user is admin and delete is enabled. That is not true as described in destroy service object code.
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.
We can further discuss this on Monday. I believe that those checks have to be performed on the service, rather than on the policy. This is because an error on a personal namespace is, an error semantically speaking, not something disallowed for some users (i.e. related to authentication or authorization).
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.
We need to fix this in the authorization level somehow to avoid showing the delete button when deletion would be denied. That's why I suggested it here.
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'm not sure I'm following 😕 In order to show/hide the delete button, you need some code in the authorization level? Isn't it possible to get this right from a helper somehow?
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 do use a helper for that but I usually reuse the logic from the policies. That's what I've been doing for other cases. We've been strict in other policies rules but not in this one. What's the line between having stuff being done inside policies or not?
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.
Fair point. The distinction is on the semantics imho. It's not about "you are not authorized to perform this", rather "what you are trying to do is not possible because of reason X". In this case, it's not possible because we don't want to implement personal namespace removal until we don't implement user removal.
b6b1294
to
c9f679c
Compare
Squashed. I've added a Signed-Off in the first commit 😉 |
83133d6
to
bb864eb
Compare
|
||
// TODO: refactor bootstrap popover to a component | ||
$(this.$el).on('inserted.bs.popover', DELETE_BTN, () => { | ||
console.log('delete carai'); |
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.
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.
Haha.
bb864eb
to
9eb99ed
Compare
lib/api/helpers/namespaces.rb
Outdated
@@ -8,6 +8,10 @@ def can_manage_namespace?(namespace, user) | |||
NamespacePolicy.new(user, namespace).update? | |||
end | |||
|
|||
def can_destroy_namespace?(namespace, user) | |||
NamespacePolicy.new(user, namespace).destroy? |
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.
@vitoravelino all that would take is to update this method so it also checked personal namespaces, no?
9eb99ed
to
e6e2115
Compare
@vitoravelino I just implemented what I mentioned here. Could you review again? |
@@ -8,6 +8,10 @@ def can_manage_namespace?(namespace, user) | |||
NamespacePolicy.new(user, namespace).update? | |||
end | |||
|
|||
def can_destroy_namespace?(namespace, user) | |||
NamespacePolicy.new(user, namespace).destroy? && !User.exists?(namespace: namespace) |
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.
It worked partially. Just need to check for global namespaces to deny that too.
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.
That is true. We are not checking this in neither the policy nor the service. Where should we put this check 🤔 ? I'd say that you could argue for both in this case:
- If you put it on the policy, it means that no one is authorized to delete a global namespace. It means that this will never happen (e.g. it's not like the personal namespace case because in that case we may eventually allow that).
- If you put it on the service, it means that what you are trying to do is semantically wrong, regardless of your credentials.
On this I would favor option 1, but I'm not sure. @vitoravelino what do you think?
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.
@mssola option 1 sounds better.
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.
Besides my last comment, everything working as expected. This is super nice! Kudos! 🎉
This commit fixes one of the oldest requests we've had: being able to delete a namespace. It also introduces an API endpoint for it. There are two exceptions when it comes to deleting a namespace: 1. Personal namespaces cannot be removed. In the future we might implement user removal, and then it will make sense to re-iterate on this. 2. Global namespaces cannot be removed, because they are meant to be guaranteed by everyone using the registry. Fixes SUSE#767 Signed-off-by: Miquel Sabaté Solà <[email protected]> Signed-off-by: Vítor Avelino <[email protected]>
This is needed to keep up with the requirements of deleting namespaces. Signed-off-by: Miquel Sabaté Solà <[email protected]>
e6e2115
to
990a04e
Compare
@vitoravelino done! Let's wait for Travis now 😄 |
And with that, there are no more features left for 2.4. Let's start hunting bugs until the final release! 😋 |
This commit fixes one of the oldest requests we've had: being able to
delete a namespace. It also introduces an API endpoint for it.
Fixes #767
Signed-off-by: Miquel Sabaté Solà [email protected]