Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.


If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping


Answers may be delayed for posts that do not include sufficient information.

2020-02-20 Bug Report for Login Issue on Providence 1.7.8

To Whom It May Concern,

This is a bug report for Collective Access’ Providence version 1.7.8 platform. Please consider the below sections. Thank you.

SECTION 1. GENERAL AND TECHNICAL BACKGROUND INFORMATION.

I am performing work as a systems analyst for the Morgan-Manning House, a local historical site in Western New York. To evaluate Collective Access as a collections management software solution, I have installed Collective Access' Providence and Pawtucket platforms. These platforms are based in space maintained with WampServer’s version 3.2.2.5, the latest version, on a Dell laptop running the Windows 10 64-bit operating system on an x64-based processor with a clock speed of 2.70 GHz and 12.0 GBs of RAM. WampServer’s localhost space is being accessed using Version 80.0.3987.116 of the Google Chrome web browser, that browser’s latest 64-bit official build.

SECTION 2. DESCRIPTION OF ENCOUNTERED ISSUE.

  1. When I installed the Providence platform, errors were presented during the installation process itself (see “ATTACHMENT_1”).

  2. Whenever WampServer is first opened during a session (e.g. after the laptop boots), or closed and then restarted during a session without cached Providence user logins, navigating to “localhost/mmh/providence-1.7.8,” the directory for Providence, produces the screen shown in “ATTACHMENT_2.”

  3. Simply hitting the “refresh” option on the Google Chrome browser window produces the expected Providence login screen (see “ATTACHMENT_3”).

  4. However, when the user logs in with valid credentials, the screen shown in “ATTACHMENT_4” appears and presents only three errors on lines “1504,” “1508,” and “1549.”

  5. If the user again hits the “refresh” option on the Google Chrome browser window, a popup is shown which reads “Confirm Form Resubmission [/] The page that you’re looking for used information that you entered. Returning to that page might cause any action you took to be repeated. Do you want to continue?”

  6. Hitting the “Continue” button on this popup leads the user to “ATTACHMENT_5,” a modified version of the Providence login screen which contains an added line that reads “CSRF token is not valid.”

  7. If the user disregards the added line and again attempts to login using the same credentials, the software permits this login but returns an errored version of the Providence dashboard (see “ATTACHMENT_6”).

  8. If the user yet again hits the “refresh” option on the Google Chrome web browser, the typical and fully-functioning Providence dashboard is presented (see “ATTACHMENT_7”).

SECTION 3. ATTEMPT TO REMEDY ENCOUNTERED ISSUE.

I used Google to locate the following support page:

https://collectiveaccess.org/support/index.php?p=/discussion/300333/warning-continue-targeting-switch-is-equivalent-to-break-php-7-4-1-on-xampp-windows

In response to reportage of a similar issue, the Collective Access representative “seth” wrote the following response:

“Hi,

The develop branch deals with this issue, which first popped up in PHP 7.3. If you want to pull code from the develop branch on GitHub it should resolve this. Note that we haven't tested with PHP 7.4 just yet, but intend to do so in the next few weeks.

seth”

Accordingly, I visited https://github.com/collectiveaccess/providence/tree/develop and downloaded the version of Providence from that source. When I attempted to implement this version, however, I encountered new issues not present during my initial installation of the “release” version.

While I am reasonably competent with respect to computing, I am not so familiar with the distinctions between the GitHub “develop” distribution and the GitHub “release” distribution as to “pull code,” as “seth” suggests, which I interpreted as an indication that I should selectively apply some components of the “develop” distribution with others from the “release” distribution.

Because my download of the “develop” version introduced new problems respective to “vendor libraries,” as I recall, and because I do not know how to use the “develop” version to resolve the originally-encountered login issue documented in Section 2, I discarded the “develop” implementation of Providence and reverted back to the “release” distribution’s implementation.

SECTION 4. SIGNIFICANCE OF BUG REPORT AND REQUEST FOR ASSISTANCE.

My reversion to the “release” distribution was successful, but the encountered issue which I documented in Section 2 persists. While the login process is very cumbersome and annoying, the Providence platform remains functional for demonstration purposes and evaluation after performing the eight steps outlined in Section 2.

I have discussed this matter with my supervisor, and unless this issue is resolved, the Morgan-Manning House will not consider Collective Access as a potential collections management software solution. Collective Access’ representatives will hopefully understand this position, as it is very difficult to objectively consider the comparative merits of a program which consistently throws orange-colored error messages and requires an eight-step sequence for login purposes.

To prevent Collective Access from being discounted as a potential collections management software solution at the Morgan-Manning House, please advise how I may resolve this problem. So far as possible, please post any instructions addressed to me for resolution of this problem in language which is clear, specific, presumes only a basic level of coding and/or DBMS expertise, and which does not presume programming expertise. Writing your response using these suggestions should be helpful to me and to the broader user community. Thank you.

Comments

  • P.S. I attempted to post the above message in Google Chrome, Mozilla Firefox, and Microsoft Edge, receiving the error described on (https://collectiveaccess.org/support/index.php?p=/discussion/299464/ca-forum-exception-you-need-the-garden-community-manage-permission) in my first attempt to submit the post on each of these three web browsers. This is extremely frustrating.

  • edited February 20

    Try running PHP 7.1 on your server with 1.7.8, or else run 7.3 with the develop branch. Or wait for the next release. Those orange messages are due to incompatibilities between the current release and PHP 7.3.

    If you wish to file "bug reports" in the future, please do so on our bug tracker at https://collectiveaccess.atlassian.net.

  • Hello seth,

    I did attempt to use the official reportage system first. However, per the attached screen capture, that page is not being maintained with current certificates.

  • edited February 20
  • Hello seth,

    When I attempted to follow your link, I was directed to the page shown in the attached screen capture. I'm signing off for the night and will pick up this project next week.

  • Hello again. Last week, I attempted to access "https://collectiveaccess.atlassian.net/secure/BrowseProjects.jspa," the page linked by the "Bug Tracker" logo on "https://www.collectiveaccess.org/#support," and found that this webpage was available. However, in order to re-file the above report on Jira, the "Bug Tracker" resource, I expect and believe that I must log in via an icon visible in the lower left-hand corner of the Jira interface. Last week, and again today, I tried to log in by entering the same credentials I established for the creation of my profile on this forum. To my knowledge, these credentials represent the only user name and password which specifically exist in connection with my use of resources made available through the Collective Access website. However, I am unable to access Jira with these credentials. When entered, they return the message "[USERNAME] doesn't have access to Jira on collectiveaccess.atlassian.net." In view of this result, I attempted to create unique credentials for Jira during my investigations last week, but this step was also unsuccessful. As such, I have concluded that I must be given permissions to access Jira by a Collective Access administrator. Please advise if I am correct. If so, please allow my use of Jira to formalize the bug report. The issues documented by this report are still presented by the release of Collective Access under consideration as a collections management software solution on the premises of the Morgan-Manning House. If not, and an administrator's permission is not required to use Collective Access' implementation of Jira, please advise how it may be accessed. Thank you.

  • I am pleased to advise that I no longer need to formalize a bug report, as I have resolved my issue using the directions left by Seth on February 20. While this is a successful outcome, I would nevertheless ask that a representative of Collective Access still answer my inquiry regarding the use of Jira as a bug-reporting utility.

    In the interest of other community users who encounter the same problem I described in February, I will now provide some further information which details the solution.

    N.B. I used the first of Seth's two presented alternatives, "running PHP 7.1 on your server with [Collective Access version] 1.7.8." My system remains a laptop running WampServer on Windows 10, and I can only offer specific instructions for this setup.

    1. Open WampServer fully (the "W" logo in the system tray at the lower right side of the screen should turn green).
    2. Left-click on the green "W" logo in the system tray. You should see a context menu pop up with several lines.
    3. Find the line which reads "PHP." Hover on this line.
    4. Another context menu should pop up on the side of the first such menu.
    5. Hover over "Version," the first line of this new menu.
    6. In speaking to my own experience, I was presented with a third context menu after hovering per step 5. The menu in this step contained seven different numbers, with each such number on a distinct line and representing a version of PHP.
    7. Left-click on the number in the third context menu from step no. 6 which is closest to "7.1."
    8. When I made this change, WampServer restarted automatically.

    The above steps should solve the problem. It is my belief that I am not the only person who has documented the PHP compatibility issue, so I hope that the community of users will find this post useful.

Sign In or Register to comment.