--
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.
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.
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,
--
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.
<?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; ?>
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.
--
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.