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.

Replication of objects changed from "Not accessible to public" and changed to "Acessible to public"

I don't seem to be able to replicate an object that was initially set to "Not accessible to public" when a replication is run, and then subsequently set to "Accessible to public". Subsequent replications don't pickup the object. I'm assuming that this is because the replicator is using the log history, and when the initial replication is run, the "Create Object" event is logged, but in subsequent replication runs it uses a log pointer that is after the create event so it won't create the object.

This was found on an initial replication, however it is a general case that seems like it needs to be handled. Is there any way around this other than not setting filter_on_access_settings to 0, thereby pushing all private records to the public site?

I'm using the Providence develop branch @ commit 55b2da0.

Comments

  • Hi Brett,
    Are you using the "duplicate record" feature? What happens when you try to duplicate the object, do you get an error message?

  • Hi Sophie,

    I'm not sure what you're referring to - I'm using the "caUtils replicate-data" script to replicate between the source databases and public facing website. The source configuration for the script looks something like this:

        carrhouse = {
                url = https://<phad_ip_address>/ext/phad/ch,
                service_user = administrator,
                service_key = <source_admin_password>,
                from_log_id = 5858,
    
                filter_on_access_settings = [1],
                push_missing = 1,
    
                onlyTables = [
                ca_attributes, ca_attribute_values, ca_object_lots, ca_object_lot_labels,
                ca_objects, ca_object_labels, ca_entities, ca_entity_labels,
                ca_objects_x_entities,
                ca_object_representations, ca_object_representation_labels, ca_objects_x_object_representations,
                ca_sets, ca_set_items, ca_set_labels, ca_set_item_labels, ca_objects_x_vocabulary_terms,
                ca_list_items, ca_lists, ca_list_labels, ca_list_item_labels
        ],
                push_media = 1
        },
    

    I assume that the filter_on_access_settings is the switch that tells the replication to not include an object / entity if it is marked as Not Accessible to Public, however once a replication is run with an object that is Not Accessible, if the object is changed to Accessible, and the replication is rerun, the object is not replicated to the public database.

    I would prefer to not replicate the private records to the public website for security reasons, but I'm at a loss as to how to have the record show up when it is changed from Not Accessible to Accessible in the source database.

  • It will replicate them when their access value changes based upon the logged change, but you do need to make sure the access change is logged. If you are setting these directly in the database using SQL (for example) and bypassing the log then you'll get the behavior you describe.

    Perhaps there is something else going on, but filter_on_access_settings in general does work as described: most sites using replication depend up it.

  • Hi Seth -

    Thanks for the reply. It looks like this is working with objects/entities that are created via the GUI, but not those imported via the API. I'll dig into this to see what the difference is - there were change logs generated in both cases I'm just not sure why one is behaving and one isn't.

  • edited January 9

    Traced this back to what seems to be an issue in app/lib/Sync/Replicator.php. On line 552 I think
    if (in_array($v, $va_guids_to_skip)) {
    should actually be
    if (in_array($v, $va_guids_to_skip, true)) {

    If $v === 0, then this statement returns a false true, which was causing the Insert from the source database change log to be skipped for some objects when replicating those records.

    Issue documented here:
    https://stackoverflow.com/questions/13846769/php-in-array-0-value

  • Well $v should be a GUID, so it shouldn't ever be zero. I'd wonder why it is in that case.

  • Actually yeah I can see a case where that can happen. I'll make that change. Thanks for picking this up!

  • edited January 9

    It appears to use ca_change_log_snapshots.snapshot as the $k => $v in that foreach loop which appears to contain all the associated values included in the corresponding CRUD function so from what I'm seeing it definitely isn't just GUIDs.
    For the offending ca_change_log_snapshot.snapshot that I was seeing in my data looked like this when decoded (this was the initial insert for the record):

    a:33:{s:9:"object_id";i:74;s:9:"parent_id";s:0:"";s:14:"hier_object_id";s:2:"74";s:6:"lot_id";N;s:9:"locale_id";N;s:9:"source_id";N;s:7:"type_id";s:2:"24";s:4:"idno";s:16:"CH2018.0001.0008";s:9:"idno_sort";s:100:"CH2018 0001 0008 ";s:16:"is_deaccessioned";s:0:"";s:16:"deaccession_date";s:0:"";s:25:"deaccession_disposal_date";s:0:"";s:17:"deaccession_notes";N;s:19:"deaccession_type_id";N;s:17:"current_loc_class";N;s:20:"current_loc_subclass";N;s:14:"current_loc_id";N;s:14:"item_status_id";N;s:19:"acquisition_type_id";N;s:11:"source_info";N;s:9:"hier_left";s:1:"1";s:10:"hier_right";s:10:"4294967296";s:6:"extent";s:1:"1";s:12:"extent_units";N;s:6:"access";s:1:"0";s:6:"status";s:1:"4";s:7:"deleted";s:0:"";s:4:"rank";N;s:31:"acl_inherit_from_ca_collections";i:0;s:23:"acl_inherit_from_parent";i:0;s:26:"access_inherit_from_parent";i:0;s:10:"view_count";N;s:21:"circulation_status_id";N;}
  • Yes exactly. We haven't seen this manifest anywhere else though. I guess it was dumb luck. I'm going to commit a patch to only consider actual guids here.

  • Great, thanks.

Sign In or Register to comment.