added option to add additional items to the view-overview

[trombastic]

this is usefull to add links to other Django Apps ot PyScada Plugins

[clavay]

Why did you add this ?

[clavay]

Ok, I understood, for a dummy view defined in the settings.py :

• If link_title is set, it redirect to a view (why let this option if this is the classic way to add a view from the admin ?)
• If link_title is not set, it redirect to a local link on the server but you define an URL to catch it (and redirect to the index view function), so it will not redirect to your other plugin or django app if the those urls.py is loaded after the hmi/urls.py
• It is not possible to add an external link (ex: https://pyscada.readthedocs.io/)
• It could be better to manage this in the admin, because changing the settings.py needs to restart gunicorn.

[trombastic]

If link_title is not set, it redirect to a local link on the server but you define an URL to catch it (and redirect to the index view function), so it will not redirect to your other plugin or django app if the those urls.py is loaded after the hmi/urls.py

I'm not sure what you mean with this, at least in my case (and I admit, that I didn't think to much about other cases were one would like to add links to the view-overview) this is not a problem, but i see that there is a chance that the user may set a custom link with this new way which overrides a internal url of pyscada itself or a pyscada-plugin

It is not possible to add an external link (ex: https://pyscada.readthedocs.io/)

this is True, to have this option more changes to the view-overview template will be necessary, for my case where I use nginx as reverse proxy for the other apps, this is not a problem, but i see your point.

It could be better to manage this in the admin, because changing the settings.py needs to restart gunicorn.

In my opinion the need to restart gunicorn is not a problem, my intention was to use it not dynamically, but if we decide later to have it as dedicated model then it would be possible to keep more or less the same logic.

When I implemented this I was not sure what others may have build on top of the view-overview template and therefore tried to keep the changes to that minimal. I agree with you, that if we want to add the ability to add links more freely (e.g. external links) or allow dynamic changes, this would be not the right way. But for links in the same Namespace as Pyscada (same Top Level URL) hijacking the index Funktion in views is the only good option I see. There would be the other option to have a special URL for that (e.g. https://TOP_LEVEL_URL/external/NEW_NAMESPACE) that I don't like so much because this would make those urls harder to memories.

[clavay]

I'm not sure what you mean with this, at least in my case (and I admit, that I didn't think to much about other cases were one would like to add links to the view-overview) this is not a problem, but i see that there is a chance that the user may set a custom link with this new way which overrides a internal url of pyscada itself or a pyscada-plugin

For example, this config add a view that redirect to https://127.0.0.1/test/.

OVERVIEW_ADDITIONAL_LINKS = [
{
"title": "test",
"link_title": False,
"link_url": "test",
"description": "desc",
}
]

As this url is not defined in nginx as a location and no plugin is catching this path before the hmi.urls.py, the path you defined in hmi.urls.py redirect this link to view-overview with the link https://127.0.0.1/test/ (the index view).

########

this is True, to have this option more changes to the view-overview template will be necessary, for my case where I use nginx as reverse proxy for the other apps, this is not a problem, but i see your point.

This should do the trick :

        {% if view.visible %}
            {% with link_url=view.link_url %}
            {% if view.link_title %}
                {% url 'main-view' view.link_title as link_url %}
            {% elif "http" not in link_url %}
                {% url 'view-overview-link' view.link_url as link_url %}
            {% endif %}
        <div class="col-sm-3">
        <div class="panel panel-default">
                <div class="panel-heading">
                    <h3 class="panel-title"><a href="{{ link_url }}" target="{{ link_target }}" >{{ view.title }}</a></h3>
                </div>
                <div class="panel-body">
                {% if view.logo %}
                <a href="{{ link_url }}" class="thumbnail" target="{{ link_target }}" ><img src="{{ view.logo.url }}" alt="{{ view.description }}"  width="100%" ></a>
                {% else %}
                <a href="{{ link_url }}" class="thumbnail" target="{{ link_target }}" ><p style="min-height: 120px;">{{ view.description }}</p></a>
                {% endif %}
            </div>
           </div>
        </div>
            {% endwith %}
        {% endif %}

########

In my opinion the need to restart gunicorn is not a problem, my intention was to use it not dynamically, but if we decide later to have it as dedicated model then it would be possible to keep more or less the same logic.

When I implemented this I was not sure what others may have build on top of the view-overview template and therefore tried to keep the changes to that minimal. I agree with you, that if we want to add the ability to add links more freely (e.g. external links) or allow dynamic changes, this would be not the right way. But for links in the same Namespace as Pyscada (same Top Level URL) hijacking the index Funktion in views is the only good option I see. There would be the other option to have a special URL for that (e.g. https://TOP_LEVEL_URL/external/NEW_NAMESPACE) that I don't like so much because this would make those urls harder to memories.

I think it should be easy from the admin to:

• add link in the view-overview (internal or external)
• choose what is the default page after login (view-overview or a choosen view) for a specific group
• give access to some views, view-overview, widgets without login
• define various view-overview
• be able to change the template used for a view or for the view-overview (using a theme mechanism, as I tried to implement for the views)
• add a theme with options (color, logo...) with a plugin (what I did for the views, but I think it may be done better)

What do you think ?

[trombastic]

as a first step I will try your code Suggestion for the view-overview template