Recommend passing - “authoritive is a misspelling - when reproducing this bug the hover-over tool tip contains the correct spelling of “authoritative”. Alternatively we can argue for the use of “Authorized”.
When creating an event the main identifier is the type of event + enumeration. Agents and linked records are visible in search results. Requestor would like to be able to assign a title in the Basic Information when creating events. This seems like a plenty useful feature and would help users search for specific events and disambiguate events of similar type more easily. Recommend passing, subject to discussion.
Pass and go with “Authorized”
Awaiting more information--David will ask requestor for more information about what they’re trying to qualify in a title
Possibly a terminology issue - “Add event” in this case really means “create event”. Allowing for events to be linked to resources from the resource page would make that process congruent to linking associated subjects, accessions, etc. Curious if there is a data model issue behind the difference.
Replicated error but in more specific circumstances: only when publishing via “Publish/unpublish all” button at AO level. Does not happen when using checkbox or publish/unpublish all at a level other than the affected AO. Error messages when there is no actual error are a problem, so this should be fixed.
Awaiting more information--Elizabeth asking requestor about how they’re using Events
Pass if occurring in current code - as of Dec 4 not occurring in current code
Posted to user group email list for community feedback.
Confirmed in 3.5 sandbox. Recommend passing.
From our discussion last meeting: accepting “2010-” in the normalized date field is acceptable behavior. The issue is more so with the date calculator not handling these normalized dates correctly.
Pass for configurable option
Pass
Dalton will rewrite to refocus on breaking the date calculator
I definitely think this would be desirable. Recommend passing.
Type ahead will show all results including those with barcodes with dashes until you type a dash. At that point, no search results are returned. It sounds like a similar issue was resolved in ANW-691 so hopefully no one would have to reinvent the wheel. Recommend passing.
1. There is a plug-in that should allow the user to hide these fields (https://github.com/hudmol/user_defined_in_basic ). This can be recommended as a potential fix. However, I also think automatically hiding unused user defined fields would be a worthwhile improvement.
ArchivesSpace documentation states that slugs cannot contain characters that are reserved or those that cannot be used in URLs, including non-alphanumeric characters such as colons, forward slashes, and others. This seems like a standard limitation on the formation of slugs/URLs, so I recommend closing.
I was able to replicate this issue on 4.0.0 RC. Oddly, this issue does not appear when “auto generate slug” active - the slug only gets overwritten when auto generate is disabled. Recommend passing.
I think that making the regular expression more strict does make sense based on my understanding of the intent, which appears to just be to convert resource URIs to links for easier navigation from the job details page.
Additionally, I’d propose that we also add some error handling to fall back on just displaying the value if the conversion of to a link fails even if the regular expression matches.