Best thing though there is no official support for running designer on the RHEL 8.8 and 8.9 platforms. Where we as a company are forced to run RHEL 8.9 for our applications. I don't understand the lack of support here at all. The other products mentioned not being available on RHEL 8.8 and 8.9 are not of my interest.
And yes designer is a java application requiring OS support, but running both in a production envionment will lack proper support.

I do not have a problem with the change, but it is interesting to see that they do it now and not with IDM 5 (if that ever will be a thing).

I am still waiting for an official statement from OT on the licensing thing, if they can keep it within UBI then great, but I doubt it (we shall see).

They can't or they do not want to invest in upgrading the eclipse paltform - they basically have painted them into a corner and can find a way out.

I have been pushing for an official statement on the MacOS support and have not received one, basically as long a Eclipse works it works, if it breaks .....

I agree with the painted in a corner spot.  I think the problem is, you can hire an Eclipse expert, they exist. But it takes 6 months to train them on how Designer modifies Eclipse. And in India, it is odd if you stay at a job too long. It can wreck your career.  Spoken to past Engineering PM's they said keeping staff longer than 6 mon-1 year was the hard part.  Convincing them it was good to stay, learn, progress, etc was hard.  

So by the time someone is good enough to fix the Designer problems, they are usually heading off to other pastures. So they may NOT be able to fix it.

Conversely, looking at all their competitors, none of them have an offline tool like Designer (Not MS Entra, not Sailpoint, not Forgerock/Ping).  So losing it is a big loss for them...

They should bite the sour apple and hire someone in North America or Europe.

I doubt they will do anything to keep Designer alive, they are now focused on ILM which (from what we where told at TTP) will not provide people with off-line development - back to the days of dirxml.

It would be a miss, and they might end up regretting it as it is the big difference.

In the age of the commercial public cloud, an offline tool seems to many like a dinosaur technology.

Everything has to be always online and accessible via a web-UI and an API or command line.

I think that is influencing all software vendors decision making (not just OpenText).

Also agree with Casper that this will ultimately be a mistake.

Designer (love it or hate it) is one of the two key features that distinguish the OpenText IDM offerings from the multitude of other vendors.

The other killer feature is the real time event based engine. As far as I understand that is also being watered down in the ILM product. (near real-time only).

Companies are now starting to think about moving key technologies back more under their direct control into say a private cloud. Especially key security pillars like their IDPs and their IDM. Too many hacks, the scale and frequency of which is starting to become extremely concerning.

As for hiring a developer in a more stable employment market. That bumps the costs by a factor of many times. Which makes such a decision even less palatable for an Engineering PM who has to keep costs in line with projected revenue.

Indirectly there is by the support of RHEL 8.7 (https://www.netiq.com/documentation/identity-manager-49/designer-49-release-notes/data/designer-49-release-notes.html) - unless they do the same as with the (removed) support of RHEL 7.9.

The norm has always been that when a product is released there is support for XYZ (in this case RHEL 8.7), this implies that there is support (not tested) for RHEL 8.8 and 8.9. They will try to help, but does not promise to fix something to make it work.

The major difference between RHEL and SLES (and I prefer RHEL over SLES) is that Redhat can change their libraries in the middle of the life of a version (like they did with kerberos in RHEL 8.4 (afair)) which then renders everything which is depending on the previous version inoperable. Meaning they do not always backport.

The best way forward is to use containers where possible.

Hi all, I just want to quickly mention, that there is an issue with sending emails from templates with version 4.9!

DirXML Log Event -------------------

     Driver:   \WORKFORCE\server\s05edir02_driverset\User Notification

     Channel:  Subscriber

     Status:   Error

     Message:  Code(-9195) Error in vnd.nds.stream://tree/server/driverset/User+Notification/Subscriber/sub-etp-intruder-lock#XmlData:166 : Couldn't send email: java.lang.NoSuchMethodError: 'int com.sun.mail.util.QEncoderStream.encodedLength(byte[], boolean)'

Maybe this information helps anyone out there to notice this before upgrading a productive environment and then suddenly realizing, that notifications are not working anymore
There is an SR opened already for this issue, but currently there is not really a workaround. We needed to provide a new server with 4.8.7 which now runs the driver sending the notifications...

I am probably wrong, but I guess that they used to depend on javax.mail being part of the JRE, now it it belongs to Ellipse Org.: https://javaee.github.io/javamail/

But QEncoderStream was gone before they send it off to Eclipse, wonder where they got it from with IDM 4.8 ...

I know this probably is not the same issue, but have you tried this? https://portal.microfocus.com/s/article/KM000019133?language=en_US

In any case, thank you so much for reporting this I was just in the process of preparing for an upgrade in the customer environment... Will probably try replicating it in our test environment where we already have 4.9 installed.