Page History

...

• Authorization display in UI: How to pass Authorization rights (i.e. logged in user's access rights) from REST API to Angular?  See for example: https://github.com/DSpace/dspace-angular/issues/393
  • After much discussion, we've realized there may not be a single solution to this problem.  Though more analysis is necessary to determine that.
  • Tim has started a Managing Authorization info in Angular UI wiki page for early ideas/brainstorms.  The initial ideas brought up in this discussion are noted there already
• Scripts & Processes Endpoint: https://github.com/DSpace/Rest7Contract/pull/17
  • Tim still worried about scope creep here.  Asked for more info on the proposed backend solution
  • Main questions are around the proposed "/api/system/processes" endpoint in the REST Contract, as it seems to require several features that don't currently exist on the DSpace backend (Java API or database or Solr).  Some of those seemingly non-existent features include:
    • A way of tracking currently running DSpace processes, their start-time, current status, runtime parameters, etc.
    • A way to assign UUIDs to all processes, and link those processes to DSpace user accounts (UUIDs)
    • A way to see the output of finished processes individually (currently most processes just log to the DSpace log file, not to individual log files)
  • Atmire will take this feedback back and try and clarify the proposal for how a backend implementation might work.
• I18n status update on https://github.com/DSpace/dspace-angular/pull/366
  • Art noted that after further analysis, it looks like the "ngx-translate" PO file loader (https://github.com/biesbjerg/ngx-translate-po-http-loader) seems unmaintained, and doesn't seem to have many users.  It also seems to not be fully compatible with later versions of Angular, and doesn't work with Universal (SEO) yet.
    • This makes our ability to support PO files more complex...we'd have to fix this loader to work properly & with Universal.
  • The Angular project itself has taken a different direction altogether.  It uses XLIFF (instead of PO).  However, instead of managing translations on the client side, they are doing so on the server-side.  So, if you want an application to support 5 different languages, you'd build/deploy the application 5 times (one for each language).  If users want to switch language, they are actually switching apps (though their session info can be passed between apps).
    • Angular project claims this server side setup is much more performant for larger applications.  Unclear if we'll see this sort of performance problem though.
  • Neither of these solutions sounds ideal at this point.  We'd like to support common translation formats (e.g. PO or XLIFF) to make translations easier on translators.  But, there's not a clear "winner" between these options.
  • For the time being, we will stick with JSON (default format of "ngx-translate"), but flatten our JSON keys (to make things easier for translators)
    • We will track the PO loader for ngx-translate. If it gets more movement/support, we'll move to using it.
    • We will also track performance of ngx-translate. If we find that it's not performing well, we may eventually need to move to the Angular project approach (server side)