Enhancement #730

Access to ressources in replication and contact

Added by Portier Thomas about 5 years ago. Updated about 4 years ago.

Status:Request For CommentsStart date:
Priority:NormalDue date:
Assignee:Van Hoecke Hélène % Done:

0%

Category:CATALOG
Target version:-
Sponsor: Ergonomic impact:
Functional impact:

Description

Hi,

In the actual version of easySDI, a metadata editor can access to all the ressources (even if the ressources are not published and if the user doesn't have edit or view permission on it) to replicate or fill the contact in the metadata form. I think he should only see its own ressources (same list than in the resource list).

Are you ok with that?

Thomas

resourcelink.png (19.3 KB) Magoni Bruno, 06/09/2014 03:35 PM

import.png (8.41 KB) Magoni Bruno, 06/09/2014 03:35 PM

relations_screen_BE.png (12.6 KB) Mérour Xavier, 06/11/2014 09:59 AM

History

#1 Updated by Mérour Xavier about 5 years ago

Well... it was actually the same behaviour in previous version (easySDI V2) BUT it was also quite annoying for us because a "small resource manager" with 3 resources can have access to hundreds of resources managed on the same platform by others managers.

(If a remember well, it was added in V2 with Bern because of some constraints)

Do we have the same constraints in V4 ?

I would also be in favour of filtering on its own ressources (mask resources from others)

#2 Updated by Magoni Bruno about 5 years ago

Hi to all,

V4 uses the same logic than V2 for the two mentioned use cases:
  • linking resources between themselves through their metadata - see resourcelink.png
  • importing metadata from another resource - see import.png
The goal was to be able to replicate or link other resources that are globally available for an all organisms.
If we limit access only to users own resources, it will break down functionalities like:
  • linking a point of contact which is common to an organism (contact are not managed by any resource's managers)
  • replicating resource which is common to an organism (i.e. any resource's template)

For now access scope is not used for filtering resources in such cases but I guess that it could suit logically part of this need without breaking down existing functionalities.
About replication, the interface allows users filtering resources he wants and we could add complementary filters like toggle buttons "Resources" ("All" or "Mine only").

#3 Updated by Magoni Bruno about 5 years ago

#4 Updated by Mérour Xavier about 5 years ago

Hello !

The goal was to be able to replicate or link other resources that are globally available for an organism.

You are right Bruno... but the current behaviour is not what you describe : resources are globally available for ALL organism (not just yours). In your example (Resource link), I can be in organism A and see all contacts from others organism. The idea is not to restrict access to users own resources but to users organims' resources only.

About replication, the interface allows users filtering resources he wants and we could add complementary filters like toggle buttons "Resources" ("All" or "Mine only").

Good idea...

#5 Updated by Magoni Bruno about 5 years ago

Hi Xavier,

You're right about your note, I've wrong typed my explanation as all resources are available for all organisms.
So to resume, the best way is to apply access scope when exposing resources through resource link and resource replication.

#6 Updated by Mérour Xavier about 5 years ago

Yes, applying access scope is a good thing but I would go further. Here is our proposal :

  • Concerning "linking resources between themselves through their metadata"
    Current situation : any user can access to any contact of any organism
    Target :
    - any user can access only contacts according to their scope of any organism
    - add in the contact list (when editing metadata) the name of the organism after the name of contact (to avoid homonym confusion)
    - in back-end (see relations_screen.png), in the edition of a relation in metadata model, add two options when the child type is "resource type"
    (1) only show resources of the user's organism
    (2) only show resources belonging to the organism of the metadata currently edited
    remark : both options can be set to "true". By adding theses options, the admin can limit the list of child resource available to the user when editing metadatas.
  • concerning "importing metadata from another resource"
    Current situation : any user can access to any resource of any organism and filters on "status", "name" and "resource type".
    Target :
    - any user can access only resource according to their scope of any organism
    - add a new filter "organism" with "my organism" set by default
    - the filter "resource type" should be set by default to the resource type currently in edition

There is a third case :

  • concerning "relation between resources"
    Current situation : any user can add a relation between its resource and others resources of any organism and filters on "status", "name" "id" and "resource type".
    Target :
    - at least apply scopes as well...
    - need some input from Berne maybe ?

#7 Updated by Mérour Xavier about 5 years ago

  • File relations_screen_BE.png added

#9 Updated by Mérour Xavier about 5 years ago

  • File deleted (relations_screen_BE.png)

#10 Updated by Mérour Xavier about 5 years ago

  • Assignee set to Magoni Bruno

@Bruno
Since the proposal is now fully described (https://forge.easysdi.org/issues/730#note-6), may I ask you to change the status to "Request for Comment" ?

#11 Updated by Magoni Bruno about 5 years ago

  • Status changed from New to Request For Comments
  • Assignee deleted (Magoni Bruno)

#12 Updated by Magoni Bruno almost 5 years ago

  • Assignee set to Steering Committee

#13 Updated by Magoni Bruno almost 5 years ago

  • Assignee changed from Steering Committee to Technical Committee

#14 Updated by Magoni Bruno over 4 years ago

  • Target version set to 158

#15 Updated by Magoni Bruno over 4 years ago

  • Priority changed from Normal to High

#16 Updated by Blatti Yves over 4 years ago

We have simplification proposal for note6

1) "linking resources between themselves through their metadata" (for example contacts in metadata) :
  • Current situation :
    • any user can access to any resource of any organism
  • Target :
    • in front-end when editing metadata : add in the resources list (contact list) the name of the organism (to avoid homonym confusion)
    • in back-end (see relations_screen.png), in the edition of a relation in metadata model, add an option when the child type is "resource type" named "restrict linkable resources according to user rights" (yes/no)
      • If disabled: same behavior as 4.2.x : user can select any resources of the platform
      • If enabled: a user can access to the same resources that he sees in "my resources" a
2) "importing metadata from another resource"
  • Current situation :
    • any user can access to any resource of any organism
    • filters on "status", "name" and "resource type".
  • Target :
    • a user can access only resource according to their access scope (from any organism) : same results as in a catalog search for the user...
    • add a new filter "organism" with "my organism" set by default
    • the filter "resource type" should be set by default to the resource type currently in edition
3) "relation between resources" (in database, not in metadata, for example between products and layers) :
  • Current situation :
    • a user can add a relation between its resource and others resources of any organism
    • filters on "status", "name" "id" and "resource type".
  • Target (same logic a N°1):
    • in back-end, in resources type relation, add an option named "restrict linkable resources according to user rights" (yes/no)
      • If disabled: same behavior as 4.2.x : user can select any resources of the platform
      • If enabled: a user can access to the same resources that he sees in "my resources" a
Remarks:
  • [a] displayed resources in this page depends on the roles of the user in different organisms
  • For points 1 & 3: the logic is to propose the same resources to the user in every screens, actual behavior is kind of disturbing
  • For points 1 & 3: we may be able to reuse JModel from Resources, less code, more time for coffee
  • For point 2: Replication is a sort of "copy assistant", a user can copy content from any resources visible in a catalog search by hand. So we propose to use the same logic: Just apply the access scope.
  • We need input from "multi-organisms" easySDI users: Bern? SI17? Others?

#17 Updated by Magoni Bruno over 4 years ago

  • Assignee changed from Technical Committee to Blatti Yves

Need some "éclaircissements"

#18 Updated by Villemagne Jérôme over 4 years ago

As requested by Bruno, here is a point I met.

In the resources list page, you can click on 'Relation' to add children to a resource ; the availble children lists all resources that can be children, even if you don't have any right on it. Then, if you add as children a resource on which you don't have right, it will neither be count in the 'Children list' nor appear on the chilren list page.

#19 Updated by Van Hoecke Hélène over 4 years ago

  • After discussion, the point 3 ("relation between resources") is set aside for the moment.
    A new proposal will be made once some inputs from Bern and others users will be arrived.
  • Precision for point 1 implementation : in back-end, the selection of the option will be made in one selector containing following options :
    (1) only show resources of the user's organism
    (2) only show resources belonging to the organism of the metadata currently edited
    (3) combination of the 2 previous options

#20 Updated by Magoni Bruno over 4 years ago

  • Assignee changed from Blatti Yves to Villemagne Jérôme

#21 Updated by Magoni Bruno over 4 years ago

  • Tracker changed from Feature to Enhancement
  • Assignee changed from Villemagne Jérôme to Technical Committee

#22 Updated by Magoni Bruno over 4 years ago

  • Target version deleted (158)

#23 Updated by Van Hoecke Hélène over 4 years ago

TC keeps this ticket as it is until users inputs on :

3) "relation between resources" (in database, not in metadata, for example between products and layers) :
Current situation :
a user can add a relation between its resource and others resources of any organism
filters on "status", "name" "id" and "resource type".
Target (same logic a N°1):
in back-end, in resources type relation, add an option named "restrict linkable resources according to user rights" (yes/no)
If disabled: same behavior as 4.2.x : user can select any resources of the platform
If enabled: a user can access to the same resources that he sees in "my resources" a

#24 Updated by Van Hoecke Hélène over 4 years ago

  • Priority changed from High to Normal

#25 Updated by Van Hoecke Hélène about 4 years ago

  • Assignee changed from Technical Committee to Van Hoecke Hélène

HVH will ask to AGI about the still opened point.

Also available in: Atom PDF