VIVO-1666: Adding a new listviewconfig to PropertyConfig.n3 requires a rebuild of VIVO

[chenejac]

Don Elsborg (Migrated from VIVO-1666) said:

When we need to add a new custom listview config or modify an existing one, the entire tdbconfig database needs to be destroyed such that it will re-read the PropertyConfig.n3 file because it's in the firsttime directory.

An example is that we want to create a new config specific for  TeacherRoles and Honors/Awards. To do this we also want to modify the config for participant - [https://github.com/vivo-project/VIVO/blob/develop/home/src/main/resources/rdf/display/firsttime/PropertyConfig.n3#L1910] such that it won't display to the public. The only way to do this AND preserve our configuration is to rebuild the tdbconfig.  We would like to have a couple of improvements to this process.

1. Allow this file to be read everytime and have the tdbconfig database refresh if there are changes.
2. Allow a method to manifest the faux properties to a physical file such that it can be placed in the appropriate VIVO build directory and checked into version control.

[chenejac]

Brian Lowe said:

It sounds as if one approach for your use case would be to move PropertyConfig.n3 from display/firsttime to display/everytime in your third tier (probably retaining an empty file at the original location so it will override the default).  Then you can manage all of your changes on the filesystem and they will be reloaded each time VIVO restarts.  This only works if all of your changes are via editing the file and there isn't a need also to make changes via the GUI.

Keep in mind also that the faux property contexts and configurations can be defined in any file that is added to the display model – there's nothing magical about the file named PropertyConfig.n3.  So if you're only adding something new you can just put a new file under everytime and not have to wipe out the TDB database.

[chenejac]

Don Elsborg said:

Thanks Brian. I've created our own version of fisPropertyConfig.n3 in the everytime directory of the 3rd tier. So that's handy for new customization's.

Questions/Issues still are:

• How can I change a default setting in the shipped PropertyConfig.n3 file without rebuilding? I can move the PropertyConfig.n3 file to everytime,  it seems as if I'll still need to rebuild if I change something like a display setting.
• I'd like to see if we can develop a way to deprecate the firsttime vs. everytime vs. filegraph structures. This has been a thorn in my side for a while when I have to customize. It should be possible to allow GUI editing of a property, then have the gui save it the changes both to the tdbconfig store AND the filesystem such that we can check it into version control.