High Issue Summary
Some users are not able to search for objects with attribute type Object due to IQLValidationException: No matching attribute for AQL clause ()
This is reproducible on Data Center: yes
Steps to Reproduce
- On a JSM instance with version below 4.20.25, prepare a schema with a few object types.
- In one of the object types, create an attribute type Object to reference it to another object type.
- Insert an AQL to filter the objects for this attribute.
- Create objects accordingly and make sure objects are being filtered properly.
- Add a non-admin user to the Object Schema Developer role, and leave all other Object type level roles unassigned.
- Log in as this user, edit an object, and edit the attribute with the type of Object. This user should be able to search for an object and update the attribute value successfully.
- Upgrade this instance to >=4.20.25.
- Copy the schema and leave it as it is.
- Repeat step 6 on the original schema.
- Delete the cloned schema.
- Repeat step 6 again.
Expected Results
Without any intentional changes, users who used to be able to edit objects can still edit the same objects after upgrade
Actual Results
After upgrade, some users face issue when editing some objects/object attributes. The below exception is thrown in the atlassian-jira.log file.
2023-10-04 07:05:24,634+0000 http-nio-8080-exec-5 url: /jira/rest/insight/1.0/objecttype/104/objects; user: testuser INFO testuser 425x1184x1 wveuqs 185.53.145.95,172.50.0.1 /rest/insight/1.0/objecttype/104/objects [c.r.j.p.i.services.util.ServiceUtil] InsightException:IQLValidationException: No matching attribute for AQL clause ("Server" = ad-1234)
com.riadalabs.jira.plugins.insight.common.exception.IQLValidationException: IQLValidationException: No matching attribute for AQL clause ("Server" = ad-1234)
Other symptoms are
- A pop-up screen that says
The Jira server was contacted but has returned an error response. We are unsure of the result of this operation.
- The attribute which should allow users to search for objects and select it as value doesn't suggest any objects
- HTTP status 400 is returned with an error "No matching attribute for AQL clause" in the response
By enabling debug for com.riadalabs.jira.plugins.insight.services, we'll find that the permission of the affected user is being checked for an irrelevant object type (which is in a different schema and this user shouldn't have permission to).
2023-10-04 07:05:24,634+0000 http-nio-8080-exec-5 url: /jira/rest/insight/1.0/objecttype/104/objects; user: testuser DEBUG testuser 425x1184x1 wveuqs 185.53.145.95,172.50.0.1 /rest/insight/1.0/objecttype/104/objects [c.r.j.p.i.services.permission.InsightPermissionServiceImpl] hasInsightPermission (InsightUser{key=JIRAUSER11102}, 5, 271)
Workaround
If possible, grant the affected users Object Schema Developers or Object Type Developers role in the copied schema(s)
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-14736] Some users are not able to search for objects with attribute type Object due to IQLValidationException: No matching attribute for AQL clause ()
Same situation as @Gulyás Tibor, but unfortunately our existing higher group for the affected schema is for Jira administrators, so we couldn't grant affected users that group...
Still stuck without workaround, hope a fix will come soon.
Hi,
The given workaround not works for us that way, i.e.: giving a higher right directly to the user.
But if there is a previously added group in a higher role, and we assign the user to that group, it works well.
Regards,
Tibor
Hi,
Will there be fixes for 5.9.x versions?
Best regards,
Alvin
Seems like we do not need to set a higher level of permissions in the copied schema.
Setting the same level of the permissions in the copied schema (read) works for us.
Best Regards
Hi Xavier, the planned release of 5.4.12 is expected to be rolled out in early November.
@Yufei Zuo Hello, any idea of when release 5.4.12 will be disponible for download?
regards,
Xavier.
Hello,
In our JIRA DC instance, the problem appears on the aql queries in which we use an attribute of type "Project". Our workaround to avoid modifying the configuration (Issue Scope) of all our Asset fields was to create a new attribute of type "Text" using the name and value of the attribute of type "Project", and to rename the attribute of type "Project" (to keep it if a rollback is possible once this bug has been resolved). It was an arduous task!
Other information: the workaround proposed in this ticket doesn't work for us.
Regards,
Pierre-Jean Constant.
Customer tried upgrading to JSM 5.10.2 since it was not listed as affected, but same issue exists there..
Somehow the affected users can use the same Asset fields on Customer Portal view without any issues, they get the problem only from Jira view, so we tried some workarounds with that approach.
Hope a fix can be released soon.