Is it possible to add a "create" button at the bottom of the page which gets created using a ManageBrick?
Rather than a separate menu-item or button on the overview page, I'd like a "create" button on the list overview of available tickets.
And while thinking about it, would be even better/more in the spotlight if this could be added on top of the list instead (similar to the "actions" in the iTop backend)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes totally, but not as easily as with the backoffice menu API:
* Create a TWIG template that extends the template of the ManageBrick
* Overload the pMainHeaderActions block for example to add your markup
* In the portal XML configuration, specify for this ManageBrick instance (eg. ongoing-tickets-for-portal-user) the TWIG template to use in //brick[@id="ongoing-tickets-for-portal-user"]/templates/template[@id="page"]. See full XML documentation here.
Hope this helps,
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This doesn't work properly for ManageBrick, does it?
I'm under the impression that through the ManageBrickController::GetPageTemplateFromDisplayMode() method a hardcoded path is retrieved from the ManageBrick ( const ENUM_PAGE_TEMPLATE_PATH_TABLE = 'itop-portal-base/portal/templates/bricks/manage/layout-table.html.twig'; ) .
But that twig file refers to the original layout.html.twig, not the redefined one?
Is there an elegant solution or should I extend the ManageBrick as a workaround?
Last edit: Jeffrey Bostoen 2022-06-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh damn... This is indeed a regression that was introduced in iTop 2.5 with the different display types... 😥
The overloading of templates for this brick is no longer possible, sorry.
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes the brick should be fixed indeed, but I'm not sure which approach will should take without making its XML definition evolve.
//brick/templates/template[@id="page"] is supposed to overload the global brick page template (datamodels/2.x/itop-portal-base/portal/templates/bricks/manage/layout.html.twig), but in the case of the ManageBrick it can have several display modes (list, pie, bar), each of these having their own TWIG template.
So my proposal would be :
Solution 1 - Best proposition
In a PR restore overload of the whole brick template
Do it so the display mode templates extends either the default or the specified template. i'm not sure it's possible though as it would mean having a variable as the parent template.
Ultimately each display mode should have a template option so we can overload them, but that a whole different matter
Solution 2 - Not great but can help
In a PR restore overload of the whole brick template
Don't do anything else, but that means that the overloaded tempalte can have only 1 display mode. This can be acceptable as it will be only affecting the desired bricks instance.
Any thoughts?
Last edit: Guillaume Lajarige 2022-10-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to add a "create" button at the bottom of the page which gets created using a ManageBrick?
Rather than a separate menu-item or button on the overview page, I'd like a "create" button on the list overview of available tickets.
And while thinking about it, would be even better/more in the spotlight if this could be added on top of the list instead (similar to the "actions" in the iTop backend)
Hello Jeffrey,
Yes totally, but not as easily as with the backoffice menu API:
* Create a TWIG template that extends the template of the ManageBrick
* Overload the
pMainHeaderActionsblock for example to add your markup* In the portal XML configuration, specify for this ManageBrick instance (eg. ongoing-tickets-for-portal-user) the TWIG template to use in
//brick[@id="ongoing-tickets-for-portal-user"]/templates/template[@id="page"]. See full XML documentation here.Hope this helps,
Guillaume
Thanks for the hint, I'll look into this one!
This doesn't work properly for ManageBrick, does it?
I'm under the impression that through the
ManageBrickController::GetPageTemplateFromDisplayMode()method a hardcoded path is retrieved from the ManageBrick (const ENUM_PAGE_TEMPLATE_PATH_TABLE = 'itop-portal-base/portal/templates/bricks/manage/layout-table.html.twig';) .But that twig file refers to the original layout.html.twig, not the redefined one?
Is there an elegant solution or should I extend the ManageBrick as a workaround?
Last edit: Jeffrey Bostoen 2022-06-20
Oh damn... This is indeed a regression that was introduced in iTop 2.5 with the different display types... 😥
The overloading of templates for this brick is no longer possible, sorry.
Guillaume
So what would be the best way to go forward?
Adjsut the existing ManageBrick, perhaps if I get to it, create a pull request?
Or just extend the ManageBrick or (probably way shorter) create a UI hack?
IMHO, the ManageBrick should be fixed.
Jeffrey did create a ticket : [#2079]
Related
Tickets: #2079
Yes the brick should be fixed indeed, but I'm not sure which approach will should take without making its XML definition evolve.
//brick/templates/template[@id="page"]is supposed to overload the global brick page template (datamodels/2.x/itop-portal-base/portal/templates/bricks/manage/layout.html.twig), but in the case of the ManageBrick it can have several display modes (list, pie, bar), each of these having their own TWIG template.So my proposal would be :
Solution 1 - Best proposition
In a PR restore overload of the whole brick template
Do it so the display mode templates extends either the default or the specified template. i'm not sure it's possible though as it would mean having a variable as the parent template.
Ultimately each display mode should have a template option so we can overload them, but that a whole different matter
Solution 2 - Not great but can help
In a PR restore overload of the whole brick template
Don't do anything else, but that means that the overloaded tempalte can have only 1 display mode. This can be acceptable as it will be only affecting the desired bricks instance.
Any thoughts?
Last edit: Guillaume Lajarige 2022-10-23
I don't have a real preference to be honest, just a resolution for the use-case.
A separate feature request to simply enable a "create" button here would also be great.
What would be the best way for a fast and proper solution to this?
It's a bit overkill IMHO to have a separate button for this in a portal, especially if there are already a lot of other buttons as well.