8.0.0 (b2019040718)
As stated.
I’m trying to define colours and styles as client tags in a global base project, but these client tags aren’t inherited. I can’t copy client tags between projects either
8.0.0 (b2019040718)
As stated.
I’m trying to define colours and styles as client tags in a global base project, but these client tags aren’t inherited. I can’t copy client tags between projects either
I’m trying to replicate this and failing (using an April 17 build of 8.0.1 fwiw)
I made a parent project and defined a client memory tag in that project. Then I made an inherited project, opened it in the designer, and I see my parent’s client tag. I can drag that tag onto a Vision window, change its value, etc.
Can you try a more recent build and see if you still have that problem?
Kathy, I believe if you already have an inherited project created and make changes to the parent projects client tags the inherited resource is not updated in the inherited project. The inheritance only seems to work on the project creation.
Okay, thanks – I’ll test that out.
Just tried it out by disabling the client tag in the parent and that change appeared in the child project. I might need to have one of you work with support on how to recreate this, because I’m striking out.
(Just as a note, if you change a resource in the parent I wouldn’t expect that change to show up in a child project until you update the project, unless it’s a resource that’s completely Gateway based, like running a Named Query.)
I tested that in my gateway and the change did not merge into my inherited project. I created a test project, verified that the client tags were inherited correctly, disabled one of the inherited client tags in the parent project, and merged any changes in the gateway and there was no change in the client tag status. It is the same behavior if I add a client tag to the parent project. It is not created if I merge gateway changes in the inherited project. I am running the 8.0.1 nightly from 4/11.
Looks like we merged in a ticket titled “Client Tag subscription fixes” on 4/12, so I would try again with something from 4/13 or later.
I am not sure how the client tag inheritance is supposed to work. I installed the 8.0.2 rc today and decided to try it out.
For projects that were created during the beta it doesn’t seem to work at all.
For newer projects it kind of works. If you create a client tag in the parent project it eventually shows up in the child - this isn’t as quick as saving the parent and merging into the child. If you delete the tag from the parent it remains in the child which leads me to believe it is not true inheritance, but rather a copy.
It is not really a big deal for us at the moment, but I am curious how it should work.
Things were changing rapidly during the beta – don’t count on beta projects working now.
When you inherit a resource, you are in fact making a copy of it in the child project. I’d suggest looking at inheritance more at the project level than the resource level. If you don’t “override” a parent resource, you “inherit”. If you do override it, you see the override, at least until you delete the override, and then you see the parent again. If you add a new resource to the child, you see the new resource until you delete it, and then you see no resource.
What is the best way to rebuild a project so that it will work with correctly? Can we just export and import the whole project or do we need to pluck out all the individual pieces?
For the client tag inheritance, the ones that do get inherited never have they gray/inherited appearance. When they first show up, they have black text and there is no option to override. They don’t seem to work like the templates/windows, but I am not sure if that is the intention.
IIRC, client tags are treated as a single resource. All or nothing inheritance, not individual tags.
I like the inheritance idea and we set to work with it. However it becomes it bit tedious when exporting and importing child projects. Because with the export all the inherited resources are included, but when importing they are cause for errors because the inherited resources cannot be overridden.
Would it not be better to (be able to) exclude inherited resources from the export?
In my opinion what would be better, is if there was the option to export all inherited projects within the same backup as the main project. That way, to restore a project, you can simply restore the one main backup and it would restore all the projects required. Of course, if this is not desired, there should also be an option to exclude particular inherited projects.
Consider version control:
Level 1:
We have some standard utility functions stored in our IgnitionStd project
Level 2:
We inherit these functions and add project-wide standards and templates
Level 3: We create 15 projects inheriting from level 1 and 2 for 15 standalone sites.
We would like version control on each level, so as to be able to determine who, where and when changes were made…
Therefore I like the current project export with separate version control on all the resources, but I’m looking for a way to export only the current project…