-
-
Notifications
You must be signed in to change notification settings - Fork 825
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
dev/core#5654 add support for tagging Afforms using Tag entity #31890
base: master
Are you sure you want to change the base?
Conversation
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
I think this is my preferred approach over #31889 but interested in other views |
As a next step, I would have liked to switch the input on the FormBuilder screen to a But that wasn't working for some reason. I think there may be a constraint where Quick Add forms must have 'quick-add' in their url path. @colemanw are you aware of that? In general one of the reasons I prefer this approach is I think the UI could improve over time if we add more Tag support to SearchKit / FormBuilder (i.e. things like correctly coloured swatches in the SearchKit listing and type-to-create-new-tags-on-the-fly ). |
@ufundo I feel pretty good about this deviant use of the Tag entity. I vote for this option! |
0920a6b
to
434ab6f
Compare
I was slightly wary the schema builder might blow up somewhere because of the not-physical-table-name in |
@ufundo I have an idea of how to pre-empt anybody attempting to use these in the EntityTag table. Just pushed 4f9ab8d |
// - creates an example tag that can be used for afforms. This is more to demonstrate | ||
// how it can be used, as Donor Journey might be useful for some orgs but not for others | ||
// @todo think of better example tag that is more universally applicable? |
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.
I think it's better not.
As a general principle I think we should not install sample data onto people's sites unless they specifically select the "sample data" option in the installer.
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.
General principle: definitely agree.
My worry here though is that the "Used For" on Tags isn't discoverable enough, so people might not find how to add tags that they can use here, so I thought this might be a reasonable exception to the rule. (Note we add example Tags by default on new installs. Also Tags are by their nature very easy to throw away, so it feels not such an imposition to add this one?)
But I don't mind, can remove if you're not convinced.
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.
Yea, I had the same concern when I added tagging to SearchKit, so my solution was to create the select-or-create tag widget inspired by GitHub tags (try tagging a searchKit, it's cool).
We could probably extract that widget from SearchKit and reuse it here.
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.
Ooh, yes please. Then I can use it in civirules 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.
Ooh I hadn't seen that before. Definitely a useful widget! For formbuilder too please 😉
Component will definitely need a bit of refactoring because the component is using EntityTag
api... but would be great definitely. Happy to remove this in the meantime
(Slightly separate point - I find different orgs have different policies on whether inline tag creation is a useful feature or makes it too easy for thousands of unhelpful tags to proliferate. So might be good if there was some way to configure that... At the moment for quickform tag widgets it seems to vary a bit on different screens...)
@@ -26,7 +26,7 @@ | |||
'label' => E::ts('Afforms'), | |||
'is_reserved' => TRUE, | |||
'is_active' => TRUE, | |||
'domain_id' => NULL, | |||
'filter' => 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.
What is filter normally used for ?
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.
Not much of anything.
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.
Could it have a more semantic value? Like filter = 'tableless' and then the condition != tableless?
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 the table column is an int
.. so no
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.
I've added a comment for the significance
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.
And removed the example tag
Oh weird I didn't see these fails before https://test.civicrm.org/job/CiviCRM-Test/45834/testReport/ |
ext/search_kit/ang/crmSearchTasks/traits/searchDisplayTasksTrait.service.js
Outdated
Show resolved
Hide resolved
ext/search_kit/ang/crmSearchTasks/traits/searchDisplayTasksTrait.service.js
Outdated
Show resolved
Hide resolved
d74439b
to
6ac1f0a
Compare
6ac1f0a
to
4cbc848
Compare
4cbc848
to
b07350d
Compare
Overview
Adds the ability to tag afforms with Tags (from
civicrm_tag
table).Alternative to #31889
Before
After
Technical Details
This implementation uses the
civicrm_tag
table.The advantage over #31889 is we have a nice UI for managing tags, and tags can be reused (e.g. for activities and forms)
On the flipside, this might be a slightly deviant usage of tags, because the
used_for
field generally expects a table name in order to create db table joins between tagged entities and tags, using the EntityTag bridge (with a dynamic FKentity_table
andentity_id
). In this case Afform is not a db entity, so cannot be referenced in this way - the values are just being loaded into a pseudoconstant, and then serialized in the Afform meta.However - I feel like this might be legitimate for tags in an Api4 world - ie the key thing for tags is they reference an entity. If this is a DB entity then great, we get stuff for handling the DB queries out of the box. If not there is a bit more flexibility/work to do in how a BasicEntity uses the tags.