-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flexible id tags #133
Flexible id tags #133
Conversation
bdaa5a6
to
204adf5
Compare
204adf5
to
5f0a3f9
Compare
library/Notifications/Widget/ItemList/IncidentHistoryListItem.php
Outdated
Show resolved
Hide resolved
62256b1
to
19b5cc8
Compare
e6cf802
to
5b87eaf
Compare
I wanted to give this a try, but I only got exceptions on the event and incident detail pages. Event detail:
Incident detail:
Tried with this PR as is as well as rebased onto main in both the For the parts that I could try, the looks are more, let's say functional: That should probably receive some nicer styling, however, I don't decide if this is part of the scope of this PR. |
Please pull |
5b87eaf
to
7100594
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding new patterns to the phpstan baseline is already not a thing I'd accept, but some of them seem to relate to actual bugs. Please have a look and avoid adding stuff to the baseline.
library/Notifications/Widget/ItemList/IncidentHistoryListItem.php
Outdated
Show resolved
Hide resolved
6f76fae
to
3b120d1
Compare
3b120d1
to
fb5633b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this, because none of the issues is a deal breaker. To get this done before my vacation, I accept these limitations. Though, they should be tackled later on.
|
||
$relations->belongsTo('source', Source::class)->setJoinType('LEFT'); | ||
} | ||
|
||
public function getName(): ValidHtml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is subject to change in #132. If there's a need to render a more complex name, it involves changing what's a link and what's not. Hence the hook will be triggered way before this method is being called. So it should be sufficient to return a string here.
$relation = $isIdTag ? 'object.tag' : 'object.extra_tag'; | ||
$tagName = $tag->tag; | ||
|
||
yield $relation . '.' . $tagName => $tagName; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should render the label as it's done after the filter has been enriched. i.e. Currently only host
is shown. By completing the filter, it changes to Object host
. It should be Object host
to begin with. Though, I'd rather drop the Object
prefix and just capitalize the tag name. Anyway, my main point is, it should not be shown differently in the suggestion list than it's shown after a condition is complete.
/** @var Query $objectIdTagQuery */ | ||
$objectIdTagQuery = $this->object_id_tag; | ||
/** @var ObjectIdTag $id_tag */ | ||
foreach ($objectIdTagQuery as $id_tag) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This leads to a separate query for tags for each list item. (If this method is called by a list item)
That's rather in-effective and should be avoided. The plan here should be to join the tags in the base query already, group it and aggregate the tag names and values in two separate columns. They can then be split and combined by php, which is still better than issuing multiple additional queries.
Blocked by