Difference between revisions of "ESciDoc Committer Meeting 2010-05-11"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 75: Line 75:
**granted this role to the user  
**granted this role to the user  
***when filtering for items - situation is changed -> rules which apply to default user are not simply applied, they are extended and user gets much more items then actually needed
***when filtering for items - situation is changed -> rules which apply to default user are not simply applied, they are extended and user gets much more items then actually needed
****the user to which this role is assigned is member of 2 user groups (with no privileges at all) e.g. the following query in filters is applied (note: commented out part is most probably problematic)
****the user to which this role is assigned is member of 2 user groups (with no privileges at all)  
****e.g. the following query in filters is applied (note: commented out part is most probably problematic)





Revision as of 15:00, 10 May 2010

Date: 11.05.2010 Start time: 14:30

Location: Karlsruhe, München phone: +49-89-38602-223

Participants MPDL: Natasa Bulatovic, Michael Franke

Participants FIZ: Dr. Michael Hoppe, Steffen Wagner, Matthias Razum, Harald Kappus

Previous committer meeting

Next committer meetings

Topics[edit]

version history event[edit]

<escidocVersions:version
    xmlns:escidocVersions="http://www.escidoc.de/schemas/versionhistory/0.4"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    objid="escidoc:ex5:1"
    timestamp="2007-11-15T08:36:52.453Z"
    xlink:href="/ir/item/escidoc:ex5:1"
    xlink:title="Version 1"
    xlink:type="simple">
    <escidocVersions:version-number>1</escidocVersions:version-number>
    <escidocVersions:timestamp>2007-11-15T08:36:59.484Z</escidocVersions:timestamp>
    <escidocVersions:version-status>released</escidocVersions:version-status>
    <escidocVersions:valid-status>valid</escidocVersions:valid-status>
    <escidocVersions:comment>Status changed to released for Item escidoc:ex5.</escidocVersions:comment>
    <escidocVersions:events>
        <premis:event
            xmlns:premis="http://www.loc.gov/standards/premis/v1"
            xmlID="v1e1">
            <premis:eventIdentifier>
                <premis:eventIdentifierType>URL</premis:eventIdentifierType>
                <premis:eventIdentifierValue>/ir/item/version-history#v1e1</premis:eventIdentifierValue>
            </premis:eventIdentifier>
            <premis:eventType>http://purl.org/escidoc/infrastructure/event-type/release</premis:eventType>
            <premis:eventDateTime>2007-11-15T08:36:59.484Z</premis:eventDateTime>
            <premis:eventDetail>Status changed to released for Item escidoc:ex5.</premis:eventDetail>
            <premis:linkingAgentIdentifier
                xlink:href="/aa/user-account/escidoc:exuser1"
                xlink:title="System Administrator User"
                xlink:type="simple">
                <premis:linkingAgentIdentifierType>http://escidoc.org/identifier-types/user</premis:linkingAgentIdentifierType>
                <premis:linkingAgentIdentifierValue>escidoc:exuser1</premis:linkingAgentIdentifierValue>
            </premis:linkingAgentIdentifier>
            <premis:linkingObjectIdentifier>
                <premis:linkingObjectIdentifierType>http://escidoc.org/identifier-types/item</premis:linkingObjectIdentifierType>
                <premis:linkingObjectIdentifierValue>escidoc:ex5</premis:linkingObjectIdentifierValue>
            </premis:linkingObjectIdentifier>
        </premis:event>
    </escidocVersions:events>
</escidocVersions:version>

create new role[edit]

  • how to create a new role in the core-service with a policy that does not refer to the core service resources?
  • e.g.
    • created new policy with scope
        <role:scope unlimited="false">
		<role:scope-def resource-type="cone-service"/>
	</role:scope>
    • first case: provided very dummy policy that applies to schema, however no login of any user was possible afterwards
      • after deletion of all related data users could log-in
    • second case: provided policy with action to retrieve contexts only
    • granted this role to the user
      • when filtering for items - situation is changed -> rules which apply to default user are not simply applied, they are extended and user gets much more items then actually needed
        • the user to which this role is assigned is member of 2 user groups (with no privileges at all)
        • e.g. the following query in filters is applied (note: commented out part is most probably problematic)


SELECT count(r.id) FROM list.item r WHERE (
  (
    (
      (
        (
          r.id IN (
            SELECT resource_id FROM list.property WHERE local_path='/properties/version/status' AND value='released'
          )
        )
      )
    )
  /*  OR (
      (
        r.id IN (
          SELECT resource_id FROM list.property WHERE EXISTS (
            SELECT object_id FROM aa.role_grant WHERE user_id='escidoc:102002' AND role_id='escidoc:107021' AND (
              revocation_date IS NULL OR revocation_date>CURRENT_TIMESTAMP
            )
            AND (
              object_id IS NULL OR object_id=r.id
            )
          )
          OR r.id IN (
            SELECT resource_id FROM list.property WHERE EXISTS (
              SELECT object_id FROM aa.role_grant WHERE (
                group_id='escidoc:107001' OR group_id='escidoc:107006'
              )
              AND role_id='escidoc:107021' AND (
                revocation_date IS NULL OR revocation_date>CURRENT_TIMESTAMP
              )
              AND (
                object_id IS NULL OR object_id=r.id
              )
            )
          )
        )
      )
    ) */
  )
)
AND (
  r.id IN (
    SELECT resource_id FROM list.property WHERE local_path='/properties/context/id' AND value='escidoc:persistent3'
  )
)
LIMIT 1000