![QPclosing | Embarcadero RAD Studio Delphi C++Builder Blogs qpclosing](https://i0.wp.com/blogs.embarcadero.com/wp-content/uploads/2024/01/QPclosing-6678031.png?resize=1140%2C694&ssl=1)
Note that our new Quality portal is now live. Read about it here: https://blogs.embarcadero.com/the-new-quality-portal-is-live-here-are-the-details/
Quality Portal (https://quality.embarcadero.com/) is Embarcadero’s customer facing website for reporting bugs in the products, issues in the documentation, or to suggest new features to implement. In particular, there is a project in the Quality Portal site for RAD Studio, called RSP. This portal is powered by Atlassian JIRA and it has been hosted in house for many years now, after migrating from an old homegrown system called RAID.
Quality Portal has served us and our customer needs well over the years. As you may have heard, Atlassian has discontinued supporting on-premise servers and asked customers to migrate to the Atlassian hosted version.
The plan is to have a new public bug reporting and feature request portal for RAD Studio using the Atlassian JSM (Jira Service Manager) front end, working in conjunction with the JIRA system used by R&D. The new portal will continue to serve the purpose of allowing customers to log issues and make requests, even if it will offer a different user experience. In addition, it will have the advantage of being a standard, stable, and fully integrated system.
For the time being, the existing Quality Portal system will remain accessible read only. The data on the old system will remain visible, even after the new portal will be in place.
This migration has been planned for a few months and the expected timeline is now. Quality Portal will shortly become read only. We expect to have the new portal in place soon and we’ll have a new blog post explaining how to use it and providing additional information.
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
Are we there yet? It is well and truly next week.
Hi, Same as Lars, the week is well over now.
I actually have some understanding of what Embo are having to do here, having been involved in a migration of an on-prem Jira instance to their cloud hosted offering. There are a lots of dots to be joined up so that valuable information is not lost, and the service we get as customers is maintained.
There is also a $$$ element as the on-prem version had no additional licensing costs for adding a registered (customer) user, the cloud version requires a licence payment for any user – so they are having to convert the first class access we previously had to the JSM portal.
This too will pass.
Looking forward to the new Quality Portal!
I need to report a literal show-stopper issue for Delphi 12 – [dcc32 Fatal Error] BadUnit.pas(2483): F2084 Internal Error: AV00000000(50CA0000)-W00000000-8
that is stopping compilation of a unit that was perfectly fine in Delphi 11.x
Any word on the update? While this remains unreported, not only can’t I use Delphi 12 – it’s not even been worked on!
For critical bug reports, please contact Embarcadero support
How should we best contact support? I have a mission-critical System.IOUtils.pas bug to report: on macOS , TDirectory.GetFiles returns a TStringDynArray that does not list valid file names with three and four consecutive periods in their names. Thanks.
I just installed the Bonus KSVC 7.0 from GetIt.
Now I get these errors. I am dead in the water.
[bcc32c Error] RzCommon.hpp(647): unknown type name ‘_DELPHI_CONST’
[bcc32c Error] RzCommon.hpp(647): cannot define or redeclare ‘Word’ here because namespace ‘Rzcommon’ does not enclose namespace ‘System’
[bcc32c Error] RzCommon.hpp(647): expected ‘;’ after top level declarator
Workaround is very simple. Place
#if !defined(_DELPHI_CONST)
#define _DELPHI_CONST const
#endif
at the beginning of RzCommon.hpp. Recompile project and install components.
If you look at the same header for the same Bonus KSVC 7.0 but for BCB 11.x
it was just standard const. There is no typedef o #define for _DELPHI_CONST
in BCB headers. The _DELPHI_CONST appeared in BCB 12.
Looks like (dcc?) a new, yet another, symbol for const was introduced.
Whats the rationale?
Michal Mucha I’ve been told a fix for that issue has been pushed live. Can you download the package again and retest it?
same for me, it’s impossible to access older entries, for example
https://quality.embarcadero.com/browse/RSP-44018 that is mentioned here https://delphiworlds.com/2024/02/ongoing-support-for-third-party-ios-sdks-in-kastri/ to see the discussion thread. Obviously precious information is on those reports/discussions that shouldn’t be lost
The historical information on the old QP has been carefully curated and preserved internally. It will definitely not be lost. It was necessary for us to carry out substantial reformation on the Quality Portal, partly due to some changes from Atlassian with regard to Jira (the issue tracking software behind the scenes of QP) and because it had been long overdue. The old system had several difficulties for a number of reasons and it was necessary to completely rework how issues could be reported and how they would be tracked and synced on our internal systems. Ultimately it should be a superior solution. It’s taken longer than we expected to get it launched but we are almost ready with it now.
Just a feeling: It would be much nicer if “WE” could hear from time to time where “WE” stand – when “WE” can expect the new QP.
e.g. Ian Barker’s information doesn’t sound so bad after all! BUT “WE” get almost no information at all.
I’m not sure I entirely understand your question? “We” means me, you, and others? Or others and you?
Let me take another run at explaining…
We (Embarcadero) are currently testing the new portal among a small group of people both internal and external. There are some things which are not right with it and we (Embarcadero) are getting those addressed by the specialist team who are working on that portal. As I mentioned, it took a lot longer to get to that stage than we (Embarcadero) had believed. But it has to be right due to the importance of the key elements of the chain of things which goes on when an issue or suggested new feature is made via QP.
We (Embarcadero) believe we’ll be ready to roll this out soon – and by that, I mean as soon as we possibly can. We (actually, in this case it will be me) will be producing a blog post introducing the new QP and pointing out the new functionality and so on.
At scale, there are a lot of moving parts to QP even though on the face of it you’d be forgiven for thinking “well how hard can it be”. I know. You want it quicker. We (Embarcadero) want it quick too. But it also has to be right. If we (Embarcadero) make missteps, and we (Embarcadero) are clearly not magical beasts at avoiding computer-related drama, then if it’s in such a fast-moving, critical thing such as QP, it can quickly snowball into something even more awful than it being annoyingly unready to launch.
We (Embarcadero) want to get you QP as quickly as we can. I think you want that too. You also want a date and time, sort of, and that would be nice, but the truth is, right now, we can’t be more accurate than “very soon, we thought it would be ready by now, but it isn’t”.
Thanks for the information.
WE was deliberately chosen to be ambiguous.
WE can mean us users of RAD Studio – but it would be better if users and developers of RAD Studio work together.
My criticism was that we users only notice that the QP no longer works.
It should work again at the end of next week, that was the information from Embarcadero … and then WE (users) won’t hear anything anymore – for weeks.
The same applies to the Get It Server.
Believe it or not: We users also have to plan our work and for this information when and if something continues is important.
Thank you for your information about the new QP – such open information should come more often.
I have no problem waiting longer if the quality is better. Quite the contrary.
I’m very excited to see how everything continues 🙂
Above all, on further development regarding C++ in 12.1
BTW: Logging into the old read-only QP works again for me again. Thank you!!!
I hope all the open issues of the old QP will automatically be transferred to the new QP, during the migration process.
I have a bug in Delphi 12 and cannot report it to be fixed.
Marco, I’ll report it here.
In an MDI app, if you try to close the Main form and the FormClose event would block this by setting Action := caNone, the form is being closed anyway, well actually it’s hidden not closed, so the program is still alive, but hidden (you have to kill it from task manager).
In D11 and below this would simply prevent the form from closing, letting the program run as before.
I’ve logged this MDI issue internally, we’ll have a look
Hello Marco, I cannot report the following error, or how it would be solved: I was used to previous versions of Delphi, to be able to block the use of the Hardware back button on Android devices by placing an Action with the shortcut = Hardwareback, having full control. But in Delphi 12, it executes the corresponding action but at the same time closes the active form. And that’s what I don’t want, for the form to close. I don’t know if it is a Bug or if there is some other way to block the use of the Back Button.
I would like to report a regression bug in Delphi 12. What is the right place to do it? It is briefly described here, of course I can provide more information: https://en.delphipraxis.net/topic/11170-regression-delphi-12-unable-to-debug-dynamically-loaded-packages/
With 12.1 released a working quality portal would be nice.
Just tried to compile our components: error F2084: Interner Fehler: AV006A992F-R0000014C-0
Use the new QP here: https://embt.atlassian.net/servicedesk/customer/portals
How do I report a Delphi 12.1 issue (released today)? The quality/bug portal is still down.
You can use the new quality portal here: https://embt.atlassian.net/servicedesk/customer/portals
A new portal is available, we plan blogging about it tomorrow. If you want to start exploring on your own, https://embt.atlassian.net/servicedesk/customer/portals
I have registered the new quality portal. So all the old issues are gone? I know they are available on the old site, but what about is the purpose of the migrations if the old issues are not exported to the new site?
I am preparing a blog post now which explains the new portal. The new one is a different beast to the old portal (not 100% our choice – Atlassian has made some changes to their offerings).
I thought it was taking so long because you couldn’t transfer the old records. The portal is working now, but without the old records… 🙁 I’m really curious to see how this goes. But most importantly, I wish someone would take an active interest in the portal and there wouldn’t be months and months of entries with no response.
There is a blog post coming which will explain things a little more about the portals.
It sort of works. I can report a bug, but searching for bugs doesn’t return any results at all, even if I search for the very bug I’ve just posted. There isn’t any list at all. At least I didn’t see one… It would be quite impossible to prevent dozens of duplicates without knowing which bugs do already exist.
Nevermind. I’ve found the list, but it isn’t very intuitive to find, though.
I am not able to view any issues in the new system. It appears like there are no issues in the system yet. But according to Jochen’s post above, there should be at least one issue in the system.
It’s a bit hidden and not very intuitive.
You have to login first and then you’ll find in the top right corner (left of the avatar photo) a small menu “requests”. Click it and the small menu should expand. There you select the entry named “all”. The list should then appear.
Yes, I have tried that many times. I always get an empty list.