New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add launch-only property for project users #413

Closed
wants to merge 1 commit into
base: develop
from

Conversation

Projects
None yet
3 participants
@strangeman
Collaborator

strangeman commented Aug 2, 2017

Fix for #344

The solution may be not ideal - I just added separate launch_only property, so the user may have project admin rights and not be able to edit task templates. :)
On the other hand, this is may be useful to prevent accidental editing/deletion of templates (project admin can add/remove launch_only property for himself).

Also (please, move it to separate issue, if needed) we need to rewrite system user or project user code. Currently, they contain a similar logic (admin and ordinary user UI, various rights checks), but a very different implementation.

@twhiston

This comment has been minimized.

Show comment
Hide comment
@twhiston

twhiston Feb 16, 2018

Member

surely an admin should always be able to do everything? (this is the definition of an admin I would say). Perhaps this could be the basis of a general discussion about more granular user permissions

Member

twhiston commented Feb 16, 2018

surely an admin should always be able to do everything? (this is the definition of an admin I would say). Perhaps this could be the basis of a general discussion about more granular user permissions

@n3rV3

This comment has been minimized.

Show comment
Hide comment
@n3rV3

n3rV3 Mar 8, 2018

I am thinking of using Semaphore in a project. But, the restriction is that I will be deploying Semaphore in a different team's infra(with help from their admin/devops). They won't be happy if I have the ability to run/edit/update everything. But with this feature, I can have limited access and push only the changes I am authorized to do.

Their admins will be happy with the control, and I will have only as much access as i need(run tasks/playbooks).

n3rV3 commented Mar 8, 2018

I am thinking of using Semaphore in a project. But, the restriction is that I will be deploying Semaphore in a different team's infra(with help from their admin/devops). They won't be happy if I have the ability to run/edit/update everything. But with this feature, I can have limited access and push only the changes I am authorized to do.

Their admins will be happy with the control, and I will have only as much access as i need(run tasks/playbooks).

@twhiston

This comment has been minimized.

Show comment
Hide comment
@twhiston

twhiston Mar 8, 2018

Member

I totally hear your use case here, and i agree that it would be good to have, the question is if we put just this in now (as it touches a lot of files) or we try to look at a more fully featured and granular permissions system that will allow us to go deeper with permissions in future.
@strangeman what are your thoughts?

Member

twhiston commented Mar 8, 2018

I totally hear your use case here, and i agree that it would be good to have, the question is if we put just this in now (as it touches a lot of files) or we try to look at a more fully featured and granular permissions system that will allow us to go deeper with permissions in future.
@strangeman what are your thoughts?

@strangeman

This comment has been minimized.

Show comment
Hide comment
@strangeman

strangeman Mar 10, 2018

Collaborator

We need to invest in the more clear solution. This was a kind of dirty hack because I had no time for the proper solution. But currently, the project had active maintainers and we can do it much better. I think this is the good milestone for 2.6 or 2.7.

Collaborator

strangeman commented Mar 10, 2018

We need to invest in the more clear solution. This was a kind of dirty hack because I had no time for the proper solution. But currently, the project had active maintainers and we can do it much better. I think this is the good milestone for 2.6 or 2.7.

@twhiston

This comment has been minimized.

Show comment
Hide comment
@twhiston

twhiston Mar 10, 2018

Member

I'm going to close this PR then and we can use #344 as the issue to deal with this in a more fully featured way

Member

twhiston commented Mar 10, 2018

I'm going to close this PR then and we can use #344 as the issue to deal with this in a more fully featured way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment