Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Works deposited via proxy are always set to private visibility #5457

Closed
rjkati opened this issue Feb 22, 2022 · 2 comments · Fixed by #5553
Closed

Works deposited via proxy are always set to private visibility #5457

rjkati opened this issue Feb 22, 2022 · 2 comments · Fixed by #5553
Assignees
Labels
valkyrization Work impacts the Work part of PCDM Model

Comments

@rjkati
Copy link

rjkati commented Feb 22, 2022

Descriptive summary

On nurax-pg, when depositing a work as a proxy, the visibility of the work is set to private even if the visibility on deposit was set to public.

Expected behavior

Works deposited via proxy should reflect the visibility settings selected during the deposit process.

Actual behavior

Works deposited via proxy are set to private.

Steps to reproduce the behavior

  1. Make sure that proxy deposit is enabled on nurax-pg and that you have an account set up as a proxy for another account
  2. Navigate to Dashboard -> Works
  3. Click "Add new work" and select "Generic Work"
  4. Fill out required metadata and add a file
  5. Select "Public" visibility
  6. Select another user in the "Proxy depositors" box.
  7. Check the Deposit agreement box and click "Save".
  8. Observe message "Unauthorized The page you have tried to access is private" message
@elrayle elrayle added this to Ready in Hyrax-Valkyrization Mar 1, 2022
@elrayle elrayle added the Work impacts the Work part of PCDM Model label Mar 4, 2022
@hackartisan hackartisan self-assigned this Mar 9, 2022
@hackartisan hackartisan moved this from Ready to In Progress in Hyrax-Valkyrization Mar 9, 2022
@hackartisan
Copy link
Contributor

There's definitely a race condition here somewhere. With breakpoints in the ContentDepositorChangeEventJob and in the SetDefaultAdminSet transaction the bug disappears.

Could

Hyrax.publisher.publish('object.deposited', object: curation_concern, user: user)
be relevant? The pub/sub architecture seems like it could also be prone to race conditions. Probably the behavior should be moved into a transaction.

@hackartisan
Copy link
Contributor

hackartisan commented Mar 11, 2022

It looks like visibility is not defined as an attribute on the resource. So when the postgres adapter saves it by pulling its attributes it simply doesn't come out and doesn't override the old value.

Edit to add: that's a red herring, visibility is determined by logic outside the simple existence of a property.

hackartisan added a commit that referenced this issue Mar 11, 2022
hackartisan added a commit that referenced this issue Mar 11, 2022
hackartisan added a commit that referenced this issue Mar 14, 2022
Essentially reverts #4653.

The listener appears to be failing to run correctly due to race
conditions observed when investigating #5457 and a similar bug that
appeared after an upgrade to hyrax 3.2 at Duke.

The actor is un-deprecated here because the
full actor stack will be deprecated once it's been replaced by the
valkyrie transactions code path.

Advances #5457; addition of a transaction step in a forthcoming PR.
hackartisan added a commit that referenced this issue Mar 14, 2022
Essentially reverts #4653.

The listener appears to be failing to run correctly due to race
conditions observed when investigating #5457 and a similar bug that
appeared after an upgrade to hyrax 3.2 at Duke.

The actor is un-deprecated here because the
full actor stack will be deprecated once it's been replaced by the
valkyrie transactions code path.

Advances #5457; addition of a transaction step in a forthcoming PR.
hackartisan added a commit that referenced this issue Mar 14, 2022
Essentially reverts #4653.

The listener appears to be failing to run correctly due to race
conditions observed when investigating #5457 and a similar bug that
appeared after an upgrade to hyrax 3.2 at Duke.

The actor is un-deprecated here because the
full actor stack will be deprecated once it's been replaced by the
valkyrie transactions code path.

Advances #5457; addition of a transaction step in a forthcoming PR.
hackartisan added a commit that referenced this issue Mar 15, 2022
hackartisan added a commit that referenced this issue Mar 15, 2022
hackartisan added a commit that referenced this issue Mar 15, 2022
hackartisan added a commit that referenced this issue Mar 17, 2022
Add a new transaction step.
Replace behavior of queuing a job that runs a service with running a
service that then queues a job

closes #5457
hackartisan added a commit that referenced this issue Mar 17, 2022
Add a new transaction step.
Replace behavior of queuing a job that runs a service with running a
service that then queues a job

closes #5457
hackartisan added a commit that referenced this issue Mar 18, 2022
Add a new transaction step.
Replace behavior of queuing a job that runs a service with running a
service that then queues a job

closes #5457
@elrayle elrayle moved this from In Progress to DONE in Hyrax-Valkyrization Mar 21, 2022
@jlhardes jlhardes moved this from DONE to Ready to be Archived in Hyrax-Valkyrization Oct 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
valkyrization Work impacts the Work part of PCDM Model
Projects
Hyrax-Valkyrization
Ready to be Archived
3 participants