Skip to first unread message

David

unread,
May 23, 2016, 8:23:02 AM5/23/16
to ICA-AtoM Users
Hi,

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:
  1. Browse archival descriptions
  2. Select one description
  3. Click the "Add new"-link (for example: http://demo.accesstomemory.org/informationobject/add?parent=%2Faaron-moulton-fonds)
  4. 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>

https://github.com/artefactual/atom/blob/qa/2.3.x/apps/qubit/modules/informationobject/templates/_editActions.php#L8

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"

  1. Browse Subjects/Places
  2. Select one
  3. Click "Add new"
  4. 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:

  1. Select an archival descriptions with a lot of descendants (I selected one with 100k children)
  2. 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

unread,
May 23, 2016, 5:53:39 PM5/23/16
to ica-ato...@googlegroups.com

--
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.



--
Jesús García Crespo,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

David

unread,
May 24, 2016, 8:31:33 AM5/24/16
to ICA-AtoM Users
Already with PRs. That was fast. Thanks!

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

unread,
May 24, 2016, 10:32:53 AM5/24/16
to ICA-AtoM Users
I remembered that there is a thread about "some thoughts" https://groups.google.com/forum/#!topic/ica-atom-users/MMsFettgGSU
You can also answer there if you think that that thread would be a more proper place.

Regards

Dan Gillean

unread,
May 24, 2016, 12:57:39 PM5/24/16
to ICA-AtoM Users
Hi David,

You managed to catch one of our developers working on the 2.3 release, so we've addressed the bugs you identified as part of that. Thanks again for your report.

Regarding your suggestions, thanks for you input! I think that overall, these are great ideas. We do already make a few changes in the application when multi-repository = no. For example, the institutional scoping in the global search box is removed, institution is removed as a facet, and the options in the Repository drop-down in the advanced search panel are removed. There are certainly ways that these behaviors could be extended and improved.

I'm not sure I would want to make the repository field populated by default in new archival descriptions, unless we could set it up so it only occurred with new top-level records - we already have enough users explicitly linking the repository at all levels (and causing performance slow-downs as a result), and I wouldn't want to put the burden on the user to remember to remove it every time a child description is created. I also think that we'd have to think carefully about making the add repository form part of the installation - AtoM doesn't explicitly enforce the need for a repository (you might get warnings depending on your standards template, but it is not required), and we are constantly surprised by the use cases our community presents to us: ways of using AtoM that often had not occurred to us! Similarly, the installation and configuration process is long enough already, and often carried out by different users (e.g. a system administrator, and IT department, a hosting provider) than the people who will be creating the records.

The University of Saskatchewan has been interested in supplementing the ability to remain within a specific institution's holdings when browsing in a multi-repository system - you might find some of their ideas interesting. There is a long-running discussion with some mockups on this issue ticket in the AtoM wishlist:

See also:

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,


Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

Tim Hutchinson

unread,
May 24, 2016, 7:14:52 PM5/24/16
to ICA-AtoM Users
Hi Dan,

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

unread,
May 24, 2016, 8:39:52 PM5/24/16
to ICA-AtoM Users
Great points, Tim, thanks!

Relevant documentation link:

Cheers,


Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

David

unread,
May 30, 2016, 11:19:11 AM5/30/16
to ICA-AtoM Users
Hi Dan,

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)"
Because I knew about the performance issue I thought that it should be easy to check if a new description has the same repo as the parent (unless top-level) and remove it inside the action before persisting it:
  1. POST -> server
  2. informationObject o = POST
  3. if (o.repo != "" && hasParent(o) && o.repo == getParentRepo(o)): o.repo = ""
  4. o.save()
Can you do something like that - also for multi-repo=yes - to prevent the performance issue?
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

unread,
Jun 6, 2016, 6:12:58 AM6/6/16
to ICA-AtoM Users
Hi,

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

unread,
Jun 24, 2016, 7:03:53 AM6/24/16
to ICA-AtoM Users
Hi again,

It seems like there is an issue with the CSV-import (using the UI):

Missing 'script' and 'scriptOfDescription':
  1. Import example ISAD csv from https://wiki.accesstomemory.org/images/0/0b/Example_information_objects_isad-2.3.csv
  2. Browse archival descriptions
  3. 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

unread,
Jun 24, 2016, 1:59:01 PM6/24/16
to ica-ato...@googlegroups.com

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.

Dan Gillean

unread,
Jun 24, 2016, 4:46:59 PM6/24/16
to ICA-AtoM Users
Hi David,

Interesting... regarding the typo: I did notice this long-standing error in the CSV templates, and sought to correct it in this commit a few months ago:

... 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!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

David

unread,
Jun 27, 2016, 8:38:24 AM6/27/16
to ICA-AtoM Users
Thanks, now it works.

Another issue regarding the settings after purging data. I checked it with two settings but I guess they are not the only ones:
  1. Set 'Default repository browse view' to 'table' inside global settings | Set 'Multiple repositories' to 'no'.
  2. 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.
  3. Check global settings. browseView=card | multi-repo=yes.
  4. Browse Archival institutions | Go to advanced search
Expected: Card view | repository selection
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

unread,
Jun 27, 2016, 12:48:05 PM6/27/16
to ICA-AtoM Users
2 more minor issues:
  1. Broken Cancel link inside physicalobject/add (http://10.10.10.10/;physicalobject)
  2. CSS bug inside actor/add for 'Dates of existence' helper text (no rendering issues with FF. add word-wrap?)

Dan Gillean

unread,
Jun 27, 2016, 7:05:40 PM6/27/16
to ICA-AtoM Users
Hi David,

Thanks for these reports!

Regarding the purge error - I think you're probably right that it's a caching issue. The task is only designed to purge the database - you may need to manually try clearing your cache and restarting other caching elements (php5-fpm, memcached, etc). For now, I've clarified this in our documentation a bit, with a suggestion to do so in the admonition at the end of the section:

Regarding your other 2 reports, I've filed issues for them here:

Cheers,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

Reply all
Reply to author
Forward
0 new messages