ESciDoc Developer Workshop 2009-04-28

ESciDoc

Date: 28.04.2009 Start time: 14:30

Location: Karlsruhe, München (Video conference)

Participants MPDL: Wilhelm Frank, Natasa Bulatovic

Participants FIZ: Matthias Razum, Harald Kappus,

=workshop=
 * Previous workshop
 * ESciDoc_Developer_Workshop_2009-04-21


 * Next workshops
 * ESciDoc_Developer_Workshop_2009-05-05
 * ESciDoc_Developer_Workshop_2009-05-12

=Agenda=

VidConf 12.05
is going to visit the MPDL. The appointment is scheduled from 14:00 to 16:00. MPDL will not be able to use the VidConf room. Teleconf or postpone?
 * on Tuesday 12th May 2009 the Vicepresident of the MPG

Filters etc..

 * temporary tables for group grants (not clear how groups are structured/validated)
 * explanation/discussion why so many temporary tables created during runtime
 * not testable
 * filter for contexts check the privileges for all roles in the query even the exact role in the filter is given (if user accidentally has another role for a context, for which the filter role is not requested - wrong results again)
 * filter: XML filter: filter={/properties/type=[PubMan]}, limit=1000, offset=0, order=, direction=ASC, member=null, objectType=null, parent=null, roleId=escidoc:role-moderator, topLevelOnly=false, userId=escidoc:user2
 * queries for: role-md-editor, role-administrator, role-moderator etc... i.e. for each role this user has been assigned with

Outcome

 * FIZ agreed that temporary table solution is cumbersome and not stable
 * temporary tables staying in PG is a bug that has to be checked
 * using temporary tables was due to possible many group assignments
 * MPDL does not see it as an issue
 * MPDL proposes to have not temporary table but "in (id1, id2, id3)" query clause appended
 * FIZ agrees it would be better
 * FIZ will check the possibility of stored procedure to calculate this string
 * FIZ will provide feedback on possiblity by end of the week
 * Absolutely important to run stable in 1.1

Security issues

 * ingestion example
 * ingestion is asynchronous process
 * need possibility to "clone" own user handle (to work even after user logs-out)
 * ticket http://www.escidoc.org/jira/browse/INFR-656
 * everyone can see user account

Outcome

 * Better option:
 * FIZ: check if the ingest tool can do it with setting up the users
 * MPDL: can change the pubman ingestion workflow
 * retrieve user account via REST interfaces is a bug (as logged-in user able to retrieve other user)
 * test: not possible, user with which it was tested had Administrator account for a context /but that should be not possible/

GetGrants

 * contained in build, tested and documented

status v1.1 RC2

 * last dev Build 481, 27.4.09
 * next build

Open bugs

 * http://www.escidoc.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10012

VidCo on 23.6.

 * we might need to shift this Workshop
 * 24. in the afternoon? No new Info

Release v.1.1

 * features: http://www.escidoc.org/jira/secure/IssueNavigator.jspa?requestId=10012
 * contained in v1.1 RC1
 * SuperSuper user reset tool
 * Group handler
 * fulltext indexing for Japanese text
 * OAI-PMH, pre-defined sets
 * contained in v1.1 RC2
 * Organizational unit history
 * OAI-PMH, user-defined sets
 * PID Manager support for GWDG Handle system
 * Japanese fulltext indexing (but: open issues?)
 * Collaborator modifier role (in work)
 * GetGrants interface (in work)
 * Group handler tickets (fix) (in work)

Release v.1.2

 * release date: August 2009
 * features: http://www.escidoc.org/jira/secure/IssueNavigator.jspa?requestId=10013

Already in 1.1

 * (1) File checksum calculation (already included in 1.1)
 * (1)Retrieval of the list of current grants of a user/content object (already included in 1.1)
 * (2)OAI-PMH (already included in 1.1)

Prio 1

 * (1)assign Collaborator-modifier role to all containers in the tree below a selected container
 * (1)Handling of additional user attributes
 * we need a place to store external person ids in a user account
 * (1)Migration from v1.1 to v1.2 and related topics
 * (1)Language for Filter Methods
 * or administrative search (Solr?) other solution?
 * (1) Backup/Restore procedures productive readiness
 * see ESciDoc_Developer_Workshop_2009-03-24
 * (1) Other productive readiness issues
 * enable incremental recache/reindex (i.e. ingesting of new data should not recache/reindex complete repository)

Prio 2

 * (2)Ontology Manager+Searching within Tags
 * ESciDoc_Developer_Workshop_2008-12-02
 * Talk:ESciDoc_Content_Relations
 * Talk:ESciDoc_Content_Relations
 * (2)Surrogate objects
 * (2)Organizational Units don't need to be unique (within a parent)

Prio 3

 * (3)Content Model / Content type definition schema
 * (?)Create separate SQL scripts for user account initialization to support different needs of eSciDoc users