Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-8370

Display Similarity Factory in use in Schema-Browser

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.3, 7.0
    • Component/s: Admin UI
    • Labels:

      Description

      Perhaps the Admin UI Schema browser should also display which <similarity> that is in use in schema, like it does per-field.

      1. screenshot-1.png
        83 kB
        Jan Høydahl
      2. screenshot-2.png
        14 kB
        Jan Høydahl
      3. screenshot-3.png
        40 kB
        Jan Høydahl
      4. screenshot-4.png
        25 kB
        Jan Høydahl
      5. screenshot-5.png
        19 kB
        Jan Høydahl
      6. screenshot-6.png
        18 kB
        Jan Høydahl
      7. SOLR-8370.patch
        11 kB
        Jan Høydahl
      8. SOLR-8370.patch
        10 kB
        Jan Høydahl
      9. SOLR-8370.patch
        9 kB
        Jan Høydahl
      10. SOLR-8370.patch
        11 kB
        Jan Høydahl
      11. SOLR-8370.patch
        11 kB
        Jan Høydahl
      12. SOLR-8370.patch
        11 kB
        Jan Høydahl
      13. SOLR-8370.patch
        7 kB
        Jan Høydahl
      14. SOLR-8370.patch
        4 kB
        Jan Høydahl

        Activity

        Hide
        janhoy Jan Høydahl added a comment -

        First patch. Adds "similarity" to Luke response, and displays it below "id" in schema browser. In case of SchemaSimilarityFactory, we use a new toString method on PerFieldSimilarityWrapper, e.g.

        SchemaSimilarityFactory. Default: BM25(k1=1.2,b=0.75) 
        
        Show
        janhoy Jan Høydahl added a comment - First patch. Adds "similarity" to Luke response, and displays it below "id" in schema browser. In case of SchemaSimilarityFactory, we use a new toString method on PerFieldSimilarityWrapper, e.g. SchemaSimilarityFactory. Default: BM25(k1=1.2,b=0.75)
        Hide
        janhoy Jan Høydahl added a comment -

        Want to commit this soon, if no objections?

        Show
        janhoy Jan Høydahl added a comment - Want to commit this soon, if no objections?
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        No objections to the UI part.

        Show
        arafalov Alexandre Rafalovitch added a comment - No objections to the UI part.
        Hide
        janhoy Jan Høydahl added a comment -

        See screenshot for how it will look like

        Show
        janhoy Jan Høydahl added a comment - See screenshot for how it will look like
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        Hmm, on the second thought, that's a little overflowing.

        The way I understand it, vast majority of people will keep it at default, so all they need to see is minimal sign that it is default. And, perhaps, more information when it is not default. The API can be more explicit, of course.

        Maybe we don't need to display the full path if it is the default class anyway. I could also do some CSS to avoid it overflowing, but not for a couple of days.

        Show
        arafalov Alexandre Rafalovitch added a comment - Hmm, on the second thought, that's a little overflowing. The way I understand it, vast majority of people will keep it at default, so all they need to see is minimal sign that it is default. And, perhaps, more information when it is not default. The API can be more explicit, of course. Maybe we don't need to display the full path if it is the default class anyway. I could also do some CSS to avoid it overflowing, but not for a couple of days.
        Hide
        janhoy Jan Høydahl added a comment -

        Agree. New patch.

        • Display only toString, put abbreviated classname in toolTip
        • Added toString methods to SweetSpot and TFIDFSimilarity
        Show
        janhoy Jan Høydahl added a comment - Agree. New patch. Display only toString, put abbreviated classname in toolTip Added toString methods to SweetSpot and TFIDFSimilarity
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        Looks great. I like that it also makes people think about what they have.

        Just final clarification - this is the global schema-level similarity? Not per field one, right (we have that I think)? Because the "id" area is the global information area, just the way it looks now.

        Show
        arafalov Alexandre Rafalovitch added a comment - Looks great. I like that it also makes people think about what they have. Just final clarification - this is the global schema-level similarity? Not per field one, right (we have that I think)? Because the "id" area is the global information area, just the way it looks now.
        Hide
        janhoy Jan Høydahl added a comment -

        Yes, this is the global/default similarity defined on top-level. If you have fieldType-level similarities those will show up when viewing the field type.

        Show
        janhoy Jan Høydahl added a comment - Yes, this is the global/default similarity defined on top-level. If you have fieldType-level similarities those will show up when viewing the field type.
        Hide
        janhoy Jan Høydahl added a comment - - edited

        New patch.

        • Found out that the per-field similarity did not display correctly (old UI worked fine)
        • Added display of Similarity for both field, dynamic-field and field-type, with class-name in toolTip
        • The existing code (which did not display) displayed the global similarity class name for per-field. Fixed this
        • Refactored JS function param "field"->"name"
        • Added function to abbreviate package name in all printouts
        • Changed tooltip to ltYellow with thin border and moved closer
        Show
        janhoy Jan Høydahl added a comment - - edited New patch. Found out that the per-field similarity did not display correctly (old UI worked fine) Added display of Similarity for both field, dynamic-field and field-type, with class-name in toolTip The existing code (which did not display) displayed the global similarity class name for per-field. Fixed this Refactored JS function param "field"->"name" Added function to abbreviate package name in all printouts Changed tooltip to ltYellow with thin border and moved closer
        Hide
        janhoy Jan Høydahl added a comment -

        New patch

        • Moved change of SweetSpotSimilarity to LUCENE-7496 for separate discussion
        • Not changing PerFieldSimiliarityWrapper as it is a Lucene class and it was wrong to assume SchemaSimilarity and that get("") returns default impl. Instead, added the toString to the anonymous inner class of SchemaSimilarity
        • Skipped the toString for TFIDFSimilarity since I believe it will never be in use - we don't have a factory for it, it will be ClassicSimilarity...

        Think this should be good to go in now? Or do you see more changes needed?

        Show
        janhoy Jan Høydahl added a comment - New patch Moved change of SweetSpotSimilarity to LUCENE-7496 for separate discussion Not changing PerFieldSimiliarityWrapper as it is a Lucene class and it was wrong to assume SchemaSimilarity and that get("") returns default impl. Instead, added the toString to the anonymous inner class of SchemaSimilarity Skipped the toString for TFIDFSimilarity since I believe it will never be in use - we don't have a factory for it, it will be ClassicSimilarity... Think this should be good to go in now? Or do you see more changes needed?
        Hide
        janhoy Jan Høydahl added a comment -

        Plan to commit this tomorrow

        Show
        janhoy Jan Høydahl added a comment - Plan to commit this tomorrow
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        I've applied this patch and can see both global and field-local displays. However, the patch breaks for dynamic fields (e.g. author_s with techproducts example):

        Error: data.types[data.fields[name].type] is undefined
        getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:469:9
        $scope.refresh/</<@http://localhost:8983/solr/js/angular/controllers/schema.js:80:38
        ....
        

        I am not 100% sure I understand the similarity issues, so the following may not make sense. I am using the 3 examples from https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements (after fixing the syntax errors):

        • In the global similarity section, The tooltip seems to always say: o.a.s.search.similarities.SchemaSimilarityFactory$1 whatever similarity I configure. The field similarity tooltip seems correct.
        • I am not sure what Default means in "SchemaSimilarity. Default: DFR I(F)B3(900.0)" and "SchemaSimilarity. Default: BM25(k1=1.2,b=0.75)" They can't both (and should neither) be default. Was it supposed to mean "Global". In which case that may be better going into the title label, as the content in that section of UI will always be global/default.
        • The displayed summary of the Similarity parameters does not seem to quite match the definition. Specifically, the normalization value (H3) gets merged into previous/specific parameter (here B3). That may be correct though, I just don't know enough.
        Show
        arafalov Alexandre Rafalovitch added a comment - I've applied this patch and can see both global and field-local displays. However, the patch breaks for dynamic fields (e.g. author_s with techproducts example): Error: data.types[data.fields[name].type] is undefined getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:469:9 $scope.refresh/</<@http://localhost:8983/solr/js/angular/controllers/schema.js:80:38 .... I am not 100% sure I understand the similarity issues, so the following may not make sense. I am using the 3 examples from https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements (after fixing the syntax errors): In the global similarity section, The tooltip seems to always say: o.a.s.search.similarities.SchemaSimilarityFactory$1 whatever similarity I configure. The field similarity tooltip seems correct. I am not sure what Default means in "SchemaSimilarity. Default: DFR I(F)B3(900.0)" and "SchemaSimilarity. Default: BM25(k1=1.2,b=0.75)" They can't both (and should neither) be default. Was it supposed to mean "Global". In which case that may be better going into the title label, as the content in that section of UI will always be global/default. The displayed summary of the Similarity parameters does not seem to quite match the definition. Specifically, the normalization value (H3) gets merged into previous/specific parameter (here B3). That may be correct though, I just don't know enough.
        Hide
        janhoy Jan Høydahl added a comment -

        Thanks for the review.

        I'll look into the dynamic field issue and the tooltip.

        The SchemaSimilarity class uses the term Default about what Similarity it will use for a field that does not have an explicitly defined one. See https://lucene.apache.org/solr/6_2_1/solr-core/org/apache/solr/search/similarities/SchemaSimilarityFactory.html but it may be that "Global default" is a better wording?

        The displayed summary of the Similarity parameters does not seem to quite match the definition.

        I don't get this, examples? We simply print the toString() output of whatever class...

        Show
        janhoy Jan Høydahl added a comment - Thanks for the review. I'll look into the dynamic field issue and the tooltip. The SchemaSimilarity class uses the term Default about what Similarity it will use for a field that does not have an explicitly defined one. See https://lucene.apache.org/solr/6_2_1/solr-core/org/apache/solr/search/similarities/SchemaSimilarityFactory.html but it may be that "Global default" is a better wording? The displayed summary of the Similarity parameters does not seem to quite match the definition. I don't get this, examples? We simply print the toString() output of whatever class...
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        may be that "Global default "is a better wording?

        Global is what the documentation uses, so I would match that to keep it consistent. Visually, whatever is in that section is Global/Default, so it does not make sense to display it as part of variable part of the display (actual value).

        I don't get this, examples

        <similarity class="solr.DFRSimilarityFactory">
              <str name="normalization">H3</str>
              <str name="afterEffect">B</str>
              <str name="mu">900.0</str>
              <str name="basicModel">I(F)</str>
            </similarity>
        

        Outputs:

        DFR I(F)B3(900.0)
        
        Show
        arafalov Alexandre Rafalovitch added a comment - may be that "Global default "is a better wording? Global is what the documentation uses, so I would match that to keep it consistent. Visually, whatever is in that section is Global/Default, so it does not make sense to display it as part of variable part of the display (actual value). I don't get this, examples <similarity class="solr.DFRSimilarityFactory"> <str name="normalization">H3</str> <str name="afterEffect">B</str> <str name="mu">900.0</str> <str name="basicModel">I(F)</str> </similarity> Outputs: DFR I(F)B3(900.0)
        Hide
        janhoy Jan Høydahl added a comment -

        Ah, you better check the toString method of DFRSimilarity to dive into that. But that would be another JIRA...

        Show
        janhoy Jan Høydahl added a comment - Ah, you better check the toString method of DFRSimilarity to dive into that. But that would be another JIRA...
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        And looking at the code, there is some complex parameter normalization. So this may well be valid. Leave it to somebody with more clue/need to deal with that.

        Show
        arafalov Alexandre Rafalovitch added a comment - And looking at the code, there is some complex parameter normalization. So this may well be valid. Leave it to somebody with more clue/need to deal with that.
        Hide
        janhoy Jan Høydahl added a comment - - edited

        Looking at author_s, it is broken from Luke. The endpoint http://localhost:8983/solr/techproducts/admin/luke does not contain this dynamic field (but it contains address_s), neither does while http://localhost:8983/solr/techproducts/admin/luke?show=schema but it is listed as a copyDest.

        I'm not sure if Luke was supposed to bring it back as a field, but tell us that it is a dynField, or whether mergeIndexAndSchemaData(index, schema.schema); method in schema.js was supposed to find out that by itself, as it is now, it is that method that populates author_s but in a partial:true state... It also has a line

            display.partialState = is.field && !!data.fields[name].partial;
        

        which seems to set a variabel but do nothing further with it. So there may be some work in progress here that was never finalised? This also smells like a new JIRA, not part of this one...

        UPDATE: partialState is attempted used in schema.html but due to a typo, it does not work. I will fix that too (use display.partialState instead of just partialState. That will display a warning box "Because your Index is empty, we do not have enough Information about this Field".

        Show
        janhoy Jan Høydahl added a comment - - edited Looking at author_s, it is broken from Luke. The endpoint http://localhost:8983/solr/techproducts/admin/luke does not contain this dynamic field (but it contains address_s), neither does while http://localhost:8983/solr/techproducts/admin/luke?show=schema but it is listed as a copyDest. I'm not sure if Luke was supposed to bring it back as a field, but tell us that it is a dynField, or whether mergeIndexAndSchemaData(index, schema.schema); method in schema.js was supposed to find out that by itself, as it is now, it is that method that populates author_s but in a partial:true state... It also has a line display.partialState = is.field && !!data.fields[name].partial; which seems to set a variabel but do nothing further with it. So there may be some work in progress here that was never finalised? This also smells like a new JIRA, not part of this one... UPDATE : partialState is attempted used in schema.html but due to a typo, it does not work. I will fix that too (use display.partialState instead of just partialState . That will display a warning box "Because your Index is empty, we do not have enough Information about this Field".
        Hide
        janhoy Jan Høydahl added a comment -

        In the global similarity section, The tooltip seems to always say: o.a.s.search.similarities.SchemaSimilarityFactory$1 whatever similarity I configure. The field similarity tooltip seems correct.

        I tested with <similarity class="solr.ClassicSimilarityFactory"/> and it displays correctly the fieldName

        Show
        janhoy Jan Høydahl added a comment - In the global similarity section, The tooltip seems to always say: o.a.s.search.similarities.SchemaSimilarityFactory$1 whatever similarity I configure. The field similarity tooltip seems correct. I tested with <similarity class="solr.ClassicSimilarityFactory"/> and it displays correctly the fieldName
        Hide
        janhoy Jan Høydahl added a comment - - edited

        Alexandre, would you care to test the JS bug with a plain trunk version and see if you can reproduce without this patch, and file a JIRA if necessary? Forget this

        I'm changing wording from Default -> Global
        If the other issues are unrelated to this one, then are there more stuff to change for this JIRA?

        Show
        janhoy Jan Høydahl added a comment - - edited Alexandre, would you care to test the JS bug with a plain trunk version and see if you can reproduce without this patch, and file a JIRA if necessary? Forget this I'm changing wording from Default -> Global If the other issues are unrelated to this one, then are there more stuff to change for this JIRA?
        Hide
        janhoy Jan Høydahl added a comment - - edited

        New patch:

        • Fixed javaScript error msg when fetching similarity for a partialState field
        • Fixed display of warning message about incomplete info in partialState
        • Hidden empty FieldType label in partialState
        • Hidden Load Term Info button in partialState
        • Verified that author_s displays with full info once we index a document with author field, i.e.
          bin/post -c techproducts example/exampledocs/books.csv
          
        Show
        janhoy Jan Høydahl added a comment - - edited New patch: Fixed javaScript error msg when fetching similarity for a partialState field Fixed display of warning message about incomplete info in partialState Hidden empty FieldType label in partialState Hidden Load Term Info button in partialState Verified that author_s displays with full info once we index a document with author field, i.e. bin/post -c techproducts example/exampledocs/books.csv
        Hide
        janhoy Jan Høydahl added a comment -

        Planning to commit on thursday

        Show
        janhoy Jan Høydahl added a comment - Planning to commit on thursday
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        I am not sure if I am applying the correct patch, but I am still getting strange behavior from Luke handler that propagates all the way to the UI. Specifically, using the last example from: https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements

        The request http://localhost:8983/solr/techproducts/admin/luke?_=1476820097532&show=schema&wt=json returns:

        • The global similarity as:
              "similarity":{
                "className":"org.apache.solr.search.similarities.SchemaSimilarityFactory$1",
                "details":"SchemaSimilarity. Global: DFR I(F)B3(900.0)"},
          
        • And the type similarity for text_dfr as:
          "similarity":{
                    "className":"org.apache.lucene.search.similarities.DFRSimilarity",
                    "details":"DFR I(F)B3(900.0)"}},
          

        They should be the same as far as I can tell. And, when I said "Global", I meant that we don't need to say anything at all in the API, as it is clear from just the level of the Similarity key. I meant to change the Angular UI to say "Global similarity" instead of just "Similarity".

        Show
        arafalov Alexandre Rafalovitch added a comment - I am not sure if I am applying the correct patch, but I am still getting strange behavior from Luke handler that propagates all the way to the UI. Specifically, using the last example from: https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements The request http://localhost:8983/solr/techproducts/admin/luke?_=1476820097532&show=schema&wt=json returns: The global similarity as: "similarity":{ "className":"org.apache.solr.search.similarities.SchemaSimilarityFactory$1", "details":"SchemaSimilarity. Global: DFR I(F)B3(900.0)"}, And the type similarity for text_dfr as: "similarity":{ "className":"org.apache.lucene.search.similarities.DFRSimilarity", "details":"DFR I(F)B3(900.0)"}}, They should be the same as far as I can tell. And, when I said "Global", I meant that we don't need to say anything at all in the API, as it is clear from just the level of the Similarity key. I meant to change the Angular UI to say "Global similarity" instead of just "Similarity".
        Hide
        janhoy Jan Høydahl added a comment -

        They should be the same as far as I can tell.

        I disagree. It is an important distinction whether SchemaSimilarityFactory(PerFieldSimilarityWrapper), with a default of DFRSimilarityFactor, compared to if you explicitly set DFRSimilarityWrapper as the only global similarity without support for per-field. So the output is exactly as I wish That was why I think that "Default" was a reasonable lead text for what PerFieldSimilarityWrapper will use as default similarity for fields that don't have an explicit override.

        One option I was thinking about is to make SchemaSimilarityFactory's PerFieldSimilarityFactory a named class instead of an anonymous inner class:

        class SchemaFieldSimilarity extends PerFieldSimilarityWrapper { ... }
        

        Then the print from the global sim would instead be printing the name of the Similarity, not the factory:

            "similarity":{
              "className":"org.apache.solr.search.similarities.SchemaFieldSimilarity",
              "details":"SchemaFieldSimilarity. Default: DFR I(F)B3(900.0)"},
        

        Naming of this class could be discussed. SolrPerFieldSimilarity, SchemaSimilarity, SchemaFieldSimilarity, PerSchemaFieldSimilarityWrapper....

        Show
        janhoy Jan Høydahl added a comment - They should be the same as far as I can tell. I disagree. It is an important distinction whether SchemaSimilarityFactory(PerFieldSimilarityWrapper) , with a default of DFRSimilarityFactor , compared to if you explicitly set DFRSimilarityWrapper as the only global similarity without support for per-field. So the output is exactly as I wish That was why I think that "Default" was a reasonable lead text for what PerFieldSimilarityWrapper will use as default similarity for fields that don't have an explicit override. One option I was thinking about is to make SchemaSimilarityFactory's PerFieldSimilarityFactory a named class instead of an anonymous inner class: class SchemaFieldSimilarity extends PerFieldSimilarityWrapper { ... } Then the print from the global sim would instead be printing the name of the Similarity, not the factory: "similarity" :{ "className" : "org.apache.solr.search.similarities.SchemaFieldSimilarity" , "details" : "SchemaFieldSimilarity. Default: DFR I(F)B3(900.0)" }, Naming of this class could be discussed. SolrPerFieldSimilarity, SchemaSimilarity, SchemaFieldSimilarity, PerSchemaFieldSimilarityWrapper....
        Hide
        arafalov Alexandre Rafalovitch added a comment -

        Ok, I think my value as a sanity-checker is finished here If those things are distinct in your mind, I have no problem with them being distinct in API or visually. And perhaps, then, I was incorrect about Global and it is Implicit instead. The specific reference says:

        Each collection has one "global" Similarity, and by default Solr uses an implicit SchemaSimilarityFactory which allows individual field types to be configured with a "per-type" specific Similarity and implicitly uses BM25Similarity for any field type which does not have an explicit Similarity.
        

        I have no opinion on the naming as such.

        Show
        arafalov Alexandre Rafalovitch added a comment - Ok, I think my value as a sanity-checker is finished here If those things are distinct in your mind, I have no problem with them being distinct in API or visually. And perhaps, then, I was incorrect about Global and it is Implicit instead. The specific reference says: Each collection has one "global" Similarity, and by default Solr uses an implicit SchemaSimilarityFactory which allows individual field types to be configured with a "per-type" specific Similarity and implicitly uses BM25Similarity for any field type which does not have an explicit Similarity. I have no opinion on the naming as such.
        Hide
        janhoy Jan Høydahl added a comment -

        New patch. Final adjustments

        • Changed headline to "Global Similarity" and always black (active). The old grey color implied that you had to click on it to make it active in the right pane
        • Inner class SchemaSimilarity is no longer anonymous since we now display class name in UI. Chose name SchemaSimilarity which is a logical thing for the Factory to produce WIll display as o.a.s.search.similarities.SchemaSimilarityFactory$SchemaSimilarity
        • Changed back toString() wording for SchemaSimilarity from Global -> Default
        • Added Alexandre to CHANGES entry
        Show
        janhoy Jan Høydahl added a comment - New patch. Final adjustments Changed headline to "Global Similarity" and always black (active). The old grey color implied that you had to click on it to make it active in the right pane Inner class SchemaSimilarity is no longer anonymous since we now display class name in UI. Chose name SchemaSimilarity which is a logical thing for the Factory to produce WIll display as o.a.s.search.similarities.SchemaSimilarityFactory$SchemaSimilarity Changed back toString() wording for SchemaSimilarity from Global -> Default Added Alexandre to CHANGES entry
        Hide
        janhoy Jan Høydahl added a comment -

        Show
        janhoy Jan Høydahl added a comment -
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 14b6d93db4b0a608809782d1ef01fa97840b80e0 in lucene-solr's branch refs/heads/master from Jan Høydahl
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=14b6d93 ]

        SOLR-8370: Display configured Similarity in Schema-Browser

        Show
        jira-bot ASF subversion and git services added a comment - Commit 14b6d93db4b0a608809782d1ef01fa97840b80e0 in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=14b6d93 ] SOLR-8370 : Display configured Similarity in Schema-Browser
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit c35c723bf567e686605c21e06fdbc938b6575b4f in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c35c723 ]

        SOLR-8370: Display configured Similarity in Schema-Browser

        (cherry picked from commit 14b6d93)

        Show
        jira-bot ASF subversion and git services added a comment - Commit c35c723bf567e686605c21e06fdbc938b6575b4f in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c35c723 ] SOLR-8370 : Display configured Similarity in Schema-Browser (cherry picked from commit 14b6d93)
        Hide
        shalinmangar Shalin Shekhar Mangar added a comment -

        Closing after 6.3.0 release.

        Show
        shalinmangar Shalin Shekhar Mangar added a comment - Closing after 6.3.0 release.

          People

          • Assignee:
            janhoy Jan Høydahl
            Reporter:
            janhoy Jan Høydahl
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development