/api/programs/<uuid> Request method 'GET' is not supported

Support - Assistance technique
1

api/programs/nbxX866THY returns a 405

httpStatus Method Not Allowed
httpStatusCode 405
status ERROR
message Request method ‘GET’ is not supported

which looks strange since Login app | DHIS2
seem ok on play
is it possible that it’s hiding a sharing/permission problem ?
we were at 2.42.2 is this something that was fixed in later release ?

I found this stacktrace is possible that it’s linked ?

2026-01-28 13:35:33 ERROR CrudControllerAdvice:633 - java.lang.Exception
java.lang.NullPointerException: Cannot invoke "org.hisp.dhis.user.UserGroup.getDisplayName()" because the return value of "org.hisp.dhis.user.UserGroupStore.getByUidNoAcl(String)" is null
	at org.hisp.dhis.user.DefaultUserGroupService.lambda$getDisplayName$2(DefaultUserGroupService.java:235)
	at org.hisp.dhis.cache.LocalCache.get(LocalCache.java:99)
	at org.hisp.dhis.user.DefaultUserGroupService.getDisplayName(DefaultUserGroupService.java:235)
	at jdk.internal.reflect.GeneratedMethodAccessor1760.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:359)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:380)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:223)
	at jdk.proxy3/jdk.proxy3.$Proxy177.getDisplayName(Unknown Source)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.lambda$applySharingDisplayNames$9(FieldFilterService.java:557)
	at java.base/java.util.LinkedHashMap$LinkedValues.forEach(LinkedHashMap.java:647)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.lambda$applySharingDisplayNames$13(FieldFilterService.java:557)
	at org.hisp.dhis.fieldfiltering.FieldPathHelper.visitFieldPath(FieldPathHelper.java:256)
	at org.hisp.dhis.fieldfiltering.FieldPathHelper.visitFieldPath(FieldPathHelper.java:278)
	at org.hisp.dhis.fieldfiltering.FieldPathHelper.lambda$visitFieldPaths$13(FieldPathHelper.java:247)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at org.hisp.dhis.fieldfiltering.FieldPathHelper.visitFieldPaths(FieldPathHelper.java:247)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.lambda$applyFieldPathVisitor$6(FieldFilterService.java:459)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.applyFieldPathVisitor(FieldFilterService.java:456)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.applySharingDisplayNames(FieldFilterService.java:546)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.toObjectNodes(FieldFilterService.java:269)
	at org.hisp.dhis.fieldfiltering.FieldFilterService.toObjectNodesStream(FieldFilterService.java:348)
	at jdk.internal.reflect.GeneratedMethodAccessor627.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
2

Hi @Stephan_Mestach

Could you share a description of how the sharing settings for this program are configured?

Could you test by providing the specific user with access (not through a usergroup but directly using the user’s username)?

Thanks!

3

Hi @Stephan_Mestach

Were you able to solve this issue? Thanks!

4

Removed the no more existing user or groups in the sharing settings solved the issue (don’t have the record details, since I made the update a long time ago)

I still don’t know why this happened (I understand there’s no foreign key inforcement since it’s stored in json field)

But I would make the code more robust when reading the sharing settings.
It already happen on 2 or 3 times on different instances. Not always with that behavior.
In another case it was accessing a organisationUnitGroup by id via the api or accessing a programStage (returning a error 500).

the sql to “remove” in mass

update programstage set sharing = sharing::jsonb #- '{userGroups, ZWgK3enU1yP}';

where ZWgK3enU1yP is the groupId that was deleted.

1 Like