22378 reshape customscript object column

[mburggraf]

Closes: #22378

I went for a simple approach, using parent_object when present. I was thinking about doing the same for .device and .group, but wasn't convinced it would help much.

I was wondering, if there is some sort of convention on how a parent object should be referred to (see discussion #22403).

Removed the unused render_url() function as well.

[jeremystretch]

@claude /review Only report on issues of potential concern; we don't need commentary on anything that doesn't require further consideration.

[github-actions]

Claude finished @jeremystretch's task in 58s —— View job

---

Review

One critical bug and one performance concern to address.

---

RuntimeException is not a Python exception (tables.py:837)

except RuntimeException:

RuntimeException is a Java class — it doesn't exist in Python. Because Python only evaluates the except clause when an exception is actually raised, this silently works when no exception occurs. But when any exception is raised inside the try block (e.g. Resolver404, ObjectDoesNotExist, AttributeError from a non-standard view), Python will attempt to look up RuntimeException, find it undefined, and raise a NameError — the opposite of the intended fallback behavior.

Fix: use Exception to catch everything, or narrow to the specific exceptions that might occur (Resolver404, model.DoesNotExist, AttributeError). Fix this →

---

Per-row database query (tables.py:827)

obj = model.objects.get(**match.kwargs)

This issues a separate database query for every row in the log table. Scripts that log many objects will produce a large number of queries per page render. Since ScriptResultsTable already has record['url'] and the display value, consider whether the parent object info could be injected into the log record at write time (when the script runs) instead of being resolved on every render.

---

• Read changed files and analyze the PR
• Post review feedback

[jeremystretch]

I appreciate what you're trying to achieve with this change, but I'm not sure it' feasible from a performance standpoint.

[jeremystretch]

This is an invalid exception, but it also doesn't adequately contain a potential failure. The method will still attempt to reference record['url'], which (per line 820) might not exist.

[mburggraf]

My intention was, that if anything goes wrong, the whole function would execute in the same way, it does currently, before my PR.
So if record['url'] is empty, it currently generates a link with empty href…
I fixed the Exception name.
But I noticed, that the if statement is kinda useless if I accept running into an exception anyways, so I removed the if-line for performance reasons.

[jeremystretch]

We need to avoid potentially triggering an individual query per log line.

[mburggraf]

Actually I wanted to go with a change, which has as minimal impact on the current structures as possible.

The suggestion from Claude to injected the parent object information into the log record at write time would go against this, since it would impact the whole log format and therefore breaking backwards compatibility. (Scripts which were run before the change don't possess this information)

The additional query is only done for those log lines, who have set an object in the first place (since render_object() isn't even called when there is no object), therefore IMHO the trade-off regarding the performance does not weigh as heavily in comparison.