Remove Finding Aid from Context Menu

[Vicky Phillips]

Hi
Is there a way we can hide the Finding aid from the Context Menu? I can't seem to find a way to do this via the interface.  We're having issues with the time taken to pre-generate them and are therefore considering removing this so that we do not delay going live to the public much longer.  We're also concerned that if we leave the option there for users to generate that their jobs (PDF finding aid generation and CSV exports) will end up in a long queue which could see them waiting a long time for their job to complete.  Just to give you some idea on the scale of our issue we have 16015 top level archives for which we need to pre-generate. The following archive which isn't one of our particularly large archives took 33 minutes to generate the PDF. 
https://archives.library.wales/index.php/iolo-morganwg-manuscripts
I have thought of exporting EAD from AtoM and pre-generating outside of AtoM but the EAD export took 23m41.219s I've not been able to run xslt over this to see how long that takes. But it doesn't look like I'll benefit much from exporting and generating PDFs outside of AtoM.  Anybody else have similar issues?
Thanks,
Vicky

[Dan Gillean]

Hi Vicky,

At this time, there's no way via the user interface to hide the Finding aid generation option from authenticated users. However, public users should *only* be seeing something in the context menu if you've already generated a finding aid - they should not have the option to generate finding aids themselves.

If you intend to make local changes so that no one can see the finding aid options, I can try asking a developer to point you in the right direction in the code - it would take code-level changes to implement.

I'd love for us to be able to look into what makes the EAD export process take so long, and how we can speed up both that and finding aid generation, but that would definitely require an analysis and development project. Much of the export code is old, and would need a good refactor to gain further performance improvements, I'm guessing.

Cheers,

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

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@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/bd529c0a-6503-40a1-b838-981c38cf38c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vicky Phillips]

Hi Dan,

On Friday, 3 February 2017 22:33:11 UTC, Dan Gillean wrote:

Hi Vicky,

At this time, there's no way via the user interface to hide the Finding aid generation option from authenticated users. However, public users should *only* be seeing something in the context menu if you've already generated a finding aid - they should not have the option to generate finding aids themselves.

I need to double check this.  Unfortunately I don't have access to our 2.3 version from home so won't be able to check this until Monday now.  We've set up Shibboleth authentication on our AtoM installation and I think this may put public users into the authenticated group on AtoM.  It's late though and I may be getting confused between Shibboleth authentication and AtoM authentication user group.  I'll check on Monday and let you know what I find out.  

If you intend to make local changes so that no one can see the finding aid options, I can try asking a developer to point you in the right direction in the code - it would take code-level changes to implement.

If you could point us in the right direction just in case we do opt for hiding this for now that would be great.  I have a developer here in the Library who will be able to implement this if needs be. 

I'd love for us to be able to look into what makes the EAD export process take so long, and how we can speed up both that and finding aid generation, but that would definitely require an analysis and development project. Much of the export code is old, and would need a good refactor to gain further performance improvements, I'm guessing.

From what I gather from Dan (developer here in NLW) it's slow due to the huge amount of MySQL queries it is doing. He has started looking to see if he can optimize MySQL anymore.We'll let you know how we get on with that. If you have any other suggestions to try please let us know.

Many thanks,

Vicky

National Library of Wales  

[Dan Gillean]

One of our developers thinks that commenting out the following line should prevent the Finding aid generation options from showing up for all users:

• https://github.com/artefactual/atom/blob/qa/2.4.x/apps/qubit/modules/informationobject/templates/_actionIcons.php#L107

Keep in mind that this means no one will be able to generate finding aids, whether they are authenticated or not!

As for EAD generation, finding aids, and bottlenecks:

The greatest bottlenecks arise from our outdated ORM, Propel. The SQL queries are being handled by Propel, which is not very efficient. The developer I spoke to felt like there were essentially 3-4 possibilities for improving things, which I will list below:

The best option would be to replace Propel 1.x with a more modern ORM. However, like trying to replace the Symfony 1.x PHP framework AtoM still uses, this would be a fairly massive refactoring of the entire application - it is because of Symfony and Propel that we will eventually likely try to find support for creating an AtoM3 - replacing them in the current code base would come pretty close to a total overhaul anyway.

Another option would be to track down the SQL queries that Propel is using, and replace them in some places with optimized raw SQL - that is, skip using the ORM entirely in favor of raw SQL queries. This is not our ideal solution (for one, it further ties AtoM to a specific type of SQL database, as SQL syntax does vary between databases), but it is an approach we have ended up using in some places.

Yet another option would be to identify the worst queries, and move storage of that information to the Elasticsearch index so it can be called more readily without having to hit the database at all.

The only two other thoughts are minor ones:

Apparently PHP7 is much faster. Our 16.04 installation instructions work with PHP7, so you would always try installing that way next time you upgrade and see if it offers you any minor performance improvements. Similarly, if you have the resources, well the faster the system that is running MySQL, the faster these slow queries will be able to execute.

Hope some of that helps a bit! If you feel like your team has successfully introduced some improvements, please do consider sending us a pull request!

Cheers,

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

@accesstomemory

--

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@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/ef2ba4ca-d212-4172-a7ff-5eca40c7777f%40googlegroups.com.

[Vicky Phillips]

Hi Dan
Just to update you on this we've found that this file

apps/qubit/modules/informationobject/templates/_findingAid.php

Contains isAuthenticated which for us allows any authenticated user Staff or Patron access to be able to generate the PDF Finding Aids. We don't wish to allow our public users to be able to generate finding aids. We've therefore just changed this to isEditor instead. So now only the Archivists are able to Generate PDF Finding Aids via the web interface. 

<?php if ($sf_user->isAuthenticated()): ?>
  <li>
    <a href="<?php echo url_for(array($resource, 'module' => 'informationobject', 'action' => 'findingAid')) ?>">
      <i class="fa fa-cogs"></i>
      <?php echo __('Generate') ?>
    </a>
  </li>
<?php endif; ?>

Do you see any problems with us doing this? If not are there also any other places in the system which give permission to isAuthenticated group in the same way, which you think we may want to review?

Thanks,
Vicky

 

[Dan Gillean]

Hi Vicky,

Thanks for sharing this! AtoM does rely on isAuthenticated as a way of keeping the permissions fairly simple, so there may be other places. Authenticated users have access to the Add and Manage menus - though they won't really be able to do much with them. They can however use this to access the Jobs page. Users can only see jobs they have run (except Admins), and all users can only clear jobs they have initiated, so this shouldn't be a problem, but worth being aware of.

I had thought that Authenticated users could also view draft records by default, but a quick test suggests this is not in fact the case. I would double-check this further if I were you - reminder that a search for publicationStatusId:159 should return draft records - and there should be 0 results for an authenticated user not added to any groups if they cannot view draft records by default. 

I'll be curious to hear over time if you experience any performance issues while making this change and/or others. I was just writing up a response to a client about the permissions module, and while not all of it relates directly to this subject, I think it is a useful reminder for context, so I will share it here:

The permissions module is very flexible and granular, so it is true that there might be several different ways to achieve the same results. One important consideration is its age - it was introduced in ICA-AtoM 1.2, when the goal of the project was focused more on supporting the needs of small institutions - so the module was not built with scalability in mind unfortunately, and development to enhance its scalability and performance has not been sponsored since then. We would love to see this improved, but it will be a major project, and so far no institution has prioritized the work.

This means, unfortunately, that as you add more and more permissions, you might eventually encounter issues - pages that will time out before they load, etc - as every node on the page must be checked and checked again against a number of different, inherited and overlapping permission settings.

In general, what I have found is that the more permissions are inherited from above, the more complex it can get, and thus the more likely to affect performance.

Groups exist to make it easier to assign permissions to many users at once. Every registered user is automatically part of the authenticated group, which gives you basic permissions to log in, and "look without touching." When you add a user to a custom group (either one of the defaults, or a new group you've created yourself - say, "Volunteers"), then that group inherits the basic Authenticated group permissions - so now your user in a group has 2 levels of inheritance, plus any custom permissions you assign directly to the user. User permissions will always trump group permissions, just as custom Group permissions will override those of the basic authenticated group - so if we further customize our individual user, now we have 3 layers of inheritance.

By contrast, you could just customize the permissions of the user - so then it is just the Authenticated permissions, which are enhanced/overridden by the individual User permissions. Less inheritance, so hopefully better performance... but also more work to individually set the permissions of each user account.

One of the easiest things we found to keep permissions running smoothly is NOT to restrict View draft permissions for archival descriptions. One of the Canadian provincial portal sites was trying to do this for each of its institutional members, then adding back "View draft" permissions on a per-institution basis for individual users, but many users reported that just trying to view the authority records when logged in would time out (even though they could browse them as a public user just fine). This is because each authority record is linked to a description, and AtoM had to check each node on the page against multiple levels of permissions prior to even loading it... leading to timeouts. Once they gave their users the ability to view drafts back, trusting that their users can act professional, and have no reason to snoop on descriptions in progress (and that every description in the portal site is eventually intended for publication anyway), the situation improved significantly.

All this to say: based on my experience thus far, the simpler you can keep the permissions, and the less inheritance used, the better the performance seems to be. I have not had the time to do rigorous testing to prove this, but based on what we found with portal users, this seems to be the case.

As for how all of this relates to your question:

As we added new functionality, we were aware of this performance deficit, and worried about the performance for even just basic authenticated users if we were adding further restrictions that would have to be checked for them - and how this would cascade down to affect other Groups and individual User permissions. This is why we simply used isAuthenticated for some of these basic permissions - to avoid timeout issues for user accounts.

Those are the main areas affected that I can think of off the top of my head.

Let us know how things go as you experiment with this!

Cheers,

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

@accesstomemory

--

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@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/766199c3-bbed-416c-82c4-6b6de46758ef%40googlegroups.com.