Action "digitalobject/browse" does not exist.

[Augusto Torres]

Dear,
I am having problems with the migration from atom 2.3.1 to version 2.4.
I performed a clean install on Ubuntu 16.04 that works perfectly for new inserts.
The problem is with the migration of the data to the new server.

I dump the old base:
mysqldump -u username -p old_database> /tmp/database.sql

I created a new bank:
mysql -u username -p -e 'drop database new_database; create database
new_database character set utf8 collate utf8_unicode_ci; '

I restored the data to the new bank:
mysql -u username -p new_database </tmp/database.sql

I reindexed all the data:
php symfony digitalobject: regen-derivatives
php symfony search: populate; php symfony cc

Going
http://127.0.0.1/index.php/digitalobject/browse

How can I circumvent this error?
Tks
Augusto

Error encountered:
Action "digitalobject / browse" does not exist.
stack trace

    at
    in SF_ROOT_DIR / vendor / symfony / lib / controller / sfController.class.php line 196 ...
                    $ this-> dispatcher-> notify (new sfEvent ($ this, 'application.log', array (sprintf ('Action'% s /% s "does not exist ', $ moduleName, $ actionName))));

                  }


                  throw new sfError404Exception (sprintf ('Action'% s /% s "does not exist. ', $ moduleName, $ actionName));

                }


                // create an instance of the action
    at sfController-> forward ('digitalobject', 'browse')
    in SF_ROOT_DIR / vendor / symfony / lib / controller / sfFrontWebController.class.php line 48 ...
    at sfFrontWebController-> dispatch ()
    in SF_ROOT_DIR / vendor / symfony / lib / util / sfContext.class.php line 170 ...
    at sfContext-> dispatch ()
    in SF_ROOT_DIR / index.php line 6 ...
            require_once (dirname (__ FILE __). '/ config / ProjectConfiguration.class.php');


            $ configuration = ProjectConfiguration :: getApplicationConfiguration ('qubit', 'prod', true);

            sfContext :: createInstance ($ configuration) -> dispatch ();

Google Tradutor para empresas:Google Toolkit de tradução para appsTradutor de sites

[Dan Gillean]

Hi Augusto, 

It looks like, in your upgrade steps, you did not run the sql-upgrade task: 

• php symfony tools:upgrade-sql
  
• See: https://www.accesstomemory.org/docs/2.4/admin-manual/installation/upgrading/#run-the-upgrade-task
  

This step needs to be run to ensure that the database changes are pulled in, and any migration scripts needed to move your data (so it works properly with the new DB schema) are run. 

You should perform this steps after loading your data, but before running other maintenance tasks like regenerating derivatives, clearing the cache, restarting services, and populating the search index. 

Regarding this specific change: 

In AtoM 2.4, the digital object browse page has been merged into the general search, so that users have access to all the facets and advanced search filters available on archival description searches. So digitalobject/browse does not in fact exist any more. 

There's still a digital object browse option however! We've added the option to view results either in the full results view, or in a "card" view like you used to see on the digital object browse page. 

The link to browse digital objects in the menu will now take you to a search page that is:

• Set to use the card view (like the old digital object browse page)
• Set to show all levels of description
• Set so "Digital object" filter is set to "Yes"

This is what the new Digital object browse URL is once you've upgraded properly: 

• /informationobject/browse?view=card&onlyMedia=1&topLod=0
  

Here is the related development issue ticket: 

• https://projects.artefactual.com/issues/9949

I think that if you go back and run the SQL upgrade task, then cc, restart PHP-FPM, and re-index, you will no longer get the error. 

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/b9518bb1-1b40-4fd4-b49b-afae568e412c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Augusto Torres]

Hello Dan Gillean,
I did this according to the documentation.
I'm getting the following error in execution:
   SQLSTATE [42S21]: Column already exists: 1060 Duplicate column name 'statute_citation_id'

Any idea what this would be?
Thank you

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.

[Dan Gillean]

Hi Augusto, 

Hmmm, strange. I think it might be better to start fresh. Do you still have the SQL dump of your data? If so, I'm going to suggest that you purge the 2.4 site of all data, drop and then recreate the database, load the data, and try running the upgrade task again. As far as I'm aware, you shouldn't be seeing that error if the upgrade has completed successfully. Please try the following - ONLY if you still have your data backed up from 2.3.1!  

• In the 2.4 instance, run the purge command - this will destroy all data currently in the system: 
• php symfony tools:purge
• Then drop and recreate the database - the following example command assumes that your database name is atom, but change it as needed:
• mysql -u username -p -e 'drop database atom; create database atom character set utf8 collate utf8_unicode_ci;'
  
• Now we can load your 2.3.1 SQLdump, and re-run the upgrade task
• You'll probably want to restart services and clear the cache again before retrying the search:populate task. 

If that doesn't work, I'll see if our developers have further suggestions. 

Regards, 

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

@accesstomemory

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/c4763c3a-7030-4c76-b0f8-e271ca8108a3%40googlegroups.com.

[Augusto Torres]

I did it again as you guided me, the error persists

  SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'statute_citation_id' 

Tks

[Dan Gillean]

Hi Augusto, 

Do you still have your 2.3.1 instance installed? If so, can you run the following command on it to get us the full database version:

• php symfony tools:get-version
• See: https://www.accesstomemory.org/docs/2.4/admin-manual/maintenance/cli-tools/#find-out-what-version-of-atom-you-re-running

Please return the full output. 

I'm wondering if perhaps in a previous version when you upgraded, either you forgot to run the tools:upgrade-sql command at some point, or possibly the upgrade task could have crashed before it completed properly. 

We've looked into the migrations and they seem ok - that database column was added in 2.3 as part of migration0134. However, if your database schema hasn't been properly upgraded at every step, you might encounter the kind of error you're seeing. 

Hopefully this will help as a first step to figuring out where the issue lies. 

Thanks! 

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

@accesstomemory

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/ead21e35-9816-4a08-8ad9-c56fbb7b2cbf%40googlegroups.com.

[Augusto Torres]

Good morning Dan,
Yes, I have the old base running in version 2.3.1.
php symfony tools: get-version
2.3.1 v133
I made a new dump from the base:
mysqldump -u root -p atomdatabase> database.sql

I erased everything I had on the new server and created a clean foundation:
mysql -u root -p -e 'drop database atomdatabase; create database atomdatabase character set utf8 collate utf8_unicode_ci; '

I totally deleted and restored the atom:
cd / usr / local / nginx /
rm -R atom
mkdir atom
chown -R www-data: www-data
sudo tar xzf atom-2.4.0.tar.gz -C / usr / share / nginx / atom --strip 1

Restored the old base, with nothing else to do:
mysql -u root -p atomdatabase <database.sql

Look:
php symfony tools: get-version
2.4.0 v133

I'm really not understanding ...
Thank you
Augusto

Google Tradutor para empresas:Google Toolkit de tradução para appsTradutor de sites

[Augusto Torres]

Em quinta-feira, 5 de outubro de 2017 08:45:00 UTC-3, Augusto Torres escreveu:

Good morning Dan,
Yes, I have the old base running in version 2.3.1.
php symfony tools: get-version
2.3.1 v133
I made a new dump from the base:
mysqldump -u root -p atomdatabase> database.sql

I erased everything I had on the new server and created a clean foundation:
mysql -u root -p -e 'drop database atomdatabase; create database atomdatabase character set utf8 collate utf8_unicode_ci; '

I totally deleted and restored the atom:
cd / usr / local / nginx /
rm -R atom
mkdir atom
chown -R www-data: www-data
sudo tar xzf atom-2.4.0.tar.gz -C / usr / share / nginx / atom --strip 1

Restored the old base, with nothing else to do:
mysql -u root -p atomdatabase <database.sql

Look:
php symfony tools: get-version
2.4.0 v133

[Dan Gillean]

Hi Augusto, 

Okay.... it looks like we have a problem with the database version in your last installation. It's possible that this started last time you upgraded (possibly from 2.2 to 2.3, or 2.3 to 2.3.1), but - for version 2.3, the database version should be 138. So at some point, some migrations have not been run properly, and this is now causing problems when the current migrations are looking for things they expect to find in v138. For 2.4, the database version should be v156. 

I'm going to have to ask my team for suggestions on next steps. One thing we can try in the meantime - but before you do so, make sure you have a copy of your data sqldump outside of any AtoM instance. Your data is in a partially corrupted state, but we don't want to make your only copy any worse! 

I'm wondering if perhaps, if you load your data back into the 2.3.1 instance, and try running the sql-upgrade task there, if maybe we can get the db to v138. Try that, and then run the tools:get-version task again. If it is v138, then you can try making a new sqldump and using that to load into your 2.4 instance, and redo the upgrade steps. 

If that doesn't work, then we'll have to find a more hands-on approach to fix things. 

Regards, 

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

@accesstomemory

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/e7646786-11c1-45bd-b6ae-576c9fbfa86b%40googlegroups.com.

[Augusto Torres]

Dear Dan,
I tested with version 2.3.1.
Unfortunately nothing I do solves the inconsistency of the database.

php symfony tools: upgrade-sql

                                                                                            
SQLSTATE [42S21]: Column already exists: 1060 Duplicate column name 'statute_citation_id'

Thanks for any help you can give us.
Att
Augusto

[Dan Gillean]

Hi Augusto, 

Darn. Okay, things are going to get trickier going forward. 

The problem is essentially that, for some reason, there is a mismatch between the version your database thinks it is at, and what migration tasks have actually been run. Either the current database version stored is incorrect, and needs to manually corrected to the right version before we can run the 2.4 upgrade task, or else we need to disable the current migration task this is hanging on from running, since the changes are already in place. 

Before we are able to do anything, we need to try to figure out which is actually happening. 

Let me say this: this will be complicated, and is somewhat beyond the level of support we are able to fully offer via the user forum. We can try to talk you through as much as we are able, but at some point if we encounter further issues, it will be impossible for us to provide support without actually examining the database - which is beyond the level of support we can offer freely in the user forum. If you need this to be resolved in a timely manner and your institution has some resources to support this, please feel free to contact me off-list: Artefactual can examine the database, and find and resolve the migration issues at our time and materials rate. 

If however, you want to continue pursuing this on your own, then the first step will be for us to try to figure out which migrations have been run, and which haven't. 

This will be a process of elimination, and will require some investigation on your part. Essentially, we know that the database *thinks* it is at v133. It is unlikely that earlier migrations have not been run, so what we will start by doing is reviewing migrations 134 - 138 and seeing if we can find evidence in your installation that they have already been run. 

For reference, all the migrations in AtoM can be found here: 

• https://github.com/artefactual/atom/tree/qa/2.5.x/lib/task/migrate/migrations
  

You'll notice that most of the recent commit messages on each migration, include a 4-5 number like so:

These numbers point to the related issue ticket in our development tracker, where you can find more information. The AtoM issue tracker is here: 

• https://projects.artefactual.com/projects/atom

You can enter the issue number (without the # pound sign) in the search bar to go straight to the related issue. This should give you more context. 

So... let's start taking a look at these. ​We will assume for now that migration 133 has run, as have previous ones. What I need you to do, so we can narrow down where the issue occurs, is try to find evidence of the following migrations being run. We'll look for functionality that should be in your 2.3 version to find out - please review my notes below, and for each migration, see if you can find the functionality I reference in your 2.3.1 interface. You might want to do a bit of testing with each element too, to make sure the functionality seems to be working as expected in 2.3.1. 

Here we go: 

134 (issue 8678) fixed some previous migration issues (so could be our culprit if not run properly!), and it also turned the Statutes field in the Rights template into an autocomplete, linked to a new Taxonomy. So: to check if this has been run, please navigate to Manage > Taxonomies, and see if there is a taxonomy called "PREMIS Rights Statutes."

135 (issue 8887) made changes to the Access statements associated with actionable PREMIS rights. We can check for this by navigating to Admin > Settings. There should be a section there now called "Permissions" that has the following in it: 

136 (issue 7890) involves​ changes that are not visible in the user interface... there was a typo in one of the security check classes in the code. So, to see if this has been run, we are going to search for the old, incorrect spelling in the code, using grep in the command-line. If this migration HAS been run, then you should get 0 results back. Try the following: 

• grep -Ri priviliges /usr/share/nginx/atom
  

If it DOES return results (places in the code where this "priviliges" spelling is found), then this means that 136 has not been run - let us know! 

137 (issue 8941) is the addition of the Clipboard. You can read more about the Clipboard here: 

• https://www.accesstomemory.org/docs/2.3/user-manual/access-content/clipboard/
  

If you don't have the Clipboard showing up and working as expected in your 2.3.1 instance, then migration 137 has probably not been run! 

Finally 138 (issue 9141) involves merging the search, browse, and advanced search pages into one page, instead of 3 different but very similar ones. You should be able to see, on your Browse > archival descriptions page, the Advanced search panel, as shown in the documentation here: 

• https://www.accesstomemory.org/en/docs/2.3/user-manual/access-content/advanced-search/#advanced-search-interface
  

Let us know what you find. If what you see for any migration above does not match what I describe, this might indicate a place where a migration failed to run. If, on the other hand, you find all the functionality I describe for each migration, then it might suggest that it is only the database version number that is incorrect. Once we know which is which, we can hopefully go from there. 

Regards, 

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

@accesstomemory

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-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/61cbd6f7-17b5-4de7-bd1a-88141c4934ea%40googlegroups.com.

[Augusto Torres]

Yahuuuu
I got it !!!
I deleted these fields from the rights table
ALTER TABLE rights DROP COLUMN statute_citation_id;
ALTER TABLE rights DROP COLUMN copyright_status_id;
php symfony tools: upgrade-sql
upgrade-sql Successfully upgraded to Release 2.4.0 v156

I followed in the settings to be if they were well.
For now, thank you, Dan.
A great weekend

[Dan Gillean]

Augusto, that's great! 

I do suggest that you double-check all the functionality listed above, to make sure that everything has upgraded properly. But this is very promising - congrats! 

Regards, 

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

@accesstomemory

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/2b3fbbe5-d0e7-4800-9e9b-15fc12b74a17%40googlegroups.com.

[Augusto Torres]

Hi Dan,
It seems that is working fine.
The unique problem are the multiples messages like this when I run

php symfony search:populate
The following errors have been encountered:
Couldn't find information object (id: 389)
Couldn't find information object (id: 390)
Couldn't find information object (id: 393)
Couldn't find information object (id: 401)
Couldn't find information object (id: 403)
Couldn't find information object (id: 405)
Couldn't find information object (id: 459)
Couldn't find information object (id: 493)
Couldn't find information object (id: 634)

I have already done the commands below but they have not resolved

php symfony propel:build-nested-set
php symfony propel:generate-slugs

Tks

[Dan Gillean]

Hi Augusto, 

Sounds like some of the data is corrupted - that is, missing key information in the relevant database rows. 

The next most common problem when encountering problematic objects, after missing slugs or a broken nested set, is a missing publication status. The following 2 posts should help guide you to checking to see if this is the case for these resources: 

• https://groups.google.com/d/msg/ica-atom-users/Z8xPAMr0hiY/60L714l3EQAJ
  
• https://groups.google.com/d/msg/ica-atom-users/ZElzuHT_g40/z-XFsDFIFAAJ

The second of these posts also guides you for another possible cause, though rarer - when the object row is missing for a related resource. Let us know what you find. 

If the above suggestions do not resolve the problem then you might need to examine the MySQL database data directly using a tool like the mysql client, MySQL Workbench, or phpMyAdmin.  To determine if the information object should be fixed or deleted I suggest that you check the information_object_i18n row to see if there's any actual data present.  If there's no data, then you can delete the `object` table row, which cascade deletes the information_object, and information_object_i18n rows.  Sometimes there is a foreign key constraint that prevents deletion that needs to be addressed first.

Regards, 

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

@accesstomemory

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/feecf136-bd07-407c-aabd-7b2696670ea2%40googlegroups.com.