search

archesproject / arches

Arches is a web platform for creating, managing, & visualizing geospatial data. Arches was inspired by the needs of the Cultural Heritage community, particularly the widespread need of organizations to build & manage cultural heritage inventories
GNU Affero General Public License v3.0
219 stars 144 forks source link

Align user login data and modeled Actor #4824

Open azaroth42 opened 5 years ago

azaroth42 commented 5 years ago

Requested enhancement: A datatype that allows the association to a user account from a modeled Actor (be it a Person or a Group) to then enable further workflow business logic to be implemented.

For example, in DISCO, the person who created an object could be long dead (the artist of a painting), or could be the person who is currently interacting with the system (for when the object is a reference work for experimenting on). The person performing the sampling could be (a) the user and a Person instance (b) a user but not the current user and a Person instance, or (c) just a Person instance. The person that an activity is delegated to which they have yet to perform and document is the same.

In AATA, it is necessary to associate people who are the experts for a particular field of conservation with the classification entry for that field, such that they can be alerted that a new article has been cataloged and would they like to provide an abstract for it. [ ... cough RDM upgrade ...] They need to be in the graph data such that they can be queried and displayed, and in the user data such that their permissions and login system details can be managed.

This is not a request to have graph data to manage user accounts (though that would also solve the problem, with a sledgehammer) just a magic data type that can be used to reference the system id for the user account.

apeters commented 5 years ago

@azaroth42 Can you explain further?
This datatype that you're proposing, what widget would it be used by? Would it be used as a type of resource-instance datatype that would look to the logged in user as a way to present Actor options?

azaroth42 commented 5 years ago

Yes, exactly. Given that the people that have user accounts are also necessarily part of the business data, it makes sense (to me) to be able to have a link between the account and the Actor in the model. This link could be used to:

Does that help clarify?

apeters commented 5 years ago

My thoughts:

  • Fill in the default resource-instance for an Activity to be the Actor that represents the current user. E.g. in DISCO when Odile enters the description of an object that she produced, it would default the Production's carried_out_by to the Actor representing Odile.

This could be handled not by a new datatype, but a new widget that implements the resource-instance datatype. The widget would be configured to be aware of the underlying user management system and be influenced by the logged in user.

  • Prompt for the creation of the Actor instance upon creation of the user to ensure the system isn't out of sync. E.g. we make a user for Odile, and then get pushed over to the Person model.
  • Alert the user when changes to instances that they are related to occur when they login. e.g. Odile sees that the object she produced was added to another project's set of objects.
  • And the same for any other activity, be it comparison, sampling, destruction, etc etc.

These are really more system specific or maybe model specific (as opposed to datatype/widget) logic and would require more detailed user requirements to completely understand how to implement them.

azaroth42 commented 5 years ago

This could be handled not by a new datatype, but a new widget that implements the resource-instance datatype.

That sounds like a good path forward!

These are really more system specific or maybe model specific (as opposed to datatype/widget) logic and would require more detailed user requirements to completely understand how to implement them.

Agreed. I think it'll become clearer when we're further down the road with DISCO and the AATA migration, but the widget above will definitely help to see the (appropriate) possibilities.

azaroth42 commented 5 years ago

On second thoughts, I don't think it's a good idea to reuse the resource-instance datatype. The overloading of the datatype would make import and export very complicated. The internal user account won't have a URI or a JSON-LD representation, but would end up being mixed in with all of the other real resources. We need to be able to export, modify and reimport instances with this feature, and thus the information should be reflected into the JSON-LD import and export APIs, otherwise it will get lost on reimport.

chiatt commented 4 years ago

@azaroth42 If a system user were deleted, would that deletion need to cascade to related actor instances?

azaroth42 commented 4 years ago

That's a good question! I don't think so, as the user-as-model might be related to other instances in the business data, even if they can no longer login or use the system. For example, if Catherine were to leave the Getty and go to the Smithsonian, GCI might remove her account from their system, but they would still want to know what she had done before leaving.