External URL sources
Hi
Melissa
,
An issue came up yesterday that made me realize that we need to modify some of the requirements for the new application. The issue concerns disputes and documents where we do not have applicable documentation on the system. This is a common thing for us to do with documents when we decide not to integrate a full text copy of the document, and rather create a placeholder document that provides the user with a full citation and a link to an external source where they can obtain a copy of the document. Any of the category A and B documents with (citation and source) in the document title are examples of these documents: https://www.investorstatelawguide.com/Treaties/AnnotDocument?toc=annotSection&agreementID=443&tabcontent=&cat=bit.
Currently, these placeholders are manually created by the ISLG content team (both the XML and PDF). It is a fairly tedious process, and it would be great if we could automate parts of this process. I'm wondering if we could do this by creating additional fields in the applicable master lists, which would display the relevant information when a full text version of the document is not available. I have made modifications to the ISLG Meta Data Field Map for the following lists (highlighted in green in the spreadsheet):
An issue came up yesterday that made me realize that we need to modify some of the requirements for the new application. The issue concerns disputes and documents where we do not have applicable documentation on the system. This is a common thing for us to do with documents when we decide not to integrate a full text copy of the document, and rather create a placeholder document that provides the user with a full citation and a link to an external source where they can obtain a copy of the document. Any of the category A and B documents with (citation and source) in the document title are examples of these documents: https://www.investorstatelawguide.com/Treaties/AnnotDocument?toc=annotSection&agreementID=443&tabcontent=&cat=bit.
Currently, these placeholders are manually created by the ISLG content team (both the XML and PDF). It is a fairly tedious process, and it would be great if we could automate parts of this process. I'm wondering if we could do this by creating additional fields in the applicable master lists, which would display the relevant information when a full text version of the document is not available. I have made modifications to the ISLG Meta Data Field Map for the following lists (highlighted in green in the spreadsheet):
- Dispute
- URL
- Common URL Source
- Dispute Documents
- Publicly Available
- Treaties
- Placeholder
- Full Citation
- URL
- Common URL Source
- Arbitration Rules
- Placeholder
- Full Citation
- URL
- Common URL Source
I have made modifications to the URL Link requirements to create a display text field in addition to the URL text itself (see: https://industrialagency.tpondemand.com/RestUI/Board.aspx#page=board/5389754907359543952&appConfig=eyJhY2lkIjoiRUM0QzUwNTU4QzZBNUQ1NjQxRkNGNUQyM0FFRDQxM0YifQ==&boardPopup=userstory/7907).
For Common URL Source fields, this is a new type of Dropdown URL Link field that allows admin users to maintain a defined list of common URLs that are used as external sources. Creating a defined list of URLs would allow the admin user to modify the URLs of any document associated with that common URL source, which would avoid the need of modifying a large number of URL links when a common URL source changes. We've experienced this a few times of the over the years, and it creates a huge headache for our content team. This is a new type of field, and a new user story with requirements will be needed.
I've also added new fields to the Dispute and Dispute Documents master lists to allow admin users to add external source links when applicable. For Dispute Document entries, this will apply to documents where the document is not publicly available. For Disputes, this will allows us to provide users with third party sources to corroborate dispute data that is not supported by documentation.
Let me know your thoughts.
Thanks,
Morgan
For Common URL Source fields, this is a new type of Dropdown URL Link field that allows admin users to maintain a defined list of common URLs that are used as external sources. Creating a defined list of URLs would allow the admin user to modify the URLs of any document associated with that common URL source, which would avoid the need of modifying a large number of URL links when a common URL source changes. We've experienced this a few times of the over the years, and it creates a huge headache for our content team. This is a new type of field, and a new user story with requirements will be needed.
I've also added new fields to the Dispute and Dispute Documents master lists to allow admin users to add external source links when applicable. For Dispute Document entries, this will apply to documents where the document is not publicly available. For Disputes, this will allows us to provide users with third party sources to corroborate dispute data that is not supported by documentation.
Let me know your thoughts.
Thanks,
Morgan
Just pinging you to ensure we integrate the above into the to-do list.
Thanks,
Morgan
Thanks for the reminder here. I had updated the relevant forms, however I think there is a better way to handle this.
We could adopt the methods used commonly for url redirections. This would be easier to manage on your end.
Essentially you could maintain a list of common URL sources as you suggested, but rather than having the field on each form, admins would just copy the url as is exists into the URL field.
If a change occurs to the common URL source, the admin will update it in the list and at that time the system will crawl the related forms (Dispute, Dispute Documents, Treaties, Arbitration rules) and update the string. We can also keep a historical record of the previous data in case we ever need to revert.
Let me know if this makes sense to you.
Mel
Morgan
We've had a few more discussions about this internally.
How often do you foresee this happening? The reason I ask is that it is likely far more efficient for the dev team to write a script to perform this task on a case by case basis then building a feature to accommodate it.
Let me now what you think or if you'd like to discuss further.
Mel
Ok. I'm not opposed to that solution. Perhaps you could explain how the feature would work? For example, would we be able to associate a group of documents with the same source URL?
Morgan