Version 8 Shared Vision Templates

Pardon me if this is spelled somewhere and I missed it:

I’m staging an upgrade server and noticed that shared Vision templates are now in a different place with a different path? I have to update the path in order to edit the shared-template - is this a known issue or am I missing something?

1 Like

You shouldn’t need to update anything for things to keep working - it should have happened automatically.
Briefly, on upgrade from 7.9 to 8.0 we removed the old truly global project and replaced it with a new regular project that is called “global”. That “global” project is marked as inheritable and all of your existing projects will have it set as the parent - which, in the new inheritance model, means pretty much the same as what having it be truly global meant before.

You will have to open the global project to edit those templates now, though - they show up as “inherited” resources in any child projects, which cannot be directly edited (although they can be overridden).

See the upgrade guide for some more info: https://docs.inductiveautomation.com/display/DOC80/Ignition+8+Upgrade+Guide#Ignition8UpgradeGuide-ProjectInheritance&“global”upgradelogic

1 Like

UGH… :rage:
So what is the date range for LTS 7.9.x?

7.9 is LTS until 10/12/21 - five years from initial release date.
7.9.11 is expected to be out in May.

<snark> Will LTS 8.1 be released in time for that? </snark>

Seriously, though, y’all might want to consider factoring in the release of the following LTS. Something like “Five years from initial release, but not less than three years from initial release of the following LTS”, perhaps.

Hmmm. Why the rage? People editing shared resources (scripts!) causing restarts across all projects is the bane of large multi-project installs. The new architecture is a huge win, especially with the ability to push what used to be shared scripts for tag events into their own isolated gateway scripting project.

The only thing I’m disappointed about is the lack of multiple inheritance. :cry:

Scripts I am fine with, it is the templates that will drive me mad.
I guess I will just have to keep 2 designer sessions open at the same time…

Consider developing shared templates in the project that initially uses them. Or initially needs updates to them (with an override). Then push that resource to the parent project when it is stable and/or suitable for use with the other leaf projects.

2 Likes

Short answer: Yes, absolutely.

Longer answer: the delay between 7.9 and 8.0 was longer than usual…because we also changed a lot more than usual. We incremented the “major” version for a reason. 8.0 to 8.1 won’t have the same kind of fundamental changes - more new features and lots of improvements to existing ones.

@m.currier we’ve derailed this thread a bit, but I just want to explicitly ask - did you have to update the path used to use your existing shared templates, or was that done for you? If “shared” templates in 7.9 weren’t showing up in 8.0, then that’s a bug we need to fix. If you weren’t able to edit them due to the inheritance changes I mentioned above, then everything is working as intended.

Initially the SharedTemplates are disabled/grayed [in the project-tree] in any non-global project. If I try to edit the shared template from that instance it errors. If I change the path from [shared]blibidy to SharedTemplate/blibidy I can then edit it it locally (and it’s no longer disabled in the tree). Two questions:

  1. Is this expected behavior? i.e. a new workflow…
  2. Does changing the path break the connection to the global/shared template?

So, it’s important to understand what the new inheritance system actually implies. There are two separate projects in play, after an upgrade:
global - where previously “global” resources lived. This defines a set of resources (including shared templates, etc)
<yourproject> - which inherits from the global project. Those inherited resources act as if they’re actually present in <yourproject> - but they cannot be edited, because they’re not actually there. If you want to make modifications, you have two options:

  1. Right click the ‘greyed out’ resource to override it. This creates a copy of the parent’s resource definition, only this copy is actually inside your project, meaning you can edit it. The downside to doing this often is that you aren’t changing things in a “global” way.
  2. Open the global project and make your edits there. Then, the next time you pull in changes in <yourproject>, you’ll get an updated inherited resource. It’s still not actually in <yourproject>, but you can use it as if it was.

It’s a different way to think about inheritance from what we had before, but it’s incredibly more powerful and flexible.

I’ll make a note to have someone double check that template upgrading is working as expected, but so far it does appear that it is.

2 Likes

I must be missing something here…

Tags aren’t available in the global project on either my dev machine or the production server… How do you utilize UDTs in shared-templates? Not to mention pulling live-data for testing - which is a huge benefit…

Does your global project have a tag provider set? You should still have access to all tags - they’re a truly global resource, unlike projects.

I have a similar question regarding templates when upgrading to Ignition 8, looking like the same issue that m.currier had to start this thread…

After upgrading to Ignition 8, when i double click on a template (that we know is stored in the inheritable “global” project), it tells me the template doesn’t exist. In order to override the template or simply open the template to debug a problem, I have to change the path from “[shared]” prefix to “SharedTemplates/” prefix. The templates seem to operate correctly without doing this, but the ability to open the template from it’s instance would be nice without having to manually edit the template path whenever you have a scenario that requires debug or overrides.

The upgrade guide says the following:
“The vision module will automatically convert a template path like “[shared]MyTemplate” as “SharedTemplates/MyTemplate” so that no further action is needed.”

Is this statement still true, or will we always need to change the path prefix in order for this functionality to work?