-
-
Notifications
You must be signed in to change notification settings - Fork 828
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
Unhide financial acls, disable if not required. #29360
Conversation
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
405dbf7
to
0c3594c
Compare
2ccddf1
to
4b5563d
Compare
4b5563d
to
0695ef7
Compare
@colemanw this is passing now! |
if (!$setting) { | ||
return TRUE; | ||
} | ||
$setting = unserialize($setting); | ||
if ($setting) { |
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.
@eileenmcnaughton I'm confused about what this code is doing. Why the unserialize()
? The setting appears to be a boolean, not serialized:
civicrm-core/ext/financialacls/tests/phpunit/Civi/Financialacls/FinancialTypeTest.php
Line 24 in aac2d70
Civi::settings()->set('acl_financial_type', TRUE); |
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.
Oh, ok I guess you have to unserialize because you're pulling it directly from the database?
But now I'm still confused because the logic appears to be backward. You are uninstalling the extension if the setting is TRUE? Shouldn't it be the other way 'round?
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.
@colemanw yep.... it should be...
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.
@colemanw above is fixed
0695ef7
to
b195ca8
Compare
note just flagging at the moment if a user wants to disable civi_contribute extension / Contribute Component the financialacls block it |
@seamuslee001 yeah - that is what this is supposed to help with - ie disable it for most users. There is another PR open to further move the logic over but struggling to get engagement on that one #28967 - possibly 'cheap & cheerful acls' should be in the core extension & only the JMA extension would have 'thorough but performance-harsh' acls but at the moment we have a bit of both in core |
$financialAclExtension = civicrm_api3('extension', 'get', ['key' => 'biz.jmaconsulting.financialaclreport', 'sequential' => 1]); | ||
if ($ftAclSetting && (($financialAclExtension['count'] == 1 && $financialAclExtension['values'][0]['status'] != 'installed') || $financialAclExtension['count'] !== 1)) { | ||
if (($financialAclExtension['count'] == 1 && $financialAclExtension['values'][0]['status'] !== 'installed') || $financialAclExtension['count'] !== 1) { |
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.
@eileenmcnaughton Do we need to add a check hook in this extension https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_check/?
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.
so I had doubts about how valid this is now - it does depend on where we land with #28967 - ie do we
a) do expensive, super thorough thing in in core & make the extension obsolete or
b) do the thing that performs well & is probably enough for most cases in core & recommend people use the extension for the expensive thing - I haven't had any engagement from @JoeMurray or @seamuslee001 on that but I think the value of the check is grey enough that removing for now seems OK
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.
now that @seamuslee001 has merged #28967 this check can go
2e3f812
to
01e6b7d
Compare
This was held up because of lack of clarity around the check - but the merging of #28967 means the check / extension is no longer relevant so I have removed it. The previous review otherwise tested this so I think it should be mergeable too @seamuslee001 - I updated the upgrader version |
@@ -396,10 +396,23 @@ public static function checkPermissionToEditFinancialType($financialTypeID) { | |||
* | |||
* @todo rename this function e.g isFinancialTypeACLsEnabled. | |||
* | |||
* @deprecated since 5.75 will be removed around 5.90 |
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 this have a deprecatedWarning call as well?
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.
We actually have core calls to it still - so the removal date is probably optimistic but we can always push it back - but I want people to still see it in their IDE
c3b788f
to
e4dd6b3
Compare
Just rebased this but it was passing - should be good to merge now I think |
e4dd6b3
to
2ef203c
Compare
2ef203c
to
8771548
Compare
@colemanw can you give this MOP since all the issues are resolved now |
We should also
@colemanw I started thinking about how we would do this -
Note my other PRs working this out of core are #28967 & #28960 -
Overview
Unhide financial acls, disable if not required.
Before
financialacls extension installed on all sites, disabled if setting not set, hidden
After
unhidden, no setting, uninstalled on sites that do not have the setting set
Technical Details
I think the main way in which core calls the extension currently is where you see isACLFinancialTypeStatus() - my most recent effort to address that is in #28967 & I guess we can't remove the setting as long as tose calls exist - hence this is still WIP - we could check if the extension is enabled - fugly but...
Comments
If this feature were to be built now the entire thing would be outside core, community supported, using hooks & I think that is ideally where it will end up. However, it was implemented a long time ago when there was less hook support