Records in Draft format

[Daniela Moneta]

AtoM seems to fit our needs perfectly but I still am not sure if our organization can use AtoM for our online catalog. I have been cataloging on AtoM for a couple of years leaving all records in draft so that they are not visible to the general public. Our records are in draft form because we are a private non-profit organization that wants our catalog to be for members only. Before I go any further cataloging this collection, I would like to know if you plan to add functionality so that unauthenticated users cannot see published records. We would like the catalog to be viewable by authenticated users only. Do you plan to add additional access controls to the permissions module to limit what unauthenticated uses can view?

Thanks for your help,

Daniela Moneta, MLIS

World Subud Association

[Dan Gillean]

Hi Daniela,

We would love to see a Draft/Published publication status added to more entities (such as terms, authority records, repositories, etc) so users have more control over visibility. Right now you can control the permissions for the public users  - they are the anonymous group in Admin > Groups - but when restricting permissions this way (for example, restricting the view permissions for authority records), users can still get to search and browse pages, and they only run up against the permission restrictions when they click on an individual record and try to go to its view page.

Over the years, there has been a lot of interest in seeing the permissions module overhauled, and to see a publication status setting added to other entities, and we see these as important and useful developments for the AtoM project. However, I cannot guarantee at this time that they will be included in a future release, because that depends entirely on our user community.

As you may know, we manage to maintain AtoM and regularly issue new releases with many new features and bug fixes, as well as provide all our documentation and additional resources under open licenses, thanks to our community driven development model. While Artefactual will invest the time to fix bugs, prep and test releases, write documentation, answer user forum questions, provide presentation materials and more free of charge to our community of users, we manage to sustain ourselves as a company (and by extension AtoM itself) by offering additional paid services - including development, which we then merge into the next public release. Because this model means that we are giving away our core business assets for free for the benefit of the community, we don't have the resources to take on major feature development without community support - either in the form of feature development sponsorship, or via collaborative community code contributions. You can read more about this model on our wiki here:

• https://wiki.accesstomemory.org/Development/Philosophy

All this to say: if enhancing the publication status to other entities, or improving the permissions module is a priority to your institution, I would strongly urge you to consider ways that your institution can help to support its development. This is the only way that features and major enhancements get added to the project. If your institution does not have the resources to sponsor a feature alone, we have worked on collaboratively sponsored features, where several institutions pool resources and requirements. What Artefactual needs in such a case is a single point of contact - one institution who will act as the primary contact for coordinating requirements, testing, feedback, and sponsorship.

If you can clarify the exact requirements you need and are interested in working with Artefactual to sponsor a feature, please feel free to contact me off-list, and we can discuss your particular use case in greater detail and prepare a development estimate. We are happy to share these estimates publicly with other community members as well if you like, so other interested institutions might consider sponsoring (or co-sponsoring) the work.

In the meantime, there are several institutions we know of who use AtoM internally. Have you considered simply adding HTTP authentication to the site, so that a user name and password is required to access your AtoM instance? This way, it is not publicly available, and you can distribute the initial HTTP authentication password to members, without having to actually give them a login to the AtoM site itself. This can be easily set up by a system administrator deploying the site, and might be an option that would meet your needs - that way you can continue to use the Draft status to hide records that aren't yet ready for even your members to see. Some links for more context:

• Basic overview from Wikipedia: https://en.wikipedia.org/wiki/Basic_access_authentication
  
• This page is for a proprietary product, but it explains HTTP basic authentication well, and includes and demo example you can click on: https://www.httpwatch.com/httpgallery/authentication/
• Another good overview: http://qnimate.com/understanding-http-authentication-in-depth/
• From the PHP manual - how to set up basic authentication with PHP: http://php.net/manual/en/features.http-auth.php
  

Regards,

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/4b4a7263-a5cc-4579-889a-fcf88f466885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.