@mydigitalself, you are right the text given doesn't doesn't provide any more insight but I wouldn't get anchored on the exact example text given. I still think the value is in being fully customizable and not just being able to add or customize a link. We would probably end up with something like, "Your account has been inactive for over a month, please click here to re-enable".
@drumrigj It's more a matter of prioritisation than getting caught up on the text. It's a perfectly reasonable request, but if I consider the amount of extra value added by customising the text and the frequency at which this sort of thing occurs, I'd struggle to prioritise it higher than other improvements to GitLab.
I think this could very well be a CE request (i.e. EE will inherit it) and we could potentially move it there and open it up to gitlab-ee~139607 so that anyone can contribute it and not contend with other internal resourcing.
@mydigitalself I see this sort of customisation as something that would generally be of use to larger organisations. I think it belongs where it is, in EE. But I do see your point about prioritisation as it pertains to EE vs. CE in this case.
I don't know if it does. I'm not really clear on what the problem is since there's no problem statement. I don't understand how the "new" copy is any better - to Mike's point. The user is blocked, that's exactly what the notification is telling them.
The current default message “Your account has been blocked, Please contact your gitlab administrator if you think that this is an error” isn't very directive and within their organization it often leads users to contacting the wrong department or trying to reach out to GitLab Support directly for assistance which just delays the user from having their access restored.
@ogolowinski (looks likes this may fall under the Workspace group) This issue is pretty old but the design was completed a few months ago in #209341 (closed) so I'm hoping this means this feature may get some attention. Any idea if this is on the roadmap?
@hsutor A setting in the admin area to customize this seems reasonable. I don't think there we be much frontend work here. It would mostly be adding a new field to the one of the database tables to store the custom message. I'll label this as backend and frontend. The frontend wouldn't be any more than a weight of 1 and could probably be completed in the same MR as the backend work.
@dmoraBerlin@npost Here's an example of an item that I'm not sure if I should get on the schedule for ~"group::authentication and authorization" or not due to the timing of ~"group::workspace". Is it worth putting this in the admin panel? This goes back to the larger question of if the existing SM admin panel is going to be migrated to Workspace.
@hsutor there's a linked issue in the description that should have covered this feature's implementation? #209341 (closed)@mnearents worked on it. Wouldn't this be an extension of that work?
@mnearents@dmoraBerlin Thanks for pointing that out. So the design work is already done, this just needs to be implemented. And it is duplicated in 3 different issues, one in ~"group::authentication and authorization" , one in grouputilization and one in ~"group::workspace"
Why interested: We would like to change that message to direct users to use a form we have created in another tool to get their account unblocked, rather than them reaching out to us, and we tell them to go use that form.
Problem they are trying to solve: Stream line the blocked user workflow
Current solution for this problem: Blocked users have to reach out to the infrastructure team
Impact to the customer of not having this: Time delays for unblocking a user and additional work from infrastructure team
In your organization, what do you consider to be the highest priority for this feature proposal? According to a scale of 1-10, 1 is the lowest priority and 10 is the highest.
We are interested in this feature as we have several channels where our users can reach out to us regarding this situation. We would like to be able to share the channel where they can reach us in that message so we can avoid confusion.
What is the problem you are trying to solve?
Our users are confused as the blocked user message is not providing more information where the administrators can be reached.
Do you have any workarounds?
There doesn't seem to be any possible workaround to edit the blocked user message.
What is the impact on your organization of not having this feature?
The general user experience is affected as the message can't be edited to include where our users can reach out to the GitLab instance administrators.
Are there any questions/notes you have for the product manager?