Skip to content
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

Open
Yingwu21 opened this issue Dec 18, 2017 · 7 comments
Open

Additional functionalities #116

Yingwu21 opened this issue Dec 18, 2017 · 7 comments

Comments

@Yingwu21
Copy link

Yingwu21 commented Dec 18, 2017

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

@mredigonda
Copy link
Collaborator

mredigonda commented Dec 26, 2017

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:

  1. The ability for staff members to create tickets
  2. The existence of a staff member with read-only abilities

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!

@Yingwu21
Copy link
Author

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.

@mredigonda
Copy link
Collaborator

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.
There are some tricky cases here, like, how to implement this without needing for admins approval? and how will the admins know that the user just registered should only be able to see departments X and Y, but not Z?

@Yingwu21
Copy link
Author

Yingwu21 commented Jan 7, 2018

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.

@mredigonda
Copy link
Collaborator

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.

@nickbe
Copy link

nickbe commented Feb 20, 2018

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:

  1. I suggest to link the article topics to the departments the same way a user has the right to access a department or not. This would automatically give me access to the knowledge I need.

  2. When users are self-registered I suggest they only have access to the "Help" department, unless a staff member says otherwise. But if I grant department access to a user then he should receive some mail for let him know this.

  3. Letting someone "see" all tickets seem easy enough since this would only require adding one additional role to the list. I don't see the point in having such a user for my own purpose but I imagine other companies would like to have some kind of supervisor role here. Then it might also be advisable to prevent him from being able to edit a ticket, but maybe at least let him add some comments.

  4. As for the custom ticket forms. I think it's a pretty good idea. I would simply let staff members add custom text fields and captions for each department. No distinct field types. Just keep it simple.

@dasimmonds
Copy link

I would really like to see this kind of feature especially for user level.

We may have 5 users belonging to 1 Entity.
Either 1 of them submits a ticket, all 5 of them can view these and reply since they belong to the same entity.
It is similar to ticket collaboration in ostickets but a useful feature.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants