SCOS Database Check

[pasetti]

Consider the following scenario:

• The user loads version 1.0 of the SCOS database and uses to create a large number of models
• Each model contains references to SCOS database items; the references appear in the model as red hyperlinks
• Some time later, the user receives an update of the database (release 1.1) and he loads it in the editor
• The change from version 1.0 to version 1.1 does not necessarily invalidate all models (models which only reference database items which remained unchanged in the transition from release 1.0 to release 1.1 are still valid)
• In order to identify models which are no longer valid, the user should load all models in the editor and inspect them (models where database links appear in black font are those which are no longer valid)

Since the scenario outlined above will occur often, I would like to ask whether it would be possible to add a function in the editor such that a user can select one of the currently loaded databases and then ask the editor to check all his models and to list those which contain links which are not valid with the selected database. This would be convenient because the user would then only need to load and update the models which appear in the list.

[Tomas-M]

Just a point to note, if the user has SCOS database version 1.0 and creates models using this version, then the models will reference this version 1.0 and adding new SCOS version (1.1) will not invalidate any model. All existing models will be saved with the setting to use version 1.0 which will still be available in the database.

Another point to mention, if user uses the autocomplete feature for example in a note of Final node, there is no red hyperlink visible at all.

These are not objections, I am just noting down some points.

If we want the newly proposed feature, the user should select one of the SCOS databases, and then it will have to go through all saved models and it will have to find out

• which words on the diagram are autocompleted using the SCOS version which was saved with the diagram
• which of those words are no longer autocompleted using the new (given) SCOS database version anymore

Then a result should be presented to the user somehow, where he can find which saved document has words which won't be autocompleted anymore if the given db version is selected on them.

Then the user will need to open them one by one manually, select the new database, and then fix the autocompletions.

hm. Will think about it

[pasetti]

Just a point to note, if the user has SCOS database version 1.0 and creates models using this version, then the models will reference this version 1.0 and adding new SCOS version (1.1) will not invalidate any model. All existing models will be saved with the setting to use version 1.0 which will still be available in the database.

Yes. This is understood (and it is a good behaviour).

Another point to mention, if user uses the autocomplete feature for example in a note of Final node, there is no red hyperlink visible at all.

Yes, this is also understood.

Then a result should be presented to the user somehow, where he can find which saved document has words which won't be autocompleted anymore if the given db version is selected on them.

This is indeed what we need. The list of models with no-longer-autocompleted items could be just a csv file or whatever is most convenient.

Then the user will need to open them one by one manually, select the new database, and then fix the autocompletions.

This is understood and inevitable (only a human user can update the autocompletion links which are no longer valid).

[Tomas-M]

We can provide the user with a list of affected models, and put an "open" link to each which would open the document on a new tab, so the user can edit it, save it, close the tab, and return back to the list to open another.

Is it sufficient to just identify models which are affected, or should we provide also the information where the "misbehaving" autocomplete is located? (eg. list of nodes) ... that would be a bit harder

[pasetti]

We can provide the user with a list of affected models, and put an "open" link to each which would open the document on a new tab, so the user can edit it, save it, close the tab, and return back to the list to open another.

That would be a very good solution. Will it be possible for the user to download this list? This is not essential but might be useful if the user needs an input to produce a report with a list of non-compliant models.

Is it sufficient to just identify models which are affected, or should we provide also the information where the "misbehaving" autocomplete is located? (eg. list of nodes) ... that would be a bit harder

I am not sure about this point. The user will in any case have to open each affected model to modify it manually. In the case of invalid links in the action and guard descriptions and in the floating notes, he will immediately see where the problem is because he will see links which are not high-lighted in red. The only problem is invalid links in the notes of action nodes which are not high-lighted.

If it is not too difficult, we should provide this. Otherwise, users can live without it.

[Tomas-M]

Please test this https://github.com/pnp-software/fcp-editor/commit/aa0354eb73cbdfdb9a5591c1d5a474759b9f59e2 I need to improve UI a little bit to fix some scrolling issues etc, but the core functionality should be ready.

[Tomas-M]

You will find the functionality under menu > Actions > scroll to bottom

[pasetti]

I have pulled the update from the Test branch and I have tested on localhost. The UI looks fine to me but I think that the check does not yet work in full. I have done the following steps:

• I have loaded two databases (database A and database B)
• I have created two models M1 and M2 with database A and one model M3 with database B
• I have gone to the SCOS version check and selected a check against database A. I would expect model M3 to show up (because it was created with database B) but, in fact, nothing is shown
• I have gone again to the SCOS version check and selected a check against database B. I would expect models M1 and M2 to show up (because they were created with database B) but, in fact, only model M1 is shown

I have also done a second check which only requires one database:

• I have created model M1 with database A. Model M1 contains one autocompleted entry which is shown in red font.
• I have gone to the SCOS version check and selected a check against database A. The check replies that all saved models are compatible with the selected database. This is as expected.
• I have modified model M1 to introduce a spelling error in the autocompleted entry. The autocompleted entry now appears in black font (it is no longer recognized)
• I have gone again to the SCOS version check and selected a check against database A. The check replies again that all saved models are compatible with the selected database. I believe that this is incorrect because it should reply that there is a model with an incompatible autocompletion entry

[Tomas-M]

I think that our understanding of how the check should work differs. So I will explain how the check actually works, and you can let me know if this is what you want, or if the check should be made in a different way. So currently it works this way:

• each model has configured a SCOS database it uses. For example, model M1 can be saved with database A in settings, model M2 can be saved with database B in settings.
• when you perform the check, it goes through all models, and it reads them.
• for each model (saved file), it creates a list of currently used autocompletions. So in our example, it "sees" all autocompletions made in model M1 which are valid for database A, and it "sees" all autocompletions made in model M2 which are valid for database B.
• then, once it has collected all valid autocompleted strings, it checks against the CHECK database you selected to see which of the strings are still valid in the CHECK database.
• finally, it reports files (models) where it found an autocompleted string which does not appear in CHECK database.

So, for your example, if you make a spelling error in model M1, the text is no longer a valid autocompleted entry. Thus it is not considered during the test. Because only valid entries in model M1 are checked against the CHECK database.

So a possible "incompatibility" could happen only if the autocompleted text (eg. #TC(1,2):something) is valid within the saved file which is checked, but no longer valid in the CHECK database you selected in the Actions.

I hope you understand what I mean. Let me know please if this is what you want.

[pasetti]

Yes, it does seem that we have a different understanding of how this check should be carried out. Let me explain more precisely what I had in mind.

In order to define what should be done by the editor, I need to define the concept of a "SCOS Reference": this is a string in a text field of a model which has one of the following forms: "#TC(...", or "#TM(,...", or "#HK:...", or "#EID:...", or "TMPAR:...", or "TCPAR:..." . Thus, for instance, a SCOS Reference String could be: "TC(1,2):SomeName" or it could be: "HK:SomeHkName".

Let us now suppose that a user performs a check against database CHECK. Here is what I would expect the editor to do:

• The editor reads all models belonging to the user
• For each model, the editor checks whether there are text fields which contains SCOS References in the text fields of the model and then it checks whether they match an entry in database CHECK
• If there are SCOS References which do not match any entry in database CHECK, the editor declare the model to be not compatible with database CHECK
• If, instead, all SCOS References match entries in database CHECK, the editor declares the model to be compatible with database check
• After processing all models, the editor provides the list of incompatible models

Would something like this be feasible? If it is very complicated to do, we should not do it because the check can also be done offline after the user has downloaded the models for further processing.

I hope the intention is now clearer. Let me know if there are still open points.

[Tomas-M]

I can see. I was trying to avoid hardcoding of "SCOS Reference" in the code. No problem at all, I will make it the way you like.

[Tomas-M]

Please test the test branch now. Thank you

[pasetti]

I have tested the branch on my localhost installation and it looks fine...