LabTrove Development Task List

From LabTrove Documentation
Jump to: navigation, search

1. Update Documentation[edit]

Update the documentation on In particular it would be useful to find somewhere to host screen-shots for the documentation, as following numbered list can be quite difficult.

  • TSP+DRN - Using screenshots in documentation for 2.4 is essential. We have confirmed that screenshots of various formats (and very large sizes) can be successfully uploaded and used in this wiki. It is important to get the case for filenames correct or they won't work.
  • TSP - For future LabTroves we should replace the wiki with something that can be properly versioned.

2. New LabTrove Release[edit]

Producing a 2.4 release of LabTrove and adding it to the DEB package manager under labtrove-stable, so that someone wanting to install LabTrove can be sure they are getting a 'working' version.

The plan would be to have a stable branch an periodically merge to this and bump a minor version, e.g. 2.4.1, 2.4.2, etc. Creating new tagged versions would not be appropriate, as this just perpetuates the array of different versions people might run. There should be several choices to get either the current stable or the bleeding edge (i.e. SVN trunk):

  1. Install the deb package: labtrove (bleeding edge) or labtrove-stable
  2. Checkout the SVN, either trunk or the stable branch.
  3. Download the latest stable tarball from Sourceforge.

The last of these options makes it difficult to upgrade because we have to manually guide the sysadmin through how to bring down the new tarball and replace the old codebase with this. This is particularly difficult if they had added their own CSS or additional code. For this reason I would discourage the use of a tarball.

  • TSP - if we offer SVN tip-of-trunk or tip-of-branch checkout then as a courtesy we should generate a tarball too.
    • (For those people who run systems but are not developers - we shouldh't have to teach them SVN).
    • I do not see why we have to discourage the tarball - that is the traditional method of obtaining LabTrove.
    • We can call them LabTrove-2.4-r789.tar.gz (or LabTrove-Trunk-r890.tar.gz).
      • The r number is the significant thing.

3. Continuous Integration (CI) Environment[edit]

Produce a CI environment for testing SVN commits to LabTrove do not break existing functionality.

Setting something like this up should be fairly straightforward, the bigger task is building all the acceptance tests for every piece of functionality. Also we would need a new VM (or re-purpose an old VM) to do this.

  • TSP - Without a comprehensive test suite, a CI builder has little value.
    • I would be tempted to leave this effort for after we have agreed on a new API and then part of that implementation would be to develop an API test suite, which could also be used to promote the API as a standard.
      • DRN - The development of acceptance tests for the web interface would be quite different to that for the REST API. Something like Selenium would be needed for the web interface but the REST API could be tested with a shell, Python or even PHP script.

4. REST API Version 2[edit]

Produce version 2 of the REST API and ensure it is truly RESTful. The coding for this will take a fair amount of work but possibly the biggest task is agreeing on an API that everyone is happy with.

  • TSP - This is highly desirable but it has always been considered a LabTrove 3.0 or 4.0 task.
    • Implementation is the easy part but designing the API is the hard part as you have stated.
  • CLB - I'd be interested in helping with the API design, having done a few experiments with the current API. We do have a potentially useful starter in the API that Mark defined for blog3.

5. OpenID Migration Plugin[edit]

This is to allow a site to change its domain name and still retain the accounts created using OpenID logins. This is a particular problem with Google accounts that generate a hash for the user ID based on the domain name amongst other things. DRN has an idea of a solution that is secure and should not be too painful for users or the sysadmin to manage. This would mean we could migrate Sydney's? users off one of our hosted instances to their own hosted instance. Having had to port an old database into the current database, it shouldn't be too difficult to extract the users and content from our database and produce a .sql file that can be imported into a new instance. A redirect plugin has already been written that allows a notebook and it entries to have redirects to their new location.

  • TSP - I think this would be a useful utility.
    • We have had to address this issue more than once.
    • This is related to export(from one notebook) and import (into another on perhaps another Trove).
    • Let's say desirable if not essential.

6. Emailer Plugin[edit]

There has also been a discussion of possibly an emailer plugin to allow emails to be sent out for password resets amongst other things. This may not be applicable for a lot of existing Southampton sites that do not use localdb login but I think potential customers might think it strange that if they choose to manage their logins locally, password reset requests are not possible. Setting up a mail server/relay will vary depending on your institution, therefore we would just point users at existing online guide about how they might go about that. Then they would just need to install the plugin (with a bash script) and configure it as appropriate.

There already exists a messages plugin that tries to send emails. Maybe this can be used as a template.*

  • TSP - It's not just password resets but notification of changes to subscribed notebooks or comments on your own or subscribed notebooks.
    • Desirable but not essential I think.

7. Copy/Move Notebook Entries Plugin[edit]

This is to allow notebook entries to be copied/moved between notebooks. This is an alternative to allowing custom permissions per entry, as this is likely to cause confusion.

Copy would be to take a copy of the current revision and add it to the new notebook. A record of where the original came from would be recorded so the user could be informed if the original had been updated.

Move would reassign all revisions of the entry to new notebook. This is for where the user might have realised they had put the entry in the wrong notebook.

  • TSP - I think this feature is becoming nearly essential if only as a stopgap to fine-grained permission.
    • The ability to keep a private notebook and then copy/move certain entries to a more public one is a good workaround for changing permission.
    • Do it if you can. Be aware though that Move could break existing links to an entry which would be a no-no.
    • Perhaps instead it should e Copy or Share (Copy forks a new copy in the new notebook,
      • Share makes a Link so that revision history is shared but with different permissions).
  • SJC votes for this by e-mail.
  • CLB - Arguably part of the bigger question of export and import. There are some emerging use cases that match the general use case of exporting a set of entries selectively and in a format that can be converted to an exchange format (if I can get away with describing DITA as such) and/or rendered for a specified form of presentation.

When we looked at export a few years ago, selective export - for example using a marker key-value pair - was included in the high-level specification. Justin did some work on export but other things took priority. IMHO, the whole area of export and import, including copy/move, needs the same careful attention to design as is being mooted for the new API.

8. Digital Signatures for Entries[edit]

When a user submits and entry to a notebook they should be able to sign with a digital signature to authenticate that it was then at a particular time that create the entry. This is maily to prove intellectual property, which is not necessarily intended to be a core feature of LabTrove.

  • TSP - We have consistently held the view that Signatures and Witnessing are not an essential requirement of a University Research notebook.
    • Yes, some groups require it but their numbers are small.
    • Yes, guides like the Utah/Atrium list tout signature as an important feature but those guides are influenced by the commercial offerings that all treat IP protection as an important feature.
    • We have had discussions with Amphora about a PatentSafe plug-in which so far have fallen on stony ground. But they could be revived if we really really needed this.
    • Don't spend time on this.

9. RPM for Installing on Fedora-based Systems[edit]

We have a DEB package that can be installed on Debian-based systems such as Ubuntu, Linux Mint and Debian itself. However, there are many institutions that will support RedHat based systems and not Debian, Having an RPM will allow those who want to install LabTrove at such an institution the opportunity to do so.

  • TSP - Desirable if not essential.
    • In order of decreasing importance Scientific Linux, Fedora, RHEL.
    • If it's straightforward then we should do this as it increases the ease of take-up. We've had one person request this afaik.
      • DRN - Also iSolutions would be more prepared to provide support for local LabTrove instances if they are installed on RHEL. This may be helpful if we do not have an active developer to provide support.

10. Additional Logins Plugin[edit]

There are some cases where a site may use one type of login but it would be useful to have one or more users who cannot uses that means of login. E.g. The odd external collaborator that needs to be able to access a notebook.

  • TSP - If this feature were enabled in an LDAP AuthN Trove hosted by an IT Services group and usable by a Trove Admin, then said IT group would certainly object as they could not take responsibility for user management.
    • I don't think this is a good idea for that reason and I don't believe we have had a real life call for this. (Except for perhaps this morning when I thought that the ugchem Trove was LDAP and SJC wanted External Examiners to have access).
      • DRN - I agree, it is difficult to be sure how much call there is for this feature. This task was just trying to define a generic solution for SJC's external examiners' use case. WordPress site allows LDAP and external user login (with local passwords), so it is questionable whether IT services in general would have a problem with this as long as who could create external user accounts was limited, (i.e. to admins).