David
There is an issue with the "Cancel"-link below the create form for a new informationobject with a parent set.
Reproducible with demo version and 2.3:
- Browse archival descriptions
- Select one description
- Click the "Add new"-link (for example: http://demo.accesstomemory.org/informationobject/add?parent=%2Faaron-moulton-fonds)
- Click "Cancel"
Expected result: Index page of the selected description (2.)
Actual result: Create form with URL: http://demo.accesstomemory.org/informationobject/copy?
Possible fix (but I guess it the problem is somewhere else):
Replace
<li><?php echo link_to(__('Cancel'), array($resource->parent, 'module' => 'informationobject'), array('class' => 'c-btn')) ?></li>
with
<li><?php echo link_to(__('Cancel'), $sf_request->parent, array('class' => 'c-btn')) ?></li>
The "Add new" link inside the description/subjects/places page is for creating a hierarchy? If I am right why don't go back to a selected item after clicking "Cancel"
- Browse Subjects/Places
- Select one
- Click "Add new"
- Click "Cancel"
What I was expecting: Index page of selected item
Actual result: Browse page (index.php/subjects)
There is also a problem deleting descriptions with many children because the confirmation page has no paginator. I think this also happens with both AtoM versions:
- Select an archival descriptions with a lot of descendants (I selected one with 100k children)
- Click "Delete"
Error Output:
It has 100005 descendants that will also be deleted:
Fatal error: Allowed memory size of 536870912 bytes exhausted...Regards,
David
Jesús García Crespo
--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a92064f8-7305-4924-a56c-5584b6fc218b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056
David
What about following for running AtoM for a single repository?
- Let the user define the single repository
- Inside settings (for example: if user selects multiple:no -> input field appears)
- As install setup step (the complete Add -> Archival institution form can be displayed)
- Change Browse -> Archival institutions so it links to the index page of the single repo (no browse page)
- Although it wont be a browse page any more I think it would be better than removing this link
- Remove "Add new" link inside the index page
- Remove Add -> Archival institution
- Pre-selected repo inside forms (may be removed because of inheritance before saving)
- ... (there may be more)
What do you think about it?
Regards,
David
David
You can also answer there if you think that that thread would be a more proper place.
Regards
Dan Gillean
See also:
- https://projects.artefactual.com/issues/6876
- https://projects.artefactual.com/issues/6166
- https://projects.artefactual.com/issues/6167
So far as I know, USask is still interested in completing this development and contributing it to the public project, though I haven't heard any updates as to the status of this in a while.
As ever, we welcome pull requests if you would like to try implementing any of your suggestions! Let us know if you have any questions for our developers, they'll try to point you in the right direction if you're not sure how best to implement something.
Cheers,
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4c32f251-f8c3-40f9-9003-495100702ac8%40googlegroups.com.
Tim Hutchinson
Indeed, this is now under active development and I'll be talking about this feature during the AtoM session at the upcoming Association of Canadian Archivists conference.
I definitely agree that populating repository by default would be useful, even for multi-institution sites (where the user has permissions on only one institution). Among other things this would avoid the accidental creation of duplicate repositories. But I take your point about the complexity of that. Maybe it would work to configure which level would get the default setting?
David, a couple quick thoughts about single-institution installs. The feature we're working on is focused on allowing a "virtual" institutional database for multi-institution installs, but I wonder if there might be aspects useful for a single institution install. In particular, this feature will add the institutional logo to most pages (as currently available on the description view page), so that will serve as a link back to the repository page. In terms of your suggestions about changing and removing links, I haven't tested, but I think you'll find you can do most of that (e.g. changing the behaviour of the repository browse link) without any changes to the code, by configuring the menus. You can also move menu items around, e.g. move add repository to the admin menu so that regular users don't see it.
Tim Hutchinson
University of Saskatchewan
Dan Gillean
Cheers,
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/b8d6bb71-a0e9-46e0-aebc-f45f35197b28%40googlegroups.com.
David
Thanks for the links. I will have a closer look the next days.
Regarding the performance issue for linking the repo at all levels:
"Pre-selected repo inside forms (may be removed because of inheritance before saving)"
- POST -> server
- informationObject o = POST
- if (o.repo != "" && hasParent(o) && o.repo == getParentRepo(o)): o.repo = ""
- o.save()
With that the descriptions can have a pre selected repo at all levels.
If multi-repo=no and a default repo exists a hidden repo would also make sense to me because if multi-repo=no the users will know their repo if they create new descriptions and don't need to see it every time.
Regarding defining a default repo:
Defining the default repo as installation step also don't need to be enforced after selecting single repo but I didn't think of the possibility that an installation can be carried out by different users so I agree that this is not a good choice.
I also agree with Tim that a default repo also for multi-repo=yes could be very useful. After thinking about what Tim mentioned that a user/group could have permissions on only one institution (other user = other default repo) I guess the best place for difining/selecting default repos is somewhere inside the user/group settings?
Btw I think pull requests won't be that easy in my case any more because I've already changed almost all app templates and plugin templates (and other files too).
(*BUMP* https://groups.google.com/d/msg/ica-atom-users/cG1sj9LOWR0/c7UlmFeVEgAJ - would be nice)
Jesus, I have pulled the latest commits (https://github.com/artefactual/atom/commit/91d2901492600d0e1b683d081ba73606dbe43712) and I think the delete issue still occurs.
Deleting a description with < 200 descendants works but not with >100k.
A new issue I have already solved.
After restarting my VM Elasticsearch suddenly does not start any more. Error msg inside /var/log/elasticseach/elasticsearch.log after "sudo service elasticsearch restart":
[2016-05-30 15:51:48,786][INFO ][node ] [Karma] version[1.3.9], pid[3584], build[0915c73/2015-02-19T12:34:48Z]
[2016-05-30 15:51:48,787][INFO ][node ] [Karma] initializing ...
[2016-05-30 15:51:48,803][INFO ][plugins ] [Karma] loaded [action-updatebyquery], sites [browser]
[2016-05-30 15:51:50,300][ERROR][bootstrap ] {1.3.9}: Initialization Failed ...
- ExecutionError[java.lang.NoClassDefFoundError: org/elasticsearch/action/support/ActionFilters]
NoClassDefFoundError[org/elasticsearch/action/support/ActionFilters]
ClassNotFoundException[org.elasticsearch.action.support.ActionFilters]
I think this happened because of a conflict with one of the latest Ubuntu (14.04) updates I have installed.
As you can see I was using the old 1.3.9 version. After upgrading to 1.7 it is working again. So maybe 1.3 is not supported any more. If so you should update your minimum requirements ("1.3 or newer")
Regards,
David
David
one more thing I've noticed.
Inside term/index there are two <div id="content">. As far as I can remember I've seen that you handle this inside your code and maybe this will never lead into a problem but I think this is sill bad practice and I would think about changing one of these IDs.
Regards,
David
David
It seems like there is an issue with the CSV-import (using the UI):
Missing 'script' and 'scriptOfDescription':
- Import example ISAD csv from https://wiki.accesstomemory.org/images/0/0b/Example_information_objects_isad-2.3.csv
- Browse archival descriptions
- Scripts are missing
Typo inside csv file?:
The second item has 'en_fr' as content for scriptOfDescription. This should be 'en|fr' ?
Regards,
David
Hutchinson, Tim
It looks like the issue is that the value for the scripts needs to have leading uppercase (e.g. Latn not latn). En and fr are not a valid example of scripts at all. So if you use Latn, or Latn|Cyrl, script will import correctly. So will script of description, but it’s possible that field is not currently in the template (at least I don’t see it).
A related issue: if the incorrect value is imported, it looks like you need to edit the record twice before you can edit the script value. I’ve run into a similar issue (going back to 1.3), in this case for language, when the serialization is blank in the property.i18n table.
Tim
--
You received this message because you are subscribed to a topic in the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ica-atom-users/KTfkg4D43NE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
ica-atom-user...@googlegroups.com.
To post to this group, send email to
ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/2755ba48-cf48-4358-a5ee-e4886fb2aa8b%40googlegroups.com.
Dan Gillean
... Only while it looks like I fixed the script field, I somehow neglected the scriptOfDescription in my corrections :(
As Tim noted, the value for the script of description should in fact be a 4-letter ISO 15924 script code, e.g. Latn, Cyrl, Copt, etc. I'm working on correcting this now - thanks for the catch!
In the process of doing so, I've also taken the time to add the field name and number from the related standard to each column value - so it will be a bit more useful for archivists doing mapping.
Once this PR is reviewed and accepted, I'll upload new versions to the wiki.
Thanks again for reporting this... not sure how I missed it the last time!
David
Another issue regarding the settings after purging data. I checked it with two settings but I guess they are not the only ones:
- Set 'Default repository browse view' to 'table' inside global settings | Set 'Multiple repositories' to 'no'.
- Purge data (purge --demo), cc, php restart, nginx restart -> default repo browse view should be 'card' because this is the default setting | multi-repo should be yes.
- Check global settings. browseView=card | multi-repo=yes.
- Browse Archival institutions | Go to advanced search
Actual result: Table view. I can see an active table button and the table headers. | No repo selection
It works as expected after saving the settings without changing anything or after restarting the vagrant box so this is most likely a caching issue (redo https://github.com/artefactual/atom/blob/qa/2.3.x/lib/model/QubitSetting.php#L70 after purging?).
Regards
David
- Broken Cancel link inside physicalobject/add (http://10.10.10.10/;physicalobject)
- CSS bug inside actor/add for 'Dates of existence' helper text (no rendering issues with FF. add word-wrap?)
Dan Gillean
Regarding your other 2 reports, I've filed issues for them here:
Cheers,