We would like to collect some feedback from you to improve ABP support. In this context;
- What are your problems with ABP Support?
- Please suggest your ideas on how we can improve them.
36 Answer(s)
-
0
When we open an issue, or another customer opens an issue, it would be nice to be able to follow the history on github, like it happens on aspnetzero.
-
0
When we work on a customer solution it becomes difficult to be able to share the code in order to allow support to replicate the error.
-
1
Enable the display of the change log also for the commercial and abp suite version, pre release included. Like: https://github.com/abpframework/abp/releases/tag/7.1.0-rc.1
-
0
The search here in the Support Center could be improved. For example, when searching for an error message, it now searches for every single word by default. Or if I search for something that should contain several words, I have to do it with +. This is sometimes uncomfortable or forgotten.
-
0
The search here in the Support Center could be improved. For example, when searching for an error message, it now searches for every single word by default. Or if I search for something that should contain several words, I have to do it with +. This is sometimes uncomfortable or forgotten.
did you try the advanced search?
-
1
In ABP IO the uptime of the nuget server is critical. We regularly seem to have issues with downtime or blips with certain packages, this is a larger discussion that needs to be had. In the short term, it would be very useful to have a is it up page, with a history of down times, scheduled maintenance etc.
Similar to https://status.slack.com/ or many others
-
0
In the same vein as the above, it would be really helpful for us if there was a running update, eta, or at least something more than "we will check it" in over 5 hours of major issue.
I know the support team doesn't have an SLA, and it's a really good job you don't right now - but I, like may others waiting here, have clients expecting delivery and it's really difficult to go cap in hand saying "There is an issue, I don't know when it will be fixed. I know release was scheduled for today, but there is nothing I can do, nor do I have any more information".
A status page would be a good start, but updates on issues, especially one as large as the nuget server going down, is critical.
-
0
In ABP IO the uptime of the nuget server is critical. We regularly seem to have issues with downtime or blips with certain packages, this is a larger discussion that needs to be had. In the short term, it would be very useful to have a is it up page, with a history of down times, scheduled maintenance etc.
Similar to https://status.slack.com/ or many others
THIS! We are also impeded by nuget server failures on ABP. I feel strongly that the ABP team need to treat this kind of failure as highest priority. Currently we get almost no feedback or acknowledgement of this type of issue when it's reported on the support forum.
-
0
Example: https://status.nuget.org/
-
0
It would be advisable that at least one day before each release of ABP (both preview, rc and other) and each maintenance, Volosoft sent an email alert with the time of the intervention (start - end) to us customers, so that even we can warn our customers.
Thanks
-
0
Mosf of the time - when we have a technical question - we are asked to either send the project source code or create the test version where the problem is reproduced.
The first one is not possible because of commercial nature of the project. The second one is very time consuming and is not possible too.
Yes, our solution is quite complex and we have some custom code on the top of ABP framework. But it would be great, if your support team devoted more time trying to understand the nature of the problem and analyze the fragments of the code shown in the message. Because often the answers are very short and meaningless - so we end up debugging out solution and looking at the downloaded ABP module source codes to resolve the problem ourselves.
-
0
We have found MANY times that the documentation DOES contain the answers to problems we face, but the information is not presented in a way that is obvious to people who are new to ABP. One suggestion for improving the help would be to select a mid-level developer who has NO experience with ABP, and observe them (without helping) as they try to create a new project (do this do a different person for each 'type' of project). Document the things that cause problems and highlight those things better in the documentation. A related improvement would be to explain WHY certain things are done the way they are - once you understand the framework this becomes obvious, but when starting out many things can seem overly complicated when you do not understand why.
-
0
We have found MANY times that the documentation DOES contain the answers to problems we face, but the information is not presented in a way that is obvious to people who are new to ABP.
One suggestion for improving the help would be to select a mid-level developer who has NO experience with ABP, and observe them (without helping) as they try to create a new project (do this do a different person for each 'type' of project). Document the things that cause problems and highlight those things better in the documentation. A related improvement would be to explain WHY certain things are done the way they are - once you understand the framework this becomes obvious, but when starting out many things can seem overly complicated when you do not understand why.can you give concrete examples on this?
-
0
We have found MANY times that the documentation DOES contain the answers to problems we face, but the information is not presented in a way that is obvious to people who are new to ABP.
One suggestion for improving the help would be to select a mid-level developer who has NO experience with ABP, and observe them (without helping) as they try to create a new project (do this do a different person for each 'type' of project). Document the things that cause problems and highlight those things better in the documentation.
A related improvement would be to explain WHY certain things are done the way they are - once you understand the framework this becomes obvious, but when starting out many things can seem overly complicated when you do not understand why.can you give concrete examples on this?
I have found this to be 100% true. While some of the documentation is very good it is often very time consuming to 'connect the dots' on the 'practical approach' with doing things that should work right out of the box. There is a HUGE learning curve with ABP and I have often find myself refactoring code from back when I started using ABP because I've since learned the 'ABP Way' of doing things.
Additionally, while there are often good blog posts on how to integrate 3rd party controls/libraries with ABP the are just the basic level of integration posts and don't show how to use ABP with some of the classes from these controls. An example was when I was trying to implement custom storage with DevExpress Dashboards and spent the better part of a week going back and forth with support (with provided example of the issue) and was initially told 'I can't use DevExpress Dashboard' with ABP web solution......never an acceptable answer in my opinion. Thankfully we were able to figure out what the cause of the issue was, which was to use the runasync helper class to call a service from on the the inherited DevExpress classes, but the process was painful to get to that point.
-
0
can you give concrete examples on this?
I didn't record the many problems we faced when trying to get started. Once you know and understand the 'why' many of these things are obvious, but we had many times where we questioned using ABP in the beginning. The best way to identify these things would be to watch someone starting out using ABP for the first time (don't help them, just document where they have challenges). You will find a number of barriers to startup which can be solved with a little bit more detail in the documentation.
Using a tiered architecture, separate identity server, and Docker all added to the places where we had problems. Again, the problems were our own, but they were with things we expected to be solved by ABP (and they were, but you have to get the configuration correct, and we were using ABP because we may not have deep experience in all of the areas...).
-
0
I see that most of the comments are abstract. To fine-tune our documentation and get started steps, we need concrete examples. Because for me it's very straightforward to kick-start a project. Imagine that you start a new scratch ASP.NET Core project with Docker, DevExpress, and Identity Server with a tiered architecture, would it be slaphappy?
-
0
can you give concrete examples on this?
Example of what would have been useful to me: Step by step instructions for a deployment to Azure. Including the correct setup of OpenIddict etc. Just in a way that you can run the WebApp (in my case with Blazor) securely afterwards. Also what is necessary to store the appsettings / connection strings securely (e.g. with environment variables).
My application is still in the test environment, but I have not yet managed to configure OpenIddict so that it works correctly. For example, I had to set "WEBSITE_LOAD_USER_PROFILE" to true to work around the problem, etc.
Since I don't have that much experience with OpenIddict and Azure yet, I have to gather all the necessary info in the forum.
-
0
can you give concrete examples on this?
Example of what would have been useful to me:
Step by step instructions for a deployment to Azure. Including the correct setup of OpenIddict etc. Just in a way that you can run the WebApp (in my case with Blazor) securely afterwards. Also what is necessary to store the appsettings / connection strings securely (e.g. with environment variables).My application is still in the test environment, but I have not yet managed to configure OpenIddict so that it works correctly. For example, I had to set "WEBSITE_LOAD_USER_PROFILE" to true to work around the problem, etc.
Since I don't have that much experience with OpenIddict and Azure yet, I have to gather all the necessary info in the forum.
yeah you're right, Openiddict and Azure configurations can be pain. But these are not direclty related with ABP. We are framework maintainers and this is more like DevOps topic. Anyway we started to write deployment documents. Check out https://docs.abp.io/en/abp/latest/Deployment/Index
-
0
-
0
I use Abp.Commercial to speed up the development of monolithic applications developed on customer request. https://commercial.abp.io/startup-templates/monolith I use abp suite to build the solution through Application Template, Blazor Web Assembly, Sql Server and Integrated Authentication Server.
I'd like to understand if it is possible to have this template also in Hosted version (single application server to Deploy)
I don't use microservices and I would like to have a template where I already have everything configured including:
- User/Permission Management with Impersonation (aka OpenIddct and/or AzureAd)
- Hangifre with Dashboard for Background jobs (Example: ETL import and export data files)
- Email Sender (Example: To send an email following an event generated in the domain)
- SignalR for Notification Service (Example: To send an alert notification in GUI) -(optional) Redis for Cache (To date I have only used it once on Azure, because on windows server on-premise it is difficult to install and maintain)
I don't use Docker, RabbitMQ or other services useful for microservices, but not necessary for a monolithic application with single server.
I don't use them because neither I nor my clients have people to dedicate for configuring and maintaining these services. So they should be transparent services for me because if I have to study how to configure and use them then I lose the advantage of using Abp.Commercial and therefore I can use Abp.Io directly avoiding the cost of the license.
What would be needed is a step-by-step guide to both deployment and correct configuration at least on Azure or IIS
The steps should be:
- Generate solution from Abp
- Change the configuration files like this:
- If you use OpenIddct you do...
- If you use Azure AD you do...
- If you use MailSender you do...
- If you want to add a BackgroundJob you do...
- etc..
- Launch the application locally
- Publish to staging/test environment you follow this steps...
- Publish to production environment you follow this steps...
A guide similar to: https://docs.aspnetzero.com/en/aspnet-core-angular/latest/Deployment-Angular-Publish-Azure or https://docs.aspnetzero.com/en/aspnet-core-angular/latest/Deployment-Angular-Publish-IIS
Thanks
-
0
We already planned to create deployment guides.
I find this to be abstract. Could you give examples/specifics of the deployment guides you are planning to create? For example for which environments? Azure, AWS or other? Will it be shown for all template types? Tiered vs non tiered, etc. MVC or angular Or Blazor?
The promise of fully comprehensive deployment guides seem almost to good to be true as I have found in reality that you have to rely on researching/learning the specifics for ABP deployments which is not expected when you use a framework that is suppose to eliminate the requirement to know the specifics. For example the docker yml file that is produced when using the ABP cli does not seem to configure everything properly for my local docker deployment, so now I’m forced to dive into the details of docker to figure out what still needs to be tweaked to get it to work.
I would have thought that perhaps you would reach out to the community prior to creating such guides to make sure you were covering the vast number of ways in which the community deploys.
-
0
I see that most of the comments are abstract.
To fine-tune our documentation and get started steps, we need concrete examples.
Because for me it's very straightforward to kick-start a project.
Imagine that you start a new scratch ASP.NET Core project with Docker, DevExpress, and Identity Server with a tiered architecture, would it be slaphappy?You asked for input on ways the support could be improved, and your responses say that you don't want to hear it.
Try to create a new solution with version 7.0.2 or 7.1.0 preview - app-pro, tiered, maui-blazor, PWA, separate identity server, and PostgreSQL. It doesn't run. You can't see the error because the screen is white and the text is white. It isn't immediately obvious if the program is hanging, or crashing, or not even starting. Once you change the text color the error just says an exception occurred in the Initialize function of one of the base ABP classes, which is not something you can debug unless you have full source code. The only way to find a more specific exception was to step through every single line of code. This is not "slaphappy".
You are selling a product that is supposed to allow the users to NOT have to become experts on all of the awesome features you have coded, but your documentation and tips for getting started are written from the perspective of people who ARE experts in all of those areas, and are expecting the audience to have a similar level of knowledge as well. I think you will have a much better chance of success with new perspective customers if you take the time to understand what things can go wrong for first time users, and provide some guidance on what a user needs to understand if they are going to deviate from the "out of the box" experience. We are very happy we are using ABP, but we had a LOT of frustration getting our solution off the ground, and we still get frustrating responses many times from support. Multiple DETAILED tickets where the response is effectively "RTFM". One was "You can't use DevExpress with a tiered solution". REALLY? We aren't expecting ABP to hand us fully functional solutions when we are doing custom integrations, but we do expect help understanding how to respect the benefits of ABP and still do what our business requires.
The framework is great, but the support frequently leaves us frustrated.
-
0
The bot automatically closes it, if there's no activity from the ticket owner. @kirotech, I reopened the ticket. and please send an email to [email protected] if you have such issues. Many people are subscribed to this topic and reading your -personal- problem.
-
0
Mosf of the time - when we have a technical question - we are asked to either send the project source code or create the test version where the problem is reproduced.
The first one is not possible because of commercial nature of the project. The second one is very time consuming and is not possible too.
Yes, our solution is quite complex and we have some custom code on the top of ABP framework. But it would be great, if your support team devoted more time trying to understand the nature of the problem and analyze the fragments of the code shown in the message. Because often the answers are very short and meaningless - so we end up debugging out solution and looking at the downloaded ABP module source codes to resolve the problem ourselves.
Agreed. Would imagine very few non profit / open source project tend to use ABP Commercial.
-
0
The bot automatically closes it, if there's no activity from the ticket owner. @kirotech, I reopened the ticket. and please send an email to [email protected] if you have such issues. Many people are subscribed to this topic and reading your -personal- problem.
Hey I don't think this problem just for us. I would suggest you to keep tickets open for at least 30 days. Because not everybody has time to respond with technical details in 7 days.
Another suggestion I would like to make. We need private tickets. Because paying customers are paying for support also why all tickets has to be public? Some problems are delicate and includes security questions like we have with your not working oauth openid functionality we have to share our applications configurations publicly this just doesn't make any sense.
Also another thing. I think your support tickets creator filter is privacy problem. If I search @gmail.com I can find emails from your support system database. Also I can find your customers account names. I would suggest to improve that or just remove it from public.
Also another thing how you can improve you support is by providing reliable information when you going to release bug fixes what we found in your abp commercial. As example your abp commercial payments bugs which we reported and had to ask several times which version fix will be included in.
-
0
The bot automatically closes it, if there's no activity from the ticket owner. @kirotech, I reopened the ticket. and please send an email to [email protected] if you have such issues. Many people are subscribed to this topic and reading your -personal- problem.
Hey I don't think this problem just for us. I would suggest you to keep tickets open for at least 30 days. Because not everybody has time to respond with technical details in 7 days.
Another suggestion I would like to make. We need private tickets. Because paying customers are paying for support also why all tickets has to be public? Some problems are delicate and includes security questions like we have with your not working oauth openid functionality we have to share our applications configurations publicly this just doesn't make any sense.
Also another thing. I think your support tickets creator filter is privacy problem. If I search @gmail.com I can find emails from your support system database. Also I can find your customers account names. I would suggest to improve that or just remove it from public.
Also another thing how you can improve you support is by providing reliable information when you going to release bug fixes what we found in your abp commercial. As example your abp commercial payments bugs which we reported and had to ask several times which version fix will be included in.
To ask questions privately, you can upgrade to the Enterprise License plan.
I understand your concern about email privacy but that combo box you mention only shows usernames. If the account owner writes his email to the username area then it'll be shown, if he writes his cell phone its shown. if we remove it from there, it's still visible in the question-answer sections. hence this is not a privacy deal.
On the other hand, if you want to see raw and detailed change logs for every release, please check the full change logs document that we recently started to publish https://docs.abp.io/en/commercial/7.1/change-logs/index
-
0
The bot automatically closes it, if there's no activity from the ticket owner. @kirotech, I reopened the ticket. and please send an email to [email protected] if you have such issues. Many people are subscribed to this topic and reading your -personal- problem.
Hey I don't think this problem just for us. I would suggest you to keep tickets open for at least 30 days. Because not everybody has time to respond with technical details in 7 days.
Another suggestion I would like to make. We need private tickets. Because paying customers are paying for support also why all tickets has to be public? Some problems are delicate and includes security questions like we have with your not working oauth openid functionality we have to share our applications configurations publicly this just doesn't make any sense.
Also another thing. I think your support tickets creator filter is privacy problem. If I search @gmail.com I can find emails from your support system database. Also I can find your customers account names. I would suggest to improve that or just remove it from public.
Also another thing how you can improve you support is by providing reliable information when you going to release bug fixes what we found in your abp commercial. As example your abp commercial payments bugs which we reported and had to ask several times which version fix will be included in.
To ask questions privately, you can upgrade to the Enterprise License plan.
I understand your concern about email privacy but that combo box you mention only shows usernames. If the account owner writes his email to the username area then it'll be shown, if he writes his cell phone its shown. if we remove it from there, it's still visible in the question-answer sections. hence this is not a privacy deal.
On the other hand, if you want to see raw and detailed change logs for every release, please check the full change logs document that we recently started to publish https://docs.abp.io/en/commercial/7.1/change-logs/index
We have to pay 10000 for license to get private tickets? Doesn't look like fair offer sorry. Really appreciate your offer, but no thank you
If your user name combo box is fine with you it is 100% fine with me. No worries here. From customer perspective it just looks strange when I search and I find your customers emails and phones. but if there is no problem it is no problem.
I'm not looking for change logs I'm looking for reliable information provided in tickets when bug fix reported going to be released. Do you see the difference?
-
0
We love the framework but support and bug reporting is not handled well. My developer has mostly given up reporting issues as he says it's not worth it as responses tend to be one line, minimum effort answers. Complex issues often just get auto-closed without resolution.
I don't mind the one line answers but they should not be considered a paid response to an issue when we only get to report 15 a year. Basic forum responses should not be included in any limit.
I would suggest you take a look at how service stack (https://forums.servicestack.net/) handle this for a fraction of the price. With a unlimited support forum for paid users with a smaller number of private escalated incidents.
There is very little in the commercial package we use as we have our own UI framework, we're basically just paying for the support forum.
-
0
We love the framework but support and bug reporting is not handled well. My developer has mostly given up reporting issues as he says it's not worth it as responses tend to be one line, minimum effort answers. Complex issues often just get auto-closed without resolution.
I don't mind the one line answers but they should not be considered a paid response to an issue when we only get to report 15 a year. Basic forum responses should not be included in any limit.
Fully agree. I also noticed that the quality of the support has deteriorated: 2-3 year ago the replies (from the same support team members, BTW) were more meaningful, detailed and looked like a "ready-to-help" dialog. Now it looks like the total amount of work on the growing framework has noticeably increased since then and the support team simply does not manage to handle the support tickets. Well - it's the most careful explanation I have.
