Skip to end of metadata
Go to start of metadata

For every bug in every browser there is an amount of triage that you can do that will help us to correctly assign a bug to the right person to fix and allow the bug to be fixed quickly

Browsers

All browsers have some sort of inbuilt debugging available:

  • Safari
    • (mac) Top bar: Develop > Start debugging Javascript
  • Firefox
    • Download and install Firebug. This is a browser extension here: http://getfirebug.com/ . You will know it's installed if a little bug appears in the bottom right corner of your browser.
    • When using CollectionSpace make sure Firebug is enabled. When enabled, the bug is in colour, when disabled it is black and white. To enable it, click on the bug. A window will pop up. Make sure the net monitoring is enabled. To do that, click on the net tab, and then the arrow next to it. This should pop up a menu. Make sure that enabled is ticked. Now click on Console and then the arrow next to it, and make sure 'Show javascript Errors, Show XMLHttpRequest' are ticked.
    • You can now minimise Firebug (with v shaped button at rhs), and only open it again when there's an issue you want to check out.
  • Chrome (yes it isn't a required browser but the debug tools are very good)
    • (mac) Top bar: View > Developer > Javascript console
  • IE
    • ok I may have been optimistic on this one. more info to follow
    • If you are using IE8 you can actually use its developers tools (F12) and it has a rudimentary debugger and console.

Firefox plugin for doing POSTs

this plugin might help you https://addons.mozilla.org/en-US/firefox/addon/poster/

Javascript debuggers

All the debuggers in chrome, Firefox and safari are by and large similar
The important thing to keep an eye on are the payloads that are passed from the UI to the App layer and back again. These are easily marked as they are all /collectionspace/tenant/...

  • In Chrome & Safari:
    • Click on Resources Tab and the XHR in the sub menu. This should show you just the calls to and fro between the ui and the app
  • In FireFox
    • Click on Console and it should show you a list of GET/POST and PUT urls
    • or: got Net and XHR is the sublist again (however sometimes the response appear to come back blank, when they weren't but the data is more consistent in the Console view)

Resources

Unless these calls are erroring they should be sending and returning valid json.
To make the json more readable you can use utilities like:

GET POST PUT

The kinds of calls you'll be interested in looking at include:

  • GET : this is for all queries that are just returning data e.g. search, record read
  • POST : this is only for create queries e.g. create new object
  • PUT : this is for update queries. e.g. when you make a change to an existing object/record/procedure

Screenshot of the Firebug Console window in Firefox, showing the payload of a POST from the UI to the App layer, to create a new Acquisition record:

URL's and how they are useful to you

If you are not confident debugging the issue from the content of these urls then hopefully you can include the payloads/source in the JIRA so someone can quickly see what happened to your data that you submitted.

TIP

Icon

You can visit all of the URLs below with your browser. Be sure to preface these URLs with the host and port, if any, of the CollectionSpace system to which you'll be sending these requests; e.g. http://myhost:myport/collectionspace/tenant/{tenantname}/ ...

Also, be sure to first use your browser to log into the CollectionSpace UI system to which you'll be sending these requests, via its login screen. This will serve to authenticate your subsequent requests.

all /chain urls have been deprecated and should now be /tenant/{tenantname} - if you do not include the tenant name the system is forced to guess what tenant you are from and it might not work as expected.

Among the most commonly helpful URLs you can visit are (all are GET requests unless otherwise specified):

  • /collectionspace/tenant/{tenantname}/loginstatus
    • Please check this one first. It will tell you whether the user is logged in and what permissions that user has. There is nothing as frustrating as trying to debug something and realising that the user you logged in as doesn't have the permission to do what you wanted.
  • /collectionspace/tenant/{tenantname}/{recordid}/{csid}
    • Retrieves the payload for an existing record, whose record type is {recordid}, such as cataloging or acquisition, and whose identifier is {csid}.
  • /collectionspace/tenant/{tenantname}/{recordid}
    • You'll send this one via a POST request; you'll usually do so by trying to save a new record in the UI, and then looking at the Request and Response payloads in the debugger.
    • Creates a new record of type {recordid}.
    • If data is not saving when creating a new record it is important to look in here. If you find the POST you can see if the value was sent to the App layer in the 'Request' (look in 'header/Formdata' in chrome/safari and in 'put/source' for firefox) and then you can see if the App correctly saved it by looking in the 'Response', to see if the App correctly sent it back to the UI.
  • /collectionspace/tenant/{tenantname}/{recordid}/{csid}
    • You'll send this one via a PUT request; you'll usually check this by trying to edit and save an existing record in the UI, and then looking at the Request and Response payloads in the debugger.
    • Updates an existing record of type {recordid}, whose identifier is {csid}.
    • If data is not saving on an update it is important to look in here. If you find the PUT you can see if the value was sent to the App layer in the 'Request', and then you can see if the App correctly saved it by looking in the 'Response', as noted above.

Other useful URLs include:

  • /collectionspace/tenant/{tenantname}/{recordid}/uispec
    • This is the file that helps match the UI field selectors with the Service names for fields. If a particular field isn't saving data the first thing to do is look in here and see what the selector should be for that field and then seeing if that selector exists on the UI html page.
    • Try it for these record types: cataloging, acquisition, intake, loanin, loanout, location, movement, organization, person.
  • /collectionspace/tenant/{tenantname}/{recordid}/uischema
  • /collectionspace/tenant/{tenantname}/{recordid}/source-vocab/{fieldid}
    • this is association of a field with an authority. If you think that the wrong authority is associated or no authority. If you look in the call you will see information about all the authorities associated with a field
  • /collectionspace/tenant/{tenantname}/{recordid}/autocomplete/{fieldid}?q=...
    • this is the call to retrieve authority values that match the value after q.
    • the data in the Response tab will show you what was returned so you can compare it to what was displayed by the UI
  • /collectionspace/tenant/{tenantname}/id/****
    • this is the url that will return the number pattern you requested (known as idgenerator to the service layer)
  • /collectionspace/tenant/{tenantname}/init
    • this causes the app layer to reload its configuration files for the relevant tenant. This is a quicker way to reflect changes in app layer configuration files than restarting the cspace server.
  • /collectionspace/tenant/{tenantname}/authorities/initialise
    • will initialise default authorities for the relevant tenant but not populate these authorities with any data etc.
  • /collectionspace/tenant/{tenantname}/authorities/vocab/initialize
    • this causes the app layer to initialize term lists (controlled vocabularies) for the relevant tenant.
  • No labels