What would you like to see from CollectiveAccess 2.0?



  • edited August 2018

    The ability to set a metadata element as read only at the element and sub-element level with sub-elements not necessarily inheriting the value from the level above. Currently this only seems to be available at the interface level.

  • Another thing comes to mind as I'm working through. The ability to restrict elements by user/role/group in the element options in the 'Elements to Display on This Screen' in the 'Screen Content' field on the user interface editor. Currently we can restrict by record type but not by user/role/group. While this can be accomplished by creating a new interface, the options specific to the element representation in a user interface have to be set each time and time spent setting up the new interface.

  • This has been mentioned previously in this thread, but the ability to truly merge entities and even records. Right now the delete action on an entity can transfer relationships to another entity but does not transfer entity information, allow you to combine the entity information with another entity, or select which information fields to keep. :)

  • One more before the weekend, the ability to duplicate interfaces!

  • Someone has mentioned already Outlook integration and notifications. Bugtracker integration seems like it might be useful as well. I am using Trac but most of others would probably be fine. It could be very simple first, like reporting an issue from a set or a record and later it could evolve into something more closely tied with processes involved with management of a digital collection.

  • Be able to add translations(local) in displays and exports

  • The ablity to use quotes for exact phrases in the advanced search fields in pawtucket2.

  • The century expression in dates and time could be updated to the correct year range. For example, 20th century is currently described as 1900-1999, when it should be 1901-2000.

  • "20th century" is an alias for 1900s ... which is 1900-1999. Perhaps we should start distinguishing between the two.

  • I have an idea for CollectiveAccess 3.0 as this request feels as if it would be too complicated to add to the next version.

    I am currently working on a process to make it easier for one of my volunteers catalogue. My current plan involves a more steps than I would like,* so perhaps a future feature could be to have an optional speech recognition plugin.

    *My current thoughts are to create a importer to manage CSV files created by a voice recognition software.

  • mobile-friendly input and update!

  • It would be great to have a faster media upload tool, with the possibility to select or drag & drop a set of images.
    In general, it would be really useful to treat the media browsing section as a sort of DAM environment, where you can easily tag, search and order your images and then attach them to an object.

  • ERROR --> DatabaseException: Table 'C:\xampp\tmp#sqlf870_cc_3.MAI' is read only
    error in collective access log file please help me

  • @susmitamtechnolab Please post this in a separate thread.

  • Ability to search annotations: Specifically, I am adding tags to subclips of a video, and I would like to be able to search for matching subclips (by tag) in the main search interface

  • The ablity to set defaults in individual search forms fields

  • In the GUI media import, to choose whether the representation is primary or not.

  • I would greatly appreciate the ability to do basic image correction (crop, rotate, color correction, etc.) to media files once they are uploaded into CA.

  • edited October 2019

    Small thing-- it would be nice in the gui data import "Metadata import processing status" if it would tell you which file you're importing from. Instead of just
    Importing objects using (mapping), it did something like Importing objects using (mapping) from filename.xlsx

    It would be helpful when you're doing a number of imports and get interupted or just have a really long one to know which file you're on.

  • Hi,

    I think Providence and Pawtucket2 Wiki documentation should be revised (I could contribute to this task if You need). There are a lot of typos, broken links and some sections (like import, export and mappings) could be further explained and have more examples.



  • We are in the process of replacing the wiki with a new manual. You can see it at http://manual.collectiveaccess.org. It is very much a work in progress.

  • Minor thing--In the import media GUI, I would like to have the matching section with limit to type in the main area rather than the advanced. We much more frequently have media to add to records rather than create records from media and my users frequently see that type for creating new objects, think they've selected for attaching media to existing records and then attach objects to the wrong type of records. Also it would nice to be able to save media import settings.

  • The Nomenclature Subcommittee has created a separate website for Chenhall's Nomenclature (https://www.nomenclature.info/index.app) and one of the promises is to develop an API for the site. Therefore, I would like to see CollectiveAccess 2.0 to be able to integrate the API, or one of the other methods of accessing the data that the task force is creating, to be able to access the Nomenclature data easily.

  • I would like to see consistency in naming conventions - specifically the Caption in the editing object screen actually draws from ca_objects.subtitle. This sort of thing can be very confusing!

  • @nirvine It's really up to the profile author to keep those names consistent. Often times data elements start out with a name and then is changed by users as requirements evolve. That said, we also have various naming inconsistencies in the CA code itself, so your point is well taken!

  • I think a number of the problems I have found derive from the profile I chose to use.

  • 1. One situation that arised when describing an art museum archive is that a list item that is, for example, used in a "materials and techniques" metadata element of an artwork, could be used in a "subjects" metadata element when describing a letter by the author of the work. IE: "materials and techniques: bronze", "subjects: bronze". But a "subjects" field could also use terms from other lists, or even other tables.

    Right now one approach could be to generate a new list where to add all the terms used as subjects of a document even if they exist in other lists. Another approach could be not using lists and using occurrences instead, but all this looks messy.

    If a list element could reference multiple lists and use terms from all of them this could be solved.

    2. In a similar way, being able to restrict the use of certain list items by, just like we can restrict relationship types in the bundles would help: instead of having "artwork_types", "document_types" and "publication_types" lists, we could just add the terms to the object_types list. This was discussed here: https://gitter.im/collectiveaccess/support?at=59c14aeecfeed2eb652aeefd

    3. The importer mapping could benefit from a drag and drop UI on the web in the line of Drupal Feeds module and Feeds Tamper module.

    4. Relationship types are defined in the installation profile or through the web interface. It would really be helpful to be able to import and quick add relationship types.

    5. Adding all the .conf files options to an advanced configuration screen in the web ui.

    6. Adding the ability to import specific parts of the installation profile or the configuration. For example, I would love to move an interface or a metadata element from one Providence installation to another
  • I may have mentioned this before but I'm working quite a bit with out database lately and some things come to mind.

    1) A combining or clearer distinction of user roles and groups.

    2) More central area to modify displays, user interfaces, and search forms. They're all in different spots, and are different tools, but I find when I'm doing something I often want to modify more than one and have to navigate to the appropriate area.

    3) In working with our database I think the ability to bring sub-elements up to a top level or on its own without data loss would be useful.

    For our instance, when we migrated to CA fields such as Cataloguer which were text fields in our old database were imported as text fields. Makes sense. Going forward we're using a drop down field to eliminate spelling errors. Rather than having multiple 'boxes' for fields such as Cataloguer we created a sub-element in the Cataloguer 'box' with the drop down. All the text names have been migrated to the drop down but since the text field is the top level field we can't remove it without removing the drop down and seemingly the associated data. Hopefully that makes sense.

  • Last post number 3 would be really useful. In fact you can just do that in the database, changing the parent ID.
Sign In or Register to comment.