iTop

iTop copied to clipboard

This is a discussion with @dflaven about the possibility to let extensions add new types of ZList to be used if that extension creates a new type of presentation of the objects. I saw it is supported by MetaModel class under RegisterZList to register new types: Standard attribute lists

The only problem is that the setup compiler only compiles some predefined ZLists. I already made some changes to that, but it needs to be tested and reviewed by @Combodo.

Any update?

Since it is too late to integrate this properly to the 2.7, I think that we will not work on your PR until we have released the 2.7.

Okay not work, but can someone give any actual feedback?

Actually I like the idea of having more types of "Zlists" for many different use cases (tooltips, autocomplete...). However there is a method MetaModel::RegisterZList(...) which was supposed to be used for declaring new ZLists, so we'd better review its use (maybe obsolete the method) and check for the consequences of arbitrary ZLists before merging this PR.

As said in the initial description, the only problem currently is that the compiler only processes a few predefined items. And this PR is fixing that.

Hello @Hipska ,

We discussed this today with the R&D team. This indeed looks like a great idea to have more zlists and a way to define your own. However we might use a different approch, so I'm closing this PR and opening a new enhancement on the Combodo support portal (N°2783) so we can plan it and maybe have in iTop 2.8.

Feel free to open a ticket to the support, if you want the enhancement to be linked so you can be notified of its progress.

Guillaume

Hi, now that 3.0 is out and the referenced bug is planned for 3.1, this PR can maybe be reconsidered?

Hello, Indeed N°2783 isn't part of the 3.0.0 version. We have in mind a functionality to have "cards" on extkey hover (which would requires its own zlist or equivalent), and had a different design in mind... I'm setting this PR to be reviewed again so we can discuss about this again.

Great to hear this!

In the meantime, I resolved the conflicts..

Discussed today in functional review, everybody seems opened to it but:

• Discussion must take place within the dev team to choose what would be the best implementation for this as it is creating a new extension point for the framework. Will try to make it happen before June.
• No bandwidth for this internally for iTop 3.1, so if you (@Hipska ) feels like discussing about our future proposition and finishing the implementation it will be consider.

Okay, what exactly are you expecting from me in that case? For me the PR is a finished implementation that works..

Okay, what exactly are you expecting from me in that case? For me the PR is a finished implementation that works..

[...] Discussion must take place within the dev team to choose what would be the best implementation [...] Will try to make it happen before June.

Discussion planned for Thursday

Going forward with this, still some under laying questions that will be discussed monday or tuesday. Will do an update here then.

Hello Thomas,

Discussion took place and decision was made about how we would like this to be implemented. This is not part of the roadmap yet so I don't know if it will ever be done but I'll put the specs below in case you want to push the PR forward.

Collection

• Custom zlists must be defined under the /itop_design/classes/class/presentation/customs which will contain zlists brought by customizations (extensions, Designer, ...)
• This collection node must be added empty to all standard DM classes
• This collection node must be added empty by the compiler on XML datamodel files during the version upgrade (see iTopDesignFormat::From30To31())

Definition of the zlist

• Each custom zlist will be represented by a <custom id="ZLIST_ID">[...]</custom> node
• The node must contain the same XML structure as other zlists (no particular test to do at compile time)
• Custom zlist can (optional) expose a description of their purpose so it will be displayed in the Designer as they will be no specific UI display (nothing to there for you Thomas, just to explain why it's in the example below)

Implementation

• Compiler should append custom zlist to the standard ones (= same PHP structure)
• Compiler should throw an exception if a custom zlist has the same name (ID) as a standard one (need for explicit ID will be added in the documentation)
• MetaModel::GetZListItems() will be used to retrieve both standard and custom zlists. If a custom zlist does not exist, it will return an empty array as it already does.

Example

<itop_design>
    <classes>
        <class id="UserRequest">
            <presentation>
                <details>[...]</details>
                <list>[...</list>
                [...]
                <custom_presentations>
                    <custom_presentation id="webhook-action-slack">
                        <items>
                            <item id="caller_id">
                                <rank>10</rank>
                            </item>
                            <item id="org_id">
                                <rank>20</rank>
                            </item>
                        </items>
                    </custom_presentation>
                </custom_presentations>
            </presentation>
        </class>
        <class id="Incident">
            <presentation>
                <custom_presentations>
                    <custom_presentation id="webhook-action-slack">
                        <items>
                            <item id="caller_id">
                                <rank>10</rank>
                            </item>
                        </items>
                    </custom_presentation>
                </custom_presentations>
            </presentation>
        </class>
    </classes>
    <meta>
        <presentation>
            <custom_presentations>
                <custom_presentation id="webhook-action-slack">
                    <description><![CDATA[Will be used by the "Slack notification" Action to display the corresponding attributes in the Slack message. Refer to the "Webhooks integration" extension documentation for more information.]]></description>
                </custom_presentation>
            </custom_presentations>
        </presentation>
    </meta>
</itop_design>

PS: Please let me know if you want to go forward with that or not so I can move the PR to "pending contributor" or close it, thanks.

You can move it to Pending, I will close if I give up. Thanks for the detailed requirements, will need to have a look at it when I have some time..

Thanks. I think it is really close to what you already done.

While looking into it, I don't think customs is a correct naming as that means something totally different (douane).

Thanks Hipska, you're right ! I'm setting this PR to be reviewed in the technical meeting today so that we can update our specs :)

Can't we just do this?

<presentation>
    <details/>
    <search/>
    <list/>
    <custom id="webhook-action-slack"><items/></custom>
    <custom id="foobar"><items/></custom>
</presentation>

Hello Thomas,

Generally, we keep node collections (items with an ID, eg. <custom id="abc">) in a container node (<customs>). I understand the "customs" word is ambiguous, could you suggest an alternative? 😁

Thanks

Yeah, I know it is usually done in a container node, but this way is perfectly valid xml and makes all sub-nodes of <presentation> have the exact same structure.

What about <custom_presentation> or <custom_lists>?

Yeah, I know it is usually done in a container node, but this way is perfectly valid xml and makes all sub-nodes of <presentation> have the exact same structure.

What about <custom_presentation> or <custom_lists>?

I'll discuss it with the team and Romain next tuesday when he'll come back. He is very picky about XML 😁

Just discussed with Romain, we are ok with

<presentation>
  <details/>
  <search/>
  <list/>
  <custom_presentations>
    <custom_presentation id="slack">
      ...
    </custom_presentation>
  </custom_presentations>
</presentation>

Hello Thomas, any update? If you need some info from us please let me know, if it's lack of time on your end we understand.

Lack of time indeed, don’t have much time to work on these kind of projects lately.

Closing PR as Thomas lacks time and we need to move forward with this. See #389