Number with active tasks about suluautomationbundle

[alexander-schranz]

@chirimoya @danrot Do we see this as a requirement for the 2.0 release?

[chirimoya]

Required for me.

[alexander-schranz]

@danrot any concept about how we could implement this. I could think that it would make sense to refresh the value in a specific interval and that this kind of notification counter does also make sense for the main navigation not only for the tabs as they are not rerender so some kind of polling would be needed.

What we need todo is provide the endpoint where the information does come from and which data need to added to it e.g.:

->setNotificationEndpoint('endpoint')
->addRouterAttributesToNotificationRequest(['id' => 'id']) // data from the router attributes
->addAttributesNotificationRequest(['type' => 'page']); // static data
->setNotificationRefreshRate(60) // optional refresh rate in seconds

[danrot]

Questions about this that come to my mind:

1. Does this really need to refresh? Adds a lot of complexity, and is probably not that often used. I think @chirimoya has already questioned that at some point in the past.
2. How would the response from the endpoint look like? We don't have a simple count request just returning a number yet, and loading all the automation tasks just to display a number seems like a huge overkill. Just tested if calling the List API with a limit of 0 works, which it does (at least for contacts). that would mean that we would not have to load any entities, but could still load the returned total attribute. This would then result in a configuration like this:

->setNotificationEndpoint('endpoint') // not sure if I would call this notification, would like a more generic name better
->addRouterAttributesToNotificationRequest(['id' => 'id'])
->addNotificationRequestAttribute(['type' => 'page', 'filter' => ['status' => 'pending'])

The limit of 0 could then be added by the component doing the request to find out about the number.

[luca-rath]

Just had a quick look about this topic.

1. I also don't think automatic refreshing is necessary. I would rather say, that a new request should be made everytime the user switches tabs.
2. I would not force a specific structure for the response data. We could introduce an badgeDataCondition option (not sure about that name tho) which is a jexl condition mapping the response data to a displayable string. So if someone implements a custom endpoint for the badge, he can just return e.g. {"badge": "foo"} with badgeDataCondition = "badge" (or maybe this should be set as default), but if someone uses the cget endpoint with limit = 0, badgeDataCondition would be total.

/cc @sulu/core-team WDYT about that?

[alexander-schranz]

@luca-rath

1. is okay for me at current state to avoid polling and just do it when the tabs are loaded or switched.

2. I think condition is here a little bit missleading I think a badgePath would be a better match as I think you want to use a jsonPointer here. my_data/total`. Still I think its valid to have it we should make in the automationBundle an endpoint for it and not reuse the exist list endpoint total count to avoid any overfetching.

Maybe we need to keep in mind that a Tab could have multiple badges. So maybe need a $view->addBadge(); function and create a ViewBadge object or something with the available options.

[luca-rath]

1. 👍
2. I would still prefer a jexl expression, because this is way more flexible than just a json pointer. One of the biggest benefits would be the possibility to use jexl transforms. An example could be a |translate transform. About the name, what about dataPathExpression?
3. Yes, sounds reasonable