-
Notifications
You must be signed in to change notification settings - Fork 494
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
8092 timestamp of data access request #9257
8092 timestamp of data access request #9257
Conversation
@ericdevries thanks for the pull request! I added a release note, which you are welcome to tweak. I took a quick look at the docs and I don't think we need any changes there. API tests are passing. That's good. You mentioned fixing a related bug. Can you please provide steps for reproducing that bug? Finally, if you have a screenshot to share, you can put it under "Does this PR introduce a user interface change?" above. I gave this a size of 10 because it involves a database update and a fair amount of code was changed. I put it in the community backlog. Thanks again! |
I added the screenshot and the description on how to reproduce the bug. Let me know if you need anything else. |
@npoppelier: this PR should address your request for a date in file access request table. @pdurbin : we cannot access the Jenkins build. Can you give more information about why it failed so @ericdevries can address it? Thanks! |
Yes, I'm sorry about this. It used to be open to the public but it's hard to do this securely. We can poke an hole in the firewall for an IP for you if you'd like.
Please don't worry about it. The test that failed is simply flaky. I opened this issue so that we can address it separately: |
Prio meeting with Stefano.
|
file.getFileAccessRequesters().remove(au); | ||
boolean actionPerformed = false; | ||
for (DataFile file : files) { | ||
file.removeFileAccessRequester(au); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we test here to make sure that the removeFileAccessRequest was successful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we do this on another place as well. I'll update it.
@@ -0,0 +1,2 @@ | |||
ALTER TABLE fileaccessrequests | |||
ADD COLUMN IF NOT EXISTS creation_time TIMESTAMP WITHOUT TIME ZONE DEFAULT now(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to add a composite key to the table - though it might be problematic for upgrades, if there are any datafiles with multiple open requests from a given user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was indeed the problem I faced while building this. If the migration scripts support queries as well, we could do some kind of group by trick and table renaming to remove duplicate rows and create a fresh table with only unique rows.
This will also require some changes in the code however.
So the question is, would something like this:
-- note this is pseudo-sql
create table tmp_fileaccessrequests (user_id, file_id);
insert into tmp_fileaccessrequests
select distinct user_id, file_id from fileaccessrequests;
drop table fileaccessrequests;
rename table tmp_fileaccessrequests to fileaccessrequests;
be an acceptable solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. That would work and ensure that we don't lose any data. Just modify the script to add this to the top then add the key at the end. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall. Just a couple of comments/questions.
Also, please update with the latest from the develop branch.
Thanks for the contribution!
@ericdevries , thanks for the PR. Just wanted to make sure you saw my questions/comments. |
Hi @ericdevries just wanted to ask if you've had a chance to consider my questions/suggestions for this PR. Thanks! |
next sprint:
|
My apologies for the late reply, I did not see your questions. See my comments on your comments so we can further discuss what to do here |
@ericdevries please make the update to the migration script that we discussed last week. Also make sure that you've updated this branch with the latest from our dev branch. Once those are done we can get this PR into QA. Thanks! |
@ericdevries are you able to make the update I suggested for the migration script? If not, I can take it over. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes as discussed have been made. I updated the migration script
seen in the Edit Permissions/File dialog when clicking the link with the # of files listed. In that dialog, things explode trying to get the directoryLabel of a FileAccessRequest (seen in log) and the popup dialog incorrectly shows the input to select a user, only has a grant button (no reject), and doesn't work (the last could be an issue with this branch only).
What this PR does / why we need it:
This adds a date column to the restricted file access request overview, indicating when the earliest request by that user was made.
It also fixes an issue where the request list was not updated when a request was approved or rejected.
To reproduce this bug (outside this branch) perform the following steps:
Which issue(s) this PR closes:
Special notes for your reviewer:
Suggestions on how to test this:
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Yes, it adds a date column to the restricted file access request overview. See screenshot below:
Is there a release notes update needed for this change?:
Yes, added.
Additional documentation:
None.