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-20318: Add is_public setting on Custom groups #10028

Merged
merged 1 commit into from
Apr 6, 2017

Conversation

jitendrapurohit
Copy link
Contributor

@jitendrapurohit jitendrapurohit commented Mar 22, 2017

@jitendrapurohit jitendrapurohit changed the title CRM:20318: Add is_public setting on Custom groups CRM-20318: Add is_public setting on Custom groups Mar 22, 2017
@seamuslee001
Copy link
Contributor

@jitendrapurohit how does this interact with ACL rules that may get set?

@jitendrapurohit
Copy link
Contributor Author

jitendrapurohit commented Mar 24, 2017

@seamuslee001 This isn't a setting w.r.t a user but a page. So if a custom field is created with is_public disabled, it will not be shown on public pages (currently supported only for Event Info Page). So if an ACL is created to show for specific user, this setting will override it.

I thought of migrating this on an Event Form(say "Hide custom groups in info page") rather than on a Custom Group Form, since it is only Event Info Page where such custom field is being shown for now, but that will hold the setting as a whole(if checked all custom groups will be hidden) and not with per custom set(flexibility to show/hide specific set on the page) which is possible now.

@MegaphoneJon
Copy link
Contributor

Thank you for this @jitendrapurohit! It's definitely an annoyance that creating event custom fields adds them to the "Event Info" page.

@jitendrapurohit
Copy link
Contributor Author

@monishdeb Can you please review this and merge?

@@ -315,6 +315,8 @@ public function upgrade_4_7_16($rev) {
public function upgrade_4_7_18($rev) {
$this->addTask('Update Kenyan Provinces', 'updateKenyanProvinces');
$this->addTask(ts('Upgrade DB to %1: SQL', array(1 => $rev)), 'runSql', $rev);
$this->addTask('Add is_public column to civicrm_custom_group', 'addColumn',
'civicrm_custom_group', 'is_public', "boolean DEFAULT '1' COMMENT 'Is this property public?'");
Copy link
Member

Choose a reason for hiding this comment

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

@jitendrapurohit could you move the upgrade changes to upgrade_4_7_19(...) here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. Thanks!

@monishdeb
Copy link
Member

monishdeb commented Apr 5, 2017

@jitendrapurohit here's my report:

  1. Tested on my local against 4.7.19 upgrade and install, working fine.
  2. Created CG (Custom Group) with is_public=1 that extends an event.
  3. Created a Event and submitted custom field values of CG, created at step 2
  4. On setting is_public = yes/no the Custom Group info are toggled in Event info page respectively.

However, I found that CustomGroup DAO information is missing for that new column. This is my patch on that missing DAO info https://gist.github.com/monishdeb/8fd3eb1f3d91b2195f2ba02039074144

@eileenmcnaughton do we need to add a column in Custom group listing (url : /civicrm/admin/custom/group/?action=browse) page for this new field as Is public?

@magnolia61
Copy link
Contributor

I hope it is not too late to include (as I mentioned in the JIRA issue) that non-public groups will not be shown in the offline registration emails (another area custom groups will show aside of the event info page). If it is possible please include that, because otherwise this will give the administrator a false idea of non-disclosure to participants (e.g. internal notes will still be mailed to participants...)

@jitendrapurohit
Copy link
Contributor Author

jitendrapurohit commented Apr 5, 2017

@monishdeb shouldn't that will be included during the build? I just didn't included as then it is more likely for a PR to get stale(due to GenCodeChecksum changes). I'll push the changes.

@jitendrapurohit
Copy link
Contributor Author

@magnolia61 will check on it and get back to you soon :)

@jitendrapurohit
Copy link
Contributor Author

@magnolia61 Is that custom group created for event or participant ? As I don't see the event custom groups is sent in registration mails.

@eileenmcnaughton
Copy link
Contributor

@monishdeb @jitendrapurohit my understanding is this has been reviewed & approved & now the DAO changes have been pushed - so we should add merge on pass?

@magnolia61 - I agree with you that there are situations where the emails contain inappropriate custom data & it would be good to exclude - I've also seen this in contribution & pledge emails. This will help towards that but not resolve it - we should add a follow on ticket for that. It's not trivial as it would also need unit tests

A note re the field - there is precedent for both 'visibility' and 'is_public' in other tables, given that I don't have a strong feeling as to which is more appropriate.

@magnolia61
Copy link
Contributor

@eileenmcnaughton allright. no problem to separate this so the current PR can be merged. Shall I open a follow-up issue for that?

@eileenmcnaughton
Copy link
Contributor

@magnolia61 yes do that - I'm not sure what priority it will get. I see @jitendrapurohit might pick it up - but he is juggling a few priorities.

@monishdeb
Copy link
Member

@eileenmcnaughton I am happy with the final change. Merging now

@monishdeb monishdeb merged commit ad0181c into civicrm:master Apr 6, 2017
@jitendrapurohit jitendrapurohit deleted the is_public_group_fix branch April 7, 2017 09:20
@magnolia61
Copy link
Contributor

Just opened https://issues.civicrm.org/jira/browse/CRM-20507 for follow up on preventing mailing of is_public = 0 Custom Groups

@kpanic23
Copy link

It would have been great if the 'is_public' field would also have been added to the appropriate views, not only to the table. Had to add the field manually to unbork our installation

@MegaphoneJon
Copy link
Contributor

@kpanic23 You're absolutely correct - and https://issues.civicrm.org/jira/browse/CRM-20623 was raised to fix this exact issue. I definitely recommend upgrading against a test instance of your site first! Come talk to us at https://chat.civicrm.org if you're able to help out with testing release candidates or similar.

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