-
Notifications
You must be signed in to change notification settings - Fork 339
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
Additional functionalities #116
Comments
Thank you for your feedback! We really appreciate it. About the first two points, I don't think they will be implemented soon but they will definitively be taken into account for next features. However, as a simple workaround for now, you can have multiple instances of OpenSupports in one page. I see that you want to make groups for users and groups for admins, so having two separate instances would be a considerable approach. Of course, this does not solve the problem 'the nice way' but at least is something. About the third point, there are two things:
I like those features, we will do a careful research and we will let you know the status of this. About the fourth point, I strongly agree, that column is missing. About the fifth point, I also agree, there should be something like the "add staff member", but an "add user member". Custom ticket forms is a feature that we are planning to do almost since we started this, there are however, some other issues and bug fixes that we should take care of first, so it will take some time, but it will be implemented. This is indeed the correct way of giving us your feedback (email, or other methods are also fine), so don't worry about that, and thank you again for the good ideas! |
Thank you for the clear response to my questions/feedback. The plans for the future sound great and I can't wait to see them implemented. If you ever need help testing anything you can always ask to try something out. I am definitely going to roll out the Ticket System in January with my biggest customer so for now all the teams / visibility "issues" won't be a problem. If the future offers better solutions I will roll out the system to others as well in a more streamlined fashion. I'm thinking of disregarding Departments completely for now so that everyone just sees one Department. |
If this is implemented, I think that #74 will work in tandem with this. The idea would be that instead of allowing users to register directly, an admin will have to approve them and in the same step the admin should decide which departments will this new user be able to see. |
Just to clarify, I suggested these functionalities I'd like to see when the option to turn off user registration entirely already existed. In my case I'm going to turn off user registration and add all people manually that need to be able to submit a ticket. That aside, it would of course be a lot cooler to have a third option for accepting open registrations. But in my case I would be in full control of who gets registered and what they are allowed to see and do. Which is only 1 of few approaches of course but I'd like to see these functionalities implemented and maybe that will spark even more ideas and possibilities. |
Excellent. I agree that these functionalities only make sense when having user registration off. I can't think of any use case in which you don't know the user who register and you would like to select a set of departments for each user. |
Despite the fact that I indeed stumbled over exactly the same nags here, I think the most important thing is to keep the system as simple as possible. So I'like to add some comments here:
|
I would really like to see this kind of feature especially for user level. We may have 5 users belonging to 1 Entity. For articles, from what i see currently, with registration enabled, they cant view the articles until logged on, which is good. But also being able to make the article viewable for users or internal only would be an advantage. |
I have recently installed OpenSupports and first of all I'd like to say that this is an amazing start!
But I did find various things that would make it a lot more "professional" in it's appearance towards end users.
When creating Departments this becomes visible for EVERY end user which is very not done to show users information about other users. I'd like an option to go to a specific User and restrict them to only see Department X or Y but NOT Z. A group would also do here, assign 1 or more Users to a group and give that group access to only see X and Y but not Z.
Same goes for Articles, I love the idea of a database of articles and the likes BUT yet again it's very not done to have these be completely public to anyone using the system. It would be nice to at least have the option to limit a User by Article Topics if not specific Articles.
It's kind of weird that a Staff member can't make tickets themselves. This is especially annoying since big companies (I'm dealing with one that has 150+) have managers and they would like to see all tickets of their company in one place. This could be done by giving them a level 1 Staff account but 1. They can't make tickets themselves then and 2. Yes, you can limit a staff member to what Departments they can edit but not to what Departments they can see. Which is the same point as 1. and 2.
In the All Tickets overview for staff the column for "Status" is strangely missing. I can see which Tickets are new, but not which tickets are open/closed. This would be nice as either a separate menu option or just a column in the All Tickets menu.
I've seen the request before but I'd like to stress the importance of the ability to add Users as a Staff member without the need for a CSV file. I love the option to not user user registration since I like it being a closed system BUT it's annoying to have to turn it back on, make a user for someone else and then turn it back off again.
And lastly likely a much harder one to implement but the option for custom Ticket forms for specific Users or User Groups. From different customers I need to know different things so it would be amazing if you could build custom Ticket forms with different mandatory/non mandatory fields to guide your customers into giving you the information you need besides just a title and a text field.
I'm very sorry if this is not the correct way you had in mind but I absolutely do not understand GitHub's interface D= Also feel free to ask for additional information or explanations.
The text was updated successfully, but these errors were encountered: