| 52 | | || 21 || || Metadata versioning || !GeoNetwork needs some form of version control to track changes made to a metadata record over time. Action/Justification: This can be done inside the database without needing to externalise the metadata records. That way you can index and search on the old versions as well, if desired. Alternatively it could be done externally using perhaps a Java interface to subversion or through an interface to existing enterprise document management systems or perhaps using a different database approach for the documents eg. CouchDB. See also [http://geoserver.org/display/GEOS/Versioning+WFS this] approach to versioning WFS content?|| heikki: 3 || |
| 53 | | || 22 || || Community || Some aspects of project planning for !GeoNetwork are not visible to those outside the project steering committee. Action: Continue to adopt and implement OSGeo best practise (e.g. GeoServer).|| heikki: 2 || |
| 54 | | || 23 || ||Documentation / Community ||Documentation for ‘Implementing !GeoNetwork into your organisation’ should be provided. Rather than changing the perspective of the current documentation from "how to" from "it does", perhaps you can have different documentation for different audiences. The “how to” section of the Trac is very useful. Action: As the “how to” section of the OSGeo !GeoNetwork trac site expands, it could be linked into the documentation. || heikki: 2 || |
| 55 | | || 24 || ||Index enhancement ||!GeoNetwork’s current Lucene field / index names and the mapping of metadata fields to these Lucene field names are ad hoc. This has the potential to prevent search interoperability between catalogues. Action: !GeoNetwork should use an established mapping such as the geo profile of Z3950 (including attributes, data and relations) to define Lucene field names and the mapping from metadata elements to Lucene fields for all metadata schemas. || heikki: 2 || |
| 56 | | || 25 || ||Validation enhancement||XSD and Schematron Validators return errors that are meaningless to most users. Ability to customise the error messages easily would be useful. Action: Code containing XSD validation messages needs to be modified to include alternative or additional messages to those already in use. Schematron diagnostics specified in rules should be made more useful to users. setErrorHandler already in use - could me modded to support more meaningful messages? Francois has updated schematron to schematron validation and reporting language.|| heikki: 1 || |
| 57 | | || 26 || ||Documentation ||!GeoNetwork requires a generic capability for element help, code list choices and suggestions to be linked to metadata guidelines provided with profiles/standards. Action: !GeoNetwork to call documentation components from external sources (e.g. mouse over tool tips from profile/standard and code list documentation). || Partially done in NGR by Jose || |
| 58 | | || 27 || || Metadata categories||!GeoNetwork categories are not related to metadata content – should be configurable from content. Action: !GeoNetwork should be able to configure dynamic categories from a Lucene field. Eg. An administrator could create category names as unique values of the Lucene field name purpose (which might be mapped to gmd:purpose for ISO) – records would belong to the category described by purpose cf. also discussion on dynamic categories ie. categories that are placeholders for a saved search. || heikki: 4 || |
| 59 | | || 28 || ||Tag cloud || GeoNetwork currently does not manage its own tag cloud / Folksonomy. Action: !GeoNetwork could optionally manage these things internally rather than using a third party social networking site. [http://trac.osgeo.org/geonetwork/ticket/96 Ticket 96 suggests a way of doing this]|| heikki: 4 || |
| 60 | | || 29 || ||Harvester / Network-crawling ||Network-crawling for geo-resources. Action: GeoNetwork needs to continue to be aware of and exploit initiatives for automatic harvesting of metadata from geo-resources. Eg. Metadata extraction tools such as the Talend Spatial Data Integrator suite etc || heikki: 3 | jose: major || |
| 61 | | || 30 || ||Metadata identifier ||!GeoNetwork lacks the ability to consistently reproduce a unique identifier for the same geo resource (e.g. same dataset stored in two different locations) and/or use persistent identifier services. This is somewhere along the range from "easy enough" to "very difficult", need to spell out the precise details of the set of features you have in mind. Action: GeoNetwork needs to be able to generate, store and use metadata identifiers (eg, gmd:fileIdentifier) as well as data identifiers using the current stand alone UUID, but also (for data objects) MD5 (including what the checksum was generated from) and identifiers from external persistent identifier services (It should be possible to obtain persistent identifiers for both metadata and data from external persistent identifier services). || heikki: 4 || |
| 62 | | || 31 || ||Interoperability / resources discovery||Better inter-application interoperability. GeoNetwork needs to rethink the interoperability with the emerging FOSS such as the way that OpenLayers is designing / redeveloping its interface. e.g. use of GeoExt; e.g. GeoNetwork needs to provide simple mechanisms to allow discovered resources to be exploited and utilised in complementary open source software; e.g. drag-and-drop discovered resources into OpenLayers or GeoServer. Action: Better intra-application interoperability. GeoNetwork needs to coordinate the discovery of resources with the publication of those same resources in FOSS such as GeoServer. || heikki: 2 | jose: major || |
| 63 | | || 32 || ||Data management ||!GeoNetwork assumes resources that are tagged as data for download in gmd:protocol are local. Action: GeoNetwork needs to allow for the fact that data tagged as data for download may not be local. || heikki: 1 || |
| 64 | | || 33 || ||Remote search||Remote search across a number of sites returns a pre-selected number of hits from all remote sites (pre-selected number is a search option) – it should return these hits from each site. Action: Presentation of pre-selected number of hits from each remote site – may require more delving into JZKit. || heikki: 3 || |
| 65 | | || 34 || ||Remote search||Presentation of returned hits from remote sites may be very slow because search is limited by the speed of the slowest site. Action: Presentations of first returned hits from first responding remote site should not have to wait on the slowest site – may require more delving into JZKit. || heikki: 3 || |
| 66 | | || 35 || ||Configuration||There are too many configuration files in too many places eg. repositories.xml.tem and not all configuration options are supported by the existing admin interfaces. Action: Continue to consolidate configuration options in the system configuration interface. || heikki: 2 || |
| 67 | | || 36 || ||Web map client|| There is no documentation for the implementation of alternative web map clients to Intermap and this makes it appear that the process is far harder than it actually is. Given the enthusiasm for an OpenLayers-based interface, what "interface" there currently is will probably soon be rapidly-evolving - if not replaced completely. Action: Document the interface that GeoNetwork uses to call a web map client so that sites can substitute their own.|| heikki: 1 | jose: critical || |
| 68 | | || 37 || ||Distributed search||Current capability of !GeoNetwork to use distributed searching is given a low priority and not being developed when compared with the local search. Action: More consideration is required towards distributed searches and proper attention should be given to it.|| heikki: 2 || |
| 69 | | || 38 || ||Distributed CSW search|| Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented. || heikki: 1 || |
| 70 | | || 39 || || XML validation|| Potential for remotely accessed information to be malicious. Action: !GeoNetwork should validate all XML inputs and responses (eg. as it does for CSW) and check expected MIME types e.g. you ask for a GIF, you get a GIF. And indicate / reject non-conforming content with a warning?|| heikki: 1 || |
| 71 | | || 40 || ||Perfs enhancement (XSL)|| !GeoNetwork does too much expensive processing of XML documents with XSLT. Action: Continue to seek out and remove unnecessary XSLT processing.|| heikki: 4 || |
| 72 | | || 41 || ||Configuration ||The way that !GeoNetwork handles timeouts to remote requests is not configurable. Action: In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface.|| heikki: 2 || |
| 73 | | || 42 || ||Project management / sandbox strategy||Developments in "sand boxes" are not pushed back into the trunk in a timely manner. Action: The PSC should publish and enforce tighter processes relating to sandboxes. If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above). || heikki: 1 || |
| 74 | | || 43 || ||Customization||!GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: !GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code. || heikki: 3 || |
| 75 | | || 44 || ||Installer / Application server||There is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: !GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container. Jetty should continue to be the default. || heikki: 4 || |
| 76 | | || 45 || ||Parent/child policy ||Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component. Perhaps provide a way to limit results to only parents and toggle this option on/off. || heikki: 3 || |
| 77 | | || 46 || ||Search||Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful). Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. || || |
| 78 | | || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || heikki: proposes OWL/ebRIM integration, see [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/] || |
| 79 | | || 48 || ||Reusable Objects || Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above.|| heikki: 3 || |
| 80 | | || 49 || ||HTTPS support || HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks.|| heikki: 2 || |
| 81 | | || 50 || ||CRS management || EPSG code data from external service Action: At the moment EPSG codes have to be entered manually, but external online services are available with that data. GN should utilize this.|| DONE in 2.5 || |
| 82 | | || 51 || || Hierarchical keywords|| Keywords from external vocabularies should utilize hierarchical broader/narrower structures to ease searching capability.|| heikki: proposes [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/], mathieu (major) || |
| 83 | | || 52 || ||Indexation enhancement|| Using Apache Tika to index content from files attached to metadata records in !GeoNetwork?|| || |
| 84 | | || 53 || ||Indexation enhancement || Replace Lucene interface in GN with Apache Solr?|| heikki(blocker), mathieu(major) || |
| 85 | | || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| heikki: 3 || |
| 86 | | || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk. || heikki: 5 || |
| 87 | | || 56 || ||Customization || Improve CSS management, clean CSS file and references to unused styles, replacing tables by divs, discuss on [wiki:ThemeCustomization]|| heikki: 1 | jose: critical | francois : major || |
| 88 | | || 58 || ||Settings management || While at it can we change the code so that you can save settings from the GUI even if not all expected settings are present in your database?|| heikki: 1 || |
| 89 | | || 59 || || SMTP || Converge mail configuration (feedback + wmc.mailcontext use same config) || heikki: 1 || |
| 90 | | || 60 || || SMTP || enable configuration of smtp servers that require authentication. i.e. configure autherticate/secure y/n, username, password. || heikki: 1 || |
| 91 | | || 61 || || !CatalogSearcher is not an extension of !MetaSearcher || !LuceneSearcher, !UnusedSearcher and Z3950Searcher are all extensions of !MetaSearcher but !CatalogSearcher for CSW is not. This is ok until !CatalogSearcher is put into the session as Geonet.Session.SEARCH_RESULT where up until now only the extensions of !MetaSearcher were expected. Because !CatalogSearcher is not a !MetaSearcher the nice polymorphism/dynamic binding used for example when closing the searcher (get a !MetaSearcher and do searcher.close()) is broken and we need to do ugly if (object instanceof !LuceneSearcher) then .... else etc etc etc. Action: make !CatalogSearcher an extension of !MetaSearcher or put it somewhere else in the session. || || |
| | 52 | || 21 || || Metadata versioning || !GeoNetwork needs some form of version control to track changes made to a metadata record over time. Action/Justification: This can be done inside the database without needing to externalise the metadata records. That way you can index and search on the old versions as well, if desired. Alternatively it could be done externally using perhaps a Java interface to subversion or through an interface to existing enterprise document management systems or perhaps using a different database approach for the documents eg. CouchDB. See also [http://geoserver.org/display/GEOS/Versioning+WFS this] approach to versioning WFS content?|| heikki: 3 || Nice to have || |
| | 53 | || 22 || || Community || Some aspects of project planning for !GeoNetwork are not visible to those outside the project steering committee. Action: Continue to adopt and implement OSGeo best practise (e.g. GeoServer).|| heikki: 2 || Developper mailing list, IRC, trac || |
| | 54 | || 23 || ||Documentation / Community ||Documentation for ‘Implementing !GeoNetwork into your organisation’ should be provided. Rather than changing the perspective of the current documentation from "how to" from "it does", perhaps you can have different documentation for different audiences. The “how to” section of the Trac is very useful. Action: As the “how to” section of the OSGeo !GeoNetwork trac site expands, it could be linked into the documentation. || heikki: 2 || Migration to sphinx on its way || |
| | 55 | || 24 || ||Index enhancement ||!GeoNetwork’s current Lucene field / index names and the mapping of metadata fields to these Lucene field names are ad hoc. This has the potential to prevent search interoperability between catalogues. Action: !GeoNetwork should use an established mapping such as the geo profile of Z3950 (including attributes, data and relations) to define Lucene field names and the mapping from metadata elements to Lucene fields for all metadata schemas. || heikki: 2 || Create mapping table in the documentation || |
| | 56 | || 25 || ||Validation enhancement||XSD and Schematron Validators return errors that are meaningless to most users. Ability to customise the error messages easily would be useful. Action: Code containing XSD validation messages needs to be modified to include alternative or additional messages to those already in use. Schematron diagnostics specified in rules should be made more useful to users. setErrorHandler already in use - could me modded to support more meaningful messages? Francois has updated schematron to schematron validation and reporting language.|| heikki: 1 || Improve XSD error reporting (localized message ?) || |
| | 57 | || 26 || ||Documentation ||!GeoNetwork requires a generic capability for element help, code list choices and suggestions to be linked to metadata guidelines provided with profiles/standards. Action: !GeoNetwork to call documentation components from external sources (e.g. mouse over tool tips from profile/standard and code list documentation). || Partially done in NGR by Jose || On going || |
| | 58 | || 27 || || Metadata categories||!GeoNetwork categories are not related to metadata content – should be configurable from content. Action: !GeoNetwork should be able to configure dynamic categories from a Lucene field. Eg. An administrator could create category names as unique values of the Lucene field name purpose (which might be mapped to gmd:purpose for ISO) – records would belong to the category described by purpose cf. also discussion on dynamic categories ie. categories that are placeholders for a saved search. || heikki: 4 || Could be achieve in the index-fields mechanism || |
| | 59 | || 28 || ||Tag cloud || GeoNetwork currently does not manage its own tag cloud / Folksonomy. Action: !GeoNetwork could optionally manage these things internally rather than using a third party social networking site. [http://trac.osgeo.org/geonetwork/ticket/96 Ticket 96 suggests a way of doing this]|| heikki: 4 || Good idea ! || |
| | 60 | || 29 || ||Harvester / Network-crawling ||Network-crawling for geo-resources. Action: GeoNetwork needs to continue to be aware of and exploit initiatives for automatic harvesting of metadata from geo-resources. Eg. Metadata extraction tools such as the Talend Spatial Data Integrator suite etc || heikki: 3 | jose: major || || |
| | 61 | || 30 || ||Metadata identifier ||!GeoNetwork lacks the ability to consistently reproduce a unique identifier for the same geo resource (e.g. same dataset stored in two different locations) and/or use persistent identifier services. This is somewhere along the range from "easy enough" to "very difficult", need to spell out the precise details of the set of features you have in mind. Action: GeoNetwork needs to be able to generate, store and use metadata identifiers (eg, gmd:fileIdentifier) as well as data identifiers using the current stand alone UUID, but also (for data objects) MD5 (including what the checksum was generated from) and identifiers from external persistent identifier services (It should be possible to obtain persistent identifiers for both metadata and data from external persistent identifier services). || heikki: 4 || || |
| | 62 | || 31 || ||Interoperability / resources discovery||Better inter-application interoperability. GeoNetwork needs to rethink the interoperability with the emerging FOSS such as the way that OpenLayers is designing / redeveloping its interface. e.g. use of GeoExt; e.g. GeoNetwork needs to provide simple mechanisms to allow discovered resources to be exploited and utilised in complementary open source software; e.g. drag-and-drop discovered resources into OpenLayers or GeoServer. Action: Better intra-application interoperability. GeoNetwork needs to coordinate the discovery of resources with the publication of those same resources in FOSS such as GeoServer. || heikki: 2 | jose: major || || |
| | 63 | || 32 || ||Data management ||!GeoNetwork assumes resources that are tagged as data for download in gmd:protocol are local. Action: GeoNetwork needs to allow for the fact that data tagged as data for download may not be local. || heikki: 1 || Change protocol to local-download ? || |
| | 64 | || 33 || ||Remote search||Remote search across a number of sites returns a pre-selected number of hits from all remote sites (pre-selected number is a search option) – it should return these hits from each site. Action: Presentation of pre-selected number of hits from each remote site – may require more delving into JZKit. || heikki: 3 || Is it possible to make it abstract in order to extend to other protocols ? || |
| | 65 | || 34 || ||Remote search||Presentation of returned hits from remote sites may be very slow because search is limited by the speed of the slowest site. Action: Presentations of first returned hits from first responding remote site should not have to wait on the slowest site – may require more delving into JZKit. || heikki: 3 || || |
| | 66 | || 35 || ||Configuration||There are too many configuration files in too many places eg. repositories.xml.tem and not all configuration options are supported by the existing admin interfaces. Action: Continue to consolidate configuration options in the system configuration interface. || heikki: 2 || eg. Z39.50 repositories || |
| | 67 | || 36 || ||Web map client|| There is no documentation for the implementation of alternative web map clients to Intermap and this makes it appear that the process is far harder than it actually is. Given the enthusiasm for an OpenLayers-based interface, what "interface" there currently is will probably soon be rapidly-evolving - if not replaced completely. Action: Document the interface that GeoNetwork uses to call a web map client so that sites can substitute their own.|| heikki: 1 | jose: critical || || |
| | 68 | || 37 || ||Distributed search||Current capability of !GeoNetwork to use distributed searching is given a low priority and not being developed when compared with the local search. Action: More consideration is required towards distributed searches and proper attention should be given to it.|| heikki: 2 || || |
| | 69 | || 38 || ||Distributed CSW search|| Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented. || heikki: 1 || || |
| | 70 | || 39 || || XML validation|| Potential for remotely accessed information to be malicious. Action: !GeoNetwork should validate all XML inputs and responses (eg. as it does for CSW) and check expected MIME types e.g. you ask for a GIF, you get a GIF. And indicate / reject non-conforming content with a warning?|| heikki: 1 || || |
| | 71 | || 40 || ||Perfs enhancement (XSL)|| !GeoNetwork does too much expensive processing of XML documents with XSLT. Action: Continue to seek out and remove unnecessary XSLT processing.|| heikki: 4 || || |
| | 72 | || 41 || ||Configuration ||The way that !GeoNetwork handles timeouts to remote requests is not configurable. Action: In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface.|| heikki: 2 || || |
| | 73 | || 42 || ||Project management / sandbox strategy||Developments in "sand boxes" are not pushed back into the trunk in a timely manner. Action: The PSC should publish and enforce tighter processes relating to sandboxes. If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above). || heikki: 1 || || |
| | 74 | || 43 || ||Customization||!GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: !GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code. || heikki: 3 || || |
| | 75 | || 44 || ||Installer / Application server||There is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: !GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container. Jetty should continue to be the default. || heikki: 4 || Done in the maven migration || |
| | 76 | || 45 || ||Parent/child policy ||Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component. Perhaps provide a way to limit results to only parents and toggle this option on/off. || heikki: 3 || Not displayed in search results but in the metadata top right corner || |
| | 77 | || 46 || ||Search||Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful). Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. || || || |
| | 78 | || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || heikki: proposes OWL/ebRIM integration, see [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/] || || |
| | 79 | || 51 || || Hierarchical keywords|| Keywords from external vocabularies should utilize hierarchical broader/narrower structures to ease searching capability.|| heikki: proposes [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/], mathieu (major) || || |
| | 80 | || 48 || ||Reusable Objects || Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above.|| heikki: 3 || See composed metadata records || |
| | 81 | || 49 || ||HTTPS support || HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks.|| heikki: 2 || To be checked, Maybe the download URL set to http by default ? || |
| | 82 | || 50 || ||CRS management || EPSG code data from external service Action: At the moment EPSG codes have to be entered manually, but external online services are available with that data. GN should utilize this.|| Done in 2.5 || || |
| | 83 | || 52 || ||Indexation enhancement || Using Apache Tika to index content from files attached to metadata records in !GeoNetwork?|| || || |
| | 84 | || 53 || ||Indexation enhancement || Replace Lucene interface in GN with Apache Solr?|| heikki(blocker), mathieu(major) || || |
| | 85 | || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| heikki: 3 || Good idea ! || |
| | 86 | || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk. || heikki: 5 || Available in Bluenet || |
| | 87 | || 56 || ||Customization || Improve CSS management, clean CSS file and references to unused styles, replacing tables by divs, discuss on [wiki:ThemeCustomization]|| heikki: 1 | jose: critical | francois : major || || |
| | 88 | || 58 || ||Settings management || While at it can we change the code so that you can save settings from the GUI even if not all expected settings are present in your database?|| heikki: 1 || || |
| | 89 | || 59 || || SMTP || Converge mail configuration (feedback + wmc.mailcontext use same config) || heikki: 1 || Replacing Intermap should fix that || |
| | 90 | || 60 || || SMTP || enable configuration of smtp servers that require authentication. i.e. configure autherticate/secure y/n, username, password. || heikki: 1 || || |
| | 91 | || 61 || || !CatalogSearcher is not an extension of !MetaSearcher || !LuceneSearcher, !UnusedSearcher and Z3950Searcher are all extensions of !MetaSearcher but !CatalogSearcher for CSW is not. This is ok until !CatalogSearcher is put into the session as Geonet.Session.SEARCH_RESULT where up until now only the extensions of !MetaSearcher were expected. Because !CatalogSearcher is not a !MetaSearcher the nice polymorphism/dynamic binding used for example when closing the searcher (get a !MetaSearcher and do searcher.close()) is broken and we need to do ugly if (object instanceof !LuceneSearcher) then .... else etc etc etc. Action: make !CatalogSearcher an extension of !MetaSearcher or put it somewhere else in the session. || || || |
