IFS Developer Studio - bugs

Static Code Analysis:

Validating CVertiflexResponse-Cust.entity

Implementation file exists without the corresponding Model file

​@InfFilipV Can you select a different target version and see ? 

cannot open Context menu in new Customized fragment file
 

​@InfFilipV  can you pls send a screenshot and the version of the tool

Right click do nothing, just error is logged in IDE log.
app version is present in IDE log
 

Product Version: IFS Developer Studio 18 (Build 26.1.1220 2026-08-12)

Java: 17.0.8; OpenJDK 64-Bit Server VM 17.0.8+7-LTS

Runtime: OpenJDK Runtime Environment 17.0.8+7-LTS

System: Windows 11 version 10.0 running on amd64; UTF-8; en_US (developer_studio)

reinstallation helped, but daily reinstall is not solution… (maybe you could add button to delete cache folder in error console? to simplify that process, sometimes it really helps)

​@hamalk 
Again there is a problem with staring local server using Docker :/

Product Version: IFS Developer Studio 18 (Build 26.1.1220 2026-08-12)

After setting up the project I try to start the server and I get:

WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get "https://ifscloud.jfrog.io/v2/": unknown: Token failed verification: parse
Docker credentials or container repository invalid!

using the same credentials in terminal:

What is wrong???

and why this section can be seen once in a lifetime when you are setting up new project?

It is impossible to change the password to container repository.

​@Jonas Feigl ​@hamalk  - could anyone have a look on that?

Hi, Is true that I did not use Docker for a while, but I never filled this and it worked with some DEV nonProd images.

Really not my area of expertise so not something I can help with.

Hi,

There is no need to fill this data for customization projects. For Core Projects this data is used, but not for customization projects. That these fields are showing when setting up a new Customization project is a defect.

For customizations the tokens are delivered through the application itself, but due to a recent rotation of credentials this stopped working.

Both these issues are corrected in the next release of the Developer Studio tool, 26R2-EA tool release, planned on October 15th.

/Andreas

 “Generate Code and Deploy only Packages” deploys everything... 

Thank you for the explanation and fix

Hi,
I modified entity and now I need to redeploy Projection to include new fields.

But new version for 26r2 does not allow this anymore.

Is really correct approach to Customize it, deploy and delete?

https://ibb.co/VZxdJpq (you blocked image upload because of PHP vulnerability?)

 

Product Version: IFS Developer Studio 18 (Build 26.2.1308 2026-10-02)

Java: 17.0.8; OpenJDK 64-Bit Server VM 17.0.8+7-LTS

Runtime: OpenJDK Runtime Environment 17.0.8+7-LTS

System: Windows 11 version 10.0 running on amd64; UTF-8; en_US (developer_studio

Static Code Analysis issue

{Line 54} TRUNC is not connected to any module. Dependency could not be derived.. . If the dependency is dynamic, then conditional compilation needs to be used.. If you have already added the dependency to deploy.ini but it has not been included in a build yet, you can manually add the dependencies in your development database using Installation_SYS.Register_Dependency. . Do not include this call in any scripts though as in deliveries this has to be controlled by deploy.ini.

Assistant - Client Control - runtime issue

Using a `processviewer` now errors when inside an `arrange`. This design worked well in previous versions of IFSCloud but in 25r1the page errors until the processviewer is removed from the arrange.

Looking at the documentation, it still says it's a valid property of arrange

IFS version: 25.1.16

Please consider the issue that was reported in this topic:

Has the behavior changed for "Generate Code and Deploy" on read-only files in Developer Studio (version 26.2.1308 / 2026-10-02)? | IFS Community

We are facing this issue with any .fragment files.

exception blocking generation code for customized projection

java.lang.NullPointerException: Cannot invoke "ifs.dev.dsl4.DefaultRuleNode.getChildren()" because "mergedModel" is null
    at ifs.dev.model.codegen.cloud26r1.projection.ProjectionCommon.getItemsUsingExt(ProjectionCommon.java:869)
    at ifs.dev.model.codegen.cloud26r1.projection.ProjectionCommon.getItemsUsingExt(ProjectionCommon.java:864)
    at ifs.dev.model.codegen.cloud26r1.projection.Projection26R1LayerConsolidatorImpl.mergeDatasourcesForBasedOn(Projection26R1LayerConsolidatorImpl.java:121)
    at ifs.dev.model.codegen.cloud26r1.projection.Projection26R1LayerConsolidatorImpl.consolidate(Projection26R1LayerConsolidatorImpl.java:113)
    at ifs.dev.model.codegen.cloud26r1.projection.Projection26R1LayerConsolidator.consolidate(Projection26R1LayerConsolidator.java:15)
    at ifs.dev.model.codegen.cloud26r1.projection.Projection26R1CodeGenerator.prepareConsolidatedStructures(Projection26R1CodeGenerator.java:2294)
    at ifs.dev.model.codegen.cloud26r1.projection.Projection26R1CodeGenerator.prepareConsolidatedStructures(Projection26R1CodeGenerator.java:1021)
    at ifs.dev.model.codegen.cloud26r1.client.Client26R1CodeGenerator.generateCode(Client26R1CodeGenerator.java:421)
    at ifs.dev.model.codegen.cloud26r1.client.Client26R1CodeGenerator.generateCode(Client26R1CodeGenerator.java:78)
    at ifs.dev.nb.model.config.action.GenerateCodeActionImpl.generateFiles(GenerateCodeActionImpl.java:268)
    at ifs.dev.nb.model.config.action.GenerateCodeActionImpl$DependencyGenerator.generateFiles(GenerateCodeActionImpl.java:877)
    at ifs.dev.nb.model.config.action.GenerateCodeActionImpl$DependencyGenerator.lambda$generateCodeForType$5(GenerateCodeActionImpl.java:863)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
    at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
    at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
    at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
    at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
    at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:765)
    at ifs.dev.nb.model.config.action.GenerateCodeActionImpl$DependencyGenerator.generateCodeForType(GenerateCodeActionImpl.java:841)
    at ifs.dev.nb.model.config.action.GenerateCodeActionImpl$DependencyGenerator.run(GenerateCodeActionImpl.java:717)
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1419)
    at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
    at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2034)
 

Product Version: IFS Developer Studio 18 (Build 26.2.1308 2026-10-02)

Java: 17.0.8; OpenJDK 64-Bit Server VM 17.0.8+7-LTS

Runtime: OpenJDK Runtime Environment 17.0.8+7-LTS

System: Windows 11 version 10.0 running on amd64; UTF-8; en_US (developer_studio)

Hi,

Can we get some more info. You are generating code for a client, but is it the client or projection that is customized?

Is this just for one file, or for all files? If only one, which file is this, can you attach the content, or make an example where this occurs?

From the trace it looks like the codegenerator cannot find the projection used by the client for some reason.

Confirm also that the core files location is set to a valid path with files coming from the 26R1 zip from buildplace.

Best Regards Andreas

Hi Andreas,

Thanks for the reply. Unfortunately I can't give you more details. I don't know which file caused it. In this case, restarting the IDE fixed the problem, so I can't reproduce it now. That suggests some stale state inside the IDE, not a problem in the files themselves.

I work on dozens of projects in versions from Apps 9 to 26R1 and I can't wait for a fix. When the IDE fails, I restart it, reset it, rename files or rewrite the code, and move on. I hit 1 to 3 IDE issues every day. I report an issue when the stack trace looks useful, but I don't keep the files. They also belong to customers, so I can't share them in a public forum.

One suggestion: if the code generator cannot find the projection used by the client, the error should name the projection and the client file. A NullPointerException with no file name is very hard to report or fix.

A related and very common problem: a -Cust file that is new in the project and has no underlying core file. The code generator often expects a core file, which does not exist and should not exist. This may be a design issue. For the tool, a Cust file that customizes a core file looks the same as a completely new file in the Cust layer. An explicit marker could help, for example "extends InvoiceItem;" for a customization of an existing core object, and no such line for a new object. Then the generator and the static validation would know what to expect.

My general experience is that development in the Customization layer is tested too little. For example, the IDE requires core files to be read-only, but deployment blocks read-only files.

Also, new static validations are enforced on older versions. A new example we found is the PackageSpecViewReference rule: "A package specification must not reference a view because views are deployed after package specifications." It is raised for a public type declared with %ROWTYPE of a view in a Cust layer file, so the declaration has to be moved or rewritten. A few posts back it was said that such changes should not come out of the blue, but with 26R2 there are again new static validation errors for all previous versions. For Partners this means a lot of extra support work.
 

Best regards,
Filip

Scrollbar in project view is not shown after project change.

Hi,
could you please remove this restriction for non IFSAPP objects or at least SYS?
I’m pretty sure that SYS objects are available in moment of package specification deployment.

And again, we are forced to rework something totally harmless (and without simple solution, because there is not underlaying table which can be used instead) and move it from one util package to dozens of packages.

BTW something, which we had to start using because of 25R2 EBR and synonyms used for Materialized views.
 

Hi

I completely endorse ​@InfFilipV’s point with regards having to “rework something totally harmless” again.  Wouldn’t it be possible to a user option to stop IFS Developer auto-updating so that users on previous IFS builds can chose to continue as they were, especially with the fundamental changes required for 25R2 onwards?

mmck

Hi,

I don’t think disabling Developer Studio updates or staying on an older version is a reasonable solution.

The real issue is that static code analysis rules should be tied to the target IFS version, not to the installed version of Developer Studio.

When new validation rules are introduced, or existing rules change in behavior, priority, severity (warning vs. error), or enforcement, these changes should apply only to the IFS release they were designed for.

For older releases, validation behavior should remain consistent throughout their supported lifetime. If changes really need to be introduced retroactively, they should at least be optional or possible to disable on a per-project basis.

As a partner developer, I work on many customer projects across different IFS releases, release updates (RUs), and service updates (SUs). I cannot simply stop updating Developer Studio or stay on an older version. I also cannot maintain multiple IDE versions side by side and switch between them depending on the project.

Developer Studio should automatically apply the appropriate validation rules based on the exact target version configured for the current project, including the relevant RU or SU where applicable.

This is not the first time I have raised this concern. We had essentially the same discussion back in June regarding the DependencyNotFound validation, when an existing warning was changed into a blocking error for all previously supported releases.

I already explained at that time that changes of this magnitude should be introduced with a specific RU or SU, communicated in advance, and should not retroactively affect older versions.

See my previous comment:

https://community.ifs.com/framework-experience-infrastructure-cloud-integration-dev-tools-50/ifs-developer-studio-bugs-53458/index2.html?postid=224899#post224899

Unfortunately, we are now seeing the same situation again with other static validation rules.

The current approach is particularly problematic for partners. We regularly have to revisit and rework existing, previously valid and working code simply because Developer Studio received an update, even though nothing has changed in the target IFS version or the customer’s environment.

This creates unnecessary maintenance work across multiple customer projects, often without any actual benefit to those customers. In some cases, we are forced to restructure code that has been working for years just to satisfy a newly introduced validation rule that was never part of the requirements for that release.

I’m not arguing against improving static code analysis. These improvements are valuable, and I understand the intention to detect potential problems earlier in development. However, improvements to the development tool must not retroactively change the development requirements for existing IFS releases without providing a compatibility option.

I believe we need a general solution to validation versioning rather than addressing each new rule individually. New rules, changes in severity, and changes in enforcement should all be version-specific.

Updating Developer Studio should not, by itself, make previously valid and working code invalid or prevent its generation and deployment.

Best regards,
Filip