| [12:02:46] | <paul121[m]> | dev call happening now! |
| [12:03:24] | <symbioquine[m]> | I'll be on in about 2 minutes :) |
| [12:03:49] | <mstenta[m]> | ah! forgot! |
| [13:16:45] | <paul121[m]> | Cool Hylo + OpenTEAM news (tbh I still haven't used hylo myself, but maybe this will finally motivate me): https://medium.com/terran-collective/community-infrastructure-for-regene... |
| [13:16:45] | <paul121[m]> | > We have created our first custom group type on Hylo — Farms! Farms can be created through our API integration with OpenTEAM, by filling out a quick survey on OpenTEAM’s open source tool, SurveyStack. With the producer’s consent, rich data from the survey is then populated into a beautiful farm profile page on Hylo, offering a way for land stewards to communicate about their operation — their goals, products, land management |
| [13:16:46] | <paul121[m]> | practices, needs and the types of connections they are open to. Farm profiles offer a way for land stewards to build relationships with each other, benefit from peer-to-peer support, and connect with purchasers and the public. |
| [16:29:33] | <symbioquine[m]> | Is there a good way to prevent config entities defined through Yaml from being deleted while still allowing them to be enabled/disabled? |
| [16:30:21] | <mstenta[m]> | Hmm that's a good question |
| [16:30:29] | <mstenta[m]> | Maybe not in Drupal core itself |
| [16:30:48] | <symbioquine[m]> | I guess I need to define my own permission provider to decorate \Drupal\entity\EntityPermissionProvider? |
| [16:30:49] | <mstenta[m]> | Have you used the Config Update UI module at all? |
| [16:31:11] | <symbioquine[m]> | I don't think so |
| [16:31:11] | <mstenta[m]> | It will show you "missing config" so it provides some functionality for detecting installed/deleted config |
| [16:31:16] | <mstenta[m]> | eg: if you delete a config |
| [16:31:18] | <symbioquine[m]> | ah |
| [16:31:58] | <symbioquine[m]> | I guess that might make it fine for users to delete my default config entities - if they can just use that tool to get them back... |
| [16:32:35] | <mstenta[m]> | yea... or you provide your own UI to restore them which mimics that... |
| [16:32:42] | <mstenta[m]> | the config update ui is def advanced |
| [16:32:55] | <mstenta[m]> | (and not accessible on farmier for that reason, fwiw) |
| [16:33:02] | <symbioquine[m]> | ah |
| [16:33:34] | <mstenta[m]> | it's basically an extension of drupal core's config management ui, which gives admin the ability to import/overwrite ANYTHING |
| [16:34:38] | <mstenta[m]> | not sure your exact needs, but might make more sense to just make your own layer on top to "disable" things... without actually deleting config |
| [16:35:04] | <mstenta[m]> | leave the config/"installed module" at a lower level |
| [16:35:49] | <symbioquine[m]> | Yeah, maybe I should just make it harder to delete them via the UI and if somebody goes out of their way to do so, they can always use advanced tools to put it back. |
| [16:37:13] | <mstenta[m]> | yea - i think i like the "disable the module to remove it entirely" approach, and then a secondary UI for enabling/disabling withing your app |
| [16:37:19] | <mstenta[m]> | that's kinda how i expected field kit to do it |
| [16:37:46] | <mstenta[m]> | because you may also want more levels of control (like we talked about w/ field kit)... eg: per-user |
| [16:38:31] | <mstenta[m]> | are you familiar with the `dependencies.enforced` yml mechanism? |
| [16:38:40] | <mstenta[m]> | * the `dependencies.enforced.module` yml |
| [16:39:15] | <mstenta[m]> | eg: https://github.com/farmOS/farmOS/blob/a8b528cdd979ef59ef1f1aae16c4e10970... |
| [16:39:17] | <symbioquine[m]> | Yeah, users can still add/remove/disable plugins in Asset Link (assuming the plugin management plugin is enabled), but the site admin can configure which plugins users get served by default. That's the part I'm working on now. |
| [16:39:27] | <mstenta[m]> | oh cool gotcha |
| [16:39:46] | <symbioquine[m]> | Those default plugins either come along with Asset Link or another module - or are added manually by URL |
| [16:39:55] | <mstenta[m]> | gotcha yea |
| [16:40:01] | <mstenta[m]> | could you break them all out into separate submodules? |
| [16:40:13] | <mstenta[m]> | then it would just be enabling/disabling modules |
| [16:40:18] | <symbioquine[m]> | the site admin should be able to delete those plugins they've added, but only disable/enable the plugins which come from modules. |
| [16:40:31] | <mstenta[m]> | using `enforced` dependencies will delete the config when the module is uninstalled |
| [16:40:47] | <symbioquine[m]> | That's cool |
| [16:41:14] | <symbioquine[m]> | Seems a bit heavy-weight to make them all modules though... |
| [16:41:33] | <mstenta[m]> | yea... maybe. but i don't think it has any real performance impact |
| [16:41:47] | <mstenta[m]> | definitely "feels" that way though, i agree :-) |
| [16:42:24] | <mstenta[m]> | just sayin'... drupal already provides this "turn on/off" feature w/ modules :-) |
| [16:42:41] | <mstenta[m]> | but if you're talking about tons of plugins... maybe it's overkill |
| [16:43:45] | <mstenta[m]> | on the other hand, maybe just a very simple router+form that shows a set of checkboxes next to each, so they can be disabled, and that just gets stored in a single "simple settings" config |
| [16:44:00] | <mstenta[m]> | (default to all enabled) |
| [16:44:14] | <mstenta[m]> | and then that gets used to determine which ones to send to the client |
| [16:58:59] | <symbioquine[m]> | <mstenta[m]> "but if you're talking about tons..." <- Yeah, there'll probably be a lot in the long run |
| [17:21:12] | <symbioquine[m]> | <mstenta[m]> "on the other hand, maybe just..." <- I'm liking how the config entity version is working. I think I might make the UI code add a flag to the entities that were defined via the UI and make a `AccessInterface` implementation that only allows access to the delete route for the entities with that flag. |
| [17:21:58] | <symbioquine[m]> | Thanks for the tip about the `enforced` trick, that'll be useful for the docs on contrib modules that provide Asset Link plugins. |