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

CRM-19948: Store Attachment uploader information #11739

Merged
merged 3 commits into from
May 28, 2018

Conversation

monishdeb
Copy link
Member

This PR changes the Attachment API in order for it to save the current logged in contact ID as the uploader of the file.

The ID is stored in the created_id field, which was added to the File entity. On Attachment.create, only when adding a new file (i.e. File.id is empty), we set the created_id as logged in contact ID.

The created_id field is not required and, on delete, it's set to null. This was done because:

  • There might be existent files on the database
  • A few other places use the File BAO directly and we don't want/need to update all them right now
  • When deleting a contact, we still might want to keep the file.

Note: I couldn't find a way to test the upgrader, so I'm not really sure if it's working. I tried to play with https://github.com/civicrm/civicrm-upgrade-test but didn't have any success


@monishdeb
Copy link
Member Author

ping @colemanw @totten @eileenmcnaughton

@monishdeb monishdeb force-pushed the CRM-19948 branch 2 times, most recently from 65670f7 to a3f143e Compare February 28, 2018 18:42
@@ -147,6 +147,7 @@ function civicrm_api3_attachment_create($params) {
$fileDao->copyValues($file);
if (!$id) {
$fileDao->uri = CRM_Utils_File::makeFileName($name);
$fileDao->created_id = CRM_Core_Session::getLoggedInContactID();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to do this on the spec function - ie
'api.default' => 'user_contact_id',

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah right .. how could I overlooked it :( Will do it

@eileenmcnaughton
Copy link
Contributor

@monishdeb I understand this PR is a reviewer's commit so if you have tested it I'm Ok with it - although I made one stylistic comment.

I think there is a pretty strong precedent for adding this sort of column and while adding columns to big tables should be done cautiously due to the length of time the upgrade script can take (we can't impose 1-2 hour outages every month) my feeling is that the file table is not likely to be massive even for large sites.

Regarding the upgrader test - you mean you couldn't just run the upgrade locally?

@monishdeb
Copy link
Member Author

Thanks, @eileenmcnaughton for your feedback. I have made the additional fix, also earlier I tested the patch over a multilingual upgrade on my local. And the test build covers the monolingual upgrade, so I think the PR is safe to merge.

@colemanw
Copy link
Member

colemanw commented Mar 2, 2018

@monishdeb I'm surprised the AllCoreTables.data.php file didn't get updated by codeGen to use square bracket syntax for arrays. Did you have to do any manual updating of the file or were there any issues with codeGen?

@colemanw
Copy link
Member

colemanw commented Mar 2, 2018

@monishdeb I'm still very confused as to how the arrays managed to stay in the old syntax after being passed through codeGen the first time you did this, and why they are suddenly coming out in the correct syntax now, even though we haven't done any updates to codeGen.

@monishdeb
Copy link
Member Author

@colemanw that's because the CodeGen will simply ignore if that file is already present (see here where CRM_Core_CodeGen_Reflection::needsUpdate() return TRUE if that files is not present and eventually hits the gencode). Reason why we were not getting the correct syntax. I have then deleted the CRM/Core/DAO/AllCoreTables.data.php and then executed the bin/regen.sh which corrected syntax. (Another alternative is to run sh bin/regen.sh -g)

@totten
Copy link
Member

totten commented Mar 6, 2018

I'm still very confused as to how the arrays managed to stay in the old syntax after being passed through codeGen

that's because the CodeGen will simply ignore if that file is already present

This is incorrect. The Reflection::needsUpdate() check says that:

  • If the file does not exist, then it must be updated.
  • If the file does exist, then generate a quick preview ($this->getRaw()) and compare that to the actual code (using an an approximate equivalence test, isApproxPhpMatch(...)).

The problem here is that the equivalence-test (isApproxPhpMatch()) is too clever, owing to c3fc262#diff-ec73ce9b7d53e38552af8595f882ae9bR77 -- note how line 77 means that both $expected and $actual will be filtered through ArraySyntaxConverter before comparing them. In effect, that line says: "two PHP files are equivalent if all the code is the same, notwithstanding array-syntax variations".

I suppose there is a legitimate argument that the two files are truly equivalent (because array-syntax differences are trivial). But I can't think of a reason why we'd want to treat them as equivalent for GenCode purposes. We'd rather err towards having the current *.php match the current *.tpl. Just remove the call to ArraySyntaxConverter, run GenCode, and make sure you commit the current revisions of any generated files.

@colemanw
Copy link
Member

colemanw commented Mar 6, 2018

@totten the reason for c3fc262 is that our old php beautifier is incapable of processing files with short array syntax. Also, the smarty function {print_array} does not seem capable of outputting short syntax. So when generating DAOs, the existing files will have short syntax and the generated will have old syntax. Hence the necessity to convert them before comparing as strings.

@monishdeb monishdeb force-pushed the CRM-19948 branch 4 times, most recently from d91c2d9 to c74ea2d Compare April 16, 2018 19:10
@monishdeb
Copy link
Member Author

@colemanw @totten I have rebased this PR and shifted the upgrade code to 5.2alpha1. Please have a look!

'title' => 'Created By Contact ID',
'type' => CRM_Utils_Type::T_INT,
'description' => 'FK to civicrm_contact, who uploaded this file',
'api.default' => 'user_contact_id',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the File BAO is a more appropriate place to set this default value than the API? Setting it here will only affect apiV3.

@monishdeb monishdeb force-pushed the CRM-19948 branch 2 times, most recently from a8f8085 to b9efc25 Compare April 18, 2018 12:04
*
* @param string $rev
*/
public function upgrade_5_2_alpha1($rev) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eileenmcnaughton like I was saying if we need to set it to upgrade_5_2_alpha1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh - will watch & see if @totten / @colemanw merge this :-)

$fileDAO = new CRM_Core_DAO_File();
$fileDAO->copyValues($params);

if (empty($params['created_id'])) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this ought to also be conditional if there is no $params['id'] to avoid overwriting this value on update.

@monishdeb
Copy link
Member Author

monishdeb commented May 21, 2018

@colemanw @eileenmcnaughton can you please review & merge this PR?

(cherrypicked commits from #9761 + additional changes)

Copy link
Member

@colemanw colemanw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good except for missing hooks.

$fileDAO->created_id = CRM_Core_Session::getLoggedInContactID();
}

$fileDAO->save();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this BAO::create() function needs to call pre/post hooks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops missed it, thanks for pointing that out.

Added the hook calls. Can you please check now?

@eileenmcnaughton
Copy link
Contributor

@colemanw what does approved mean? How does that fit with 'good to merge'

@colemanw
Copy link
Member

@eileenmcnaughton I had been about to merge it but then waned to verify with @totten that the upgrade code was going into the correct place. Got that question answered so now merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants