-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test and review GUI documentation #84
Comments
Collaborative input during the course of the sprint from all @Islandora-Labs/7-x-2-x-sprinters |
please assign to me! i'm assuming what needs to happen here is review and revise (if necessary) the labels for https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/drupal/islandora/include/fields.inc |
two suggestions @manez @ruebot fedora:hasParent Repository Path Parent Object Persistent Identifier (PID) Parent Object PID |
@kimpham54 there are no PIDs in fcrepo4 😉 |
@daniel-dgi should we even be exposing this in the form? I'm having second thoughts about this now. |
field_permissions and field_read_only. only way those should get set is async in response to a fedora event. should be viewable by admin, and whoever else you feel is privileged. |
I guess we're not using the word 'object' either now, but resource Resource Path Parent Resource |
@daniel-dgi: I second @ruebot that those fedora stuff should not be displayed, instead it should display Drupal related information, e.g. parent resource should show a link to the parent drupal node |
I'm actually fine with it being displayed, so long as it is read only, and available to appropriate users like @daniel-dgi said. |
@sprklinginfo: so this actually touches on a larger issue of identity. which is to say that the identity of the resource is really the drupal node, not the fedora resource. i'm hoping there's a way we can solve this with LDP on the fedora side. if not, our options are a conversion layer (gross) or simply managing the relationships in drupal (less gross). both are doable, neither is preferable. but either way, i'm on your side about this. pcdm:hasMember should be a link to another drupal node. for sure! |
@daniel-dgi but should pcdm:hasMember link to the drupal node? shouldn't it link to the fedora uuid of the object, because that is real, persistent link to the resource? |
won't it lose the context to drupal if the node is stored in fedora? especially if these objects might be shared across multiple drupal sites/diff repositories |
@ruebot: From an end user point of view, I want to a clean and simple UI. those fedora related stuff should be hidden in the back to make things less confusing. and in production environment it is probably not a good idea to display links to our storage server either. Of course, Admins should be able to verify/access those fedora fields in 'manage' view? |
@sprklinginfo agreed. I'd only want to see this information in a manage view. |
End-user++ for what @sprklinginfo said. Keep the scary stuff out of the ingest form :) |
@sprklinginfo++, about the mapping, i'm looking at options, because it's wrong to say that the drupal node (or entity) is the same as what is stored in Fedora4. It's a representation of that, right? |
@DiegoPino : in current stage, does each durpal node (a collection or a basic image) have its counterpart in fedora? or I misunderstood.. |
@sprklinginfo, no, you understood correctly. I expressed myself bad. It's a not useful semantic conversation i started for this stage of the project. my mistake. Don't worry, you are fine 😄 |
Closing d7 related issues since we're moving to 8. |
We get to use Add Content and Content Types to add objects to Islandora, which is awesome. It also makes writing field-level instructions & hints super easy and available through Drupal (as seen where it says "Path to resource in Fedora 4" in the image below).
Someone (or multiple someones) should go through from an end-user perspective and evaluate where these can be improved or expanded.
The text was updated successfully, but these errors were encountered: