Also adding a patch
MegaKeegMan → created an issue.
Well I am actually now a little unsure if this is the same issue, but I think it is. I am having this issue only on one of my content types, and it seems to only be breaking while generating sample content for a tag reference field. It is very strange because this same field is on several other content types, but only this one content type breaks. Additionally, it doesn't matter which display I am using. Default breaks just the same as Full, which is too bad because finding this issue had my hopes up that I could just avoid using Default. And lastly, whenever I hit my exception (invalid value) a new tag actually persists, despite the problem being that the value was invalid. Every time layout builder fails to render the preview, I get a new sample tag (taxonomy term).
@mlncn I was able to resolve that issue via a patch on
https://www.drupal.org/project/drupal/issues/3087632
🐛
MenuLinkContent menu_name max length is too long
Needs work
However, I believe that we are running into this issue as well
I am working on a site that uses layout builder, and the preview on the manage layout page runs createWithSampleValues which does result in the database error:
String data, right truncated: 1406 Data too long for column 'menu_name'
I applied patch 48 and the error went away. Drupal 10, PHP 8.1
MegaKeegMan → created an issue.
This feature actually does work (not all of the details you mention). However, it is worth noting that you can add the receipt field to the orders view and then grant the permission to view order as well as the permission to view receipts. This way, a customer is able to view their receipts. However, like you say, the path for the receipt is under the admin path, and this is very undesirable. A customer should be able to view the receipt under a non-admin path. I would like this very much!
Great, thanks for the tip. I will take a look at this and report back here about whether I use this or another approach.
MegaKeegMan → created an issue.
Changed all instances of "View display" to "View page", since all displays with a path are page displays, as far as I know. And improved my patch name.
Updating the patch for 6.1.x-dev
Okay tried reviewing this on 6.1.x and unfortunately does not apply
Maybe a big ask but a token would be cool
I am trying to use this to generate default content for a distribution though. I could write a script that gets the uuid of the admin, updates the uuid in each default content zip, and then imports. But I guess the alternative is whether the import needs to respect the uuid of the referenced user, or if it could just infer that information based on the user with the given username. Any different ideas or suggestions?
Yes. The issue is that the uuid of the admin user is different between instances, so it tries to create a new user with the same name. So I guess I could just update the uuid to reflect the admin on the separate instance. Just a minor inconvenience.
MegaKeegMan → created an issue.
Note to self not to let gitlab squash commits for me
The "drutopia_core" issue fork needs review. Please ignore the "drutopia" issue fork (which was created before this issue was moved from the drutopia project queue).
MegaKeegMan → changed the visibility of the branch 3432238-a-content-editor to hidden.
When do you hit this error? It looks like you have the new code deployed. I am not particularly familiar with AEgir, and it is unclear why Drush would be attempting to re-bootstrap the system following database updates. Do you know whether the database updates are finishing?
Here is what I would recommend:
- Try performing this outside of AEgir, and see whether you are still running into these issues
- Maybe clearly document which build of Drutopia you are moving from and are going to (I realize it is possible some customization has been done)
Otherwise, per the original post: upgrading to Drutopia 2 should be the same as any other upgrade, with one significant caveat: media migration has to be performed - if you want to move to this (e.g. doing a distro-update). We do not (yet) have in place a good media upgrade process. If you want to skip this, you can upgrade to Drutopia 2 without switching/migrating to media entities, but doing a fresh install does force you into requiring a migration.
Another note—the group_permission.calculator service is provided by the group module. I am not sure what is attempting to utilize this service, but my guess is that the group module is not installed, but something else expects it to be, and I am not sure what that something is. Does your site utilize the group module?
MegaKeegMan → created an issue.
MegaKeegMan → created an issue.
As I said, I usually perform the distro update, using the module in the comment above to bring in optimizations. There are plenty, but some of the ones that are nice are related to the sites handling of images. A fresh installation of Drutopia 2 comes with media entities. It also includes optimizations of the image styles.
After the distro update, I write a custom module for my project that includes a deploy hook that uses the fieldToMediaEntity function provided by https://www.drupal.org/project/migration_helpers → . This just migrates all of the images and/or files to media entities. This method involves a bit of manual work, defining migrations via the parameters of this function call.
Alternatively, you could use https://www.drupal.org/project/image_field_to_media → to create the media fields and to migrate the images to media. When I first started using my approach to this, the image_field_to_media module did not support migrating translated media entities, and I had recently done the work of adding this feature to migration helpers. I have not checked whether this has changed. If your site does not utilize translations, this will not be an issue. You could use this module to transition to using media entities, but of course you would not get any other config optimizations without running the distro update.
I intend to take a look at adding such a deploy hook (that utilizes the migration helpers function) to Drutopia. This, of course, would not migrate images that are attached to nodes of any custom content types (or other entity bundles).
I just created and related this to an issue about upgrading an existing site to Drutopia 2 / Drupal 10. It can be simpler or more complex, depending on your goals, but feel free to leave any questions you have about this process in that issue.
I don't expect Drutopia 1 to run on Drupal 10. Drutopia 2 will run on Drupal 10 though. If you update your existing site, it should continue to work. Updating the config to be up to date with the latest installation config of the various Drutopia modules is a different story.
I have been using https://www.drupal.org/project/config_update → to bring in any optimizations to the Drutopia modules. Frankly, this approach is not particularly friendly, and involves a lot of sorting through which config changes you want to keep or get rid of. It is noteworthy that this step is optional. You can switch to Drutopia 2 without attempting to bring in the config optimizations that come with it.
Our intention will not be to continue this approach moving forward, but rather just to write update hooks whenever there are config changes in any of the modules.
MegaKeegMan → created an issue.
The documentation on the project page is out of date, and needs to be updated. Please try the following:
composer create-project drutopia/drutopia_template:2.x-dev --no-interaction DIRECTORY (replacing DIRECTORY with your project name)
You just have to configure the linkit profile, adding a matcher for media entities.
I saw that this document was updated to include a mention of the newer standard of using the .md extension, back in 2022. Is there a reason this was reverted? And can we bring that back? Usage of markdown in documentation is a very nice thing to have, after all.
MegaKeegMan → created an issue.
Adding a composer.json
If you use the git command at the bottom of the issue when creating your commit, Drupal credits will be applied properly. Would you like to try again using those details and then force push to the issue fork using the updated commit?
Also used this issue to test merge requests. Realized that I had to update the default branch to 1.0.x-dev so that MRs are targeting the correct branch by default.
MegaKeegMan → created an issue.
Please commit these changes to the issue fork and open a merge request
MegaKeegMan → changed the visibility of the branch 3423175-fix-the-issues to active.
MegaKeegMan → changed the visibility of the branch 3423175-fix-the-issues to hidden.
Looks like all of the errors are resolved by patch #4
Thanks for the contribution. I will have to remember to format the code as I build, especially the css, which is getting compiled via sassc
Though it is present, I decided to keep open, since this should probably be configured upon installation. Renaming accoringly.
My mistake. Linkit is already present in Drutopia.
MegaKeegMan → created an issue.
gusaus → credited MegaKeegMan → .
MegaKeegMan → created an issue.
MegaKeegMan → created an issue.
MegaKeegMan → created an issue.
gusaus → credited MegaKeegMan → .
Great thanks!
Glad to see this coming in. However, I just applied database updates coming from this fix and I notice that the access policy types have not been removed from config. Then this property on the config does not have any affect anymore?
Thanks for the info. I will find a time this week to watch the video you recommend. I am sure that implementing tours will be useful.
I have also found access policy types pretty confusing, and it has taken me some time to start picking up on the differences between them and why I would use each of them. While I think my understanding has improved, I still have questions. I think this will be a positive change.
As for the checkmarks. I actually think the checkmarks make sense and send the right message. For whatever reason, I did not understand that the values in the table were affected by configuration of access rules, despite the text saying so. I think what probably happened for me was that I set up my first access policy following along a tutorial, and while following a tutorial my observational powers of what was happening in the UI were a bit lessened, as I was just trying to follow steps, since at the time I lacked the confidence that I could configure the module without a guide. I didn't really start observing what was happening in that table until I started to set up my second access policy.
I don't have a single clear answer on how to resolve this. But whether in a tour or in some referenced tutorial, if while walking through how to set up an access policy there is some suggestion to look at the table before and after a rule is configured, that could help to instill some fundamental understanding for newcomers. Though I wonder how many people use a tutorial or guide initially when installing. I would assume that most people do, but it may not be a safe assumption.
The explanation currently says: "Limited means that the role has access but may be constrained by one or more access rules"
This is technically true, but I wonder if instead it should say something like:
"Limited means that the role has access but that one or more existing access rules may apply constraints"
Okay. I'm half sorry. I realized that those operations were not limited because I did not have any rules that were related to those operations. I am setting this back to "Active", not because anything needs to be done, but because I would like to take the time to consider whether there may be any UI improvements or simple documentation that could help with this. I was stumped for a bit longer than I am proud to admit, all because of a non-problem. The functionality is there though, and everything seems to be working.
I did not realize that that the access table dynamically checked whether or not their were rules applying to those operations. This makes sense, and is actually a very informative UI when you understand how to read it. Unfortunately, I had interpreted checkmarks to mean that rules CANNOT apply to those operations.
Ah hold off on attending to this please. I may be finding answers. Will update shortly.
MegaKeegMan → created an issue.
Thinking about how to manage who are group managers and members per group. I think the view bulk operation method you mentioned is definitely worth considering. However, I am considering that simpler approach might be to use https://www.drupal.org/project/cer → to sync the entity references between user and group. Will update once I have attempted this implementation. I am wondering how nicely this will work in a many to many situation.
No, but if I had a fix I would absolutely contribute it. I have actually switched to using the access policy module for my current project. I was a bit hesitant to use it at first because it is pretty complex, but I am happy to be learning it now. I am glad that you were able to reproduce the issue, though. It is a pretty strange one.
Awaiting review from client.
MegaKeegMan → made their first commit to this issue’s fork.
For convenience, I am adding this patch that comments out anything related to kss or style sheets.
https://www.drupal.org/files/issues/2024-01-11/remove_styleguide.patch →
MegaKeegMan → created an issue.
At the time of writing this issue, the module defined a field_social_post_controller. All code related to this field has been removed, and usage of this module now depends on inline_entity_form. Currently, however, the usage and configuration of inline_entity_form is not automated by the module at all. This will either require documentation and/or some more work. Switching to this model means that the post values now only exist on the microblog node.
I don't have particularly strong feelings about this, and would be okay with this direction. But I think I prefer postsave. For one, it will be clearer that this occurs later than presave. Additionally, insert, update, upsert, are all database language. Maybe my expectations are off, but I did not find this hook naming to be the most intuitive. I expect this will change between people, but as a Drupal developer I was looking for something closer to Drupal language, and not database language. I understand why insert is called insert, but it did not stand out to me as what I was looking for immediately. I think my prior point is the more important one for me. Though I am stating these preferences, I can appreciate the idea, and ultimately I really just want to see this feature in core, whatever the hook gets called.
This seems like people participating in this thread have been in agreement that this change would be a good thing. I am also in a situation right now where I am needing to implement both insert and update, and dreaming of a hook_entity_postsave. Is there anything that can be done to keep this issue moving? I would be happy to assist with reviewing patches on D10 if that will help.
MegaKeegMan → created an issue.
The plugins posting method was defined in commit f2d5175caffe819b8ac4448e6ad708d429fa370f
MegaKeegMan → created an issue.
I'm not sure yet that an access policy will be necessary for managing who can see which groups. Will there not be a way to just filter the view to only show terms that are in the current user's "group's managed" field (this is what I decided to call it).
More specifically, my thoughts are that I want to restrict who can manage a group, but not who can view it (at least in the context of the bulk operations). To clarify, I may want a group to be publicly viewable by everyone, but I only want people who have the group in their "group's managed" field to be able to see it in their group management view.
Perhaps I am mistaken, but this does not feel like something that should be handled by an access policy, but rather by a filter on the group management view. Though it is quite possible that there is yet again some nuance in configuring an access policy that I am not considering.
Very cool. I was more and more realizing that my attempt was not as the module intended. Thanks again for the help! I may try this approach, but for now I think I am just going to go ahead and use a toggle field rather than a separate access policy (though part of me thinks that the separate access policy is a better idea).
though I am running into some further complication. I currently have the widgets showing in the access tab, which in a way feels nice because they show up in the same place as the access policy selection, and because the fields that display are dependent on which access policy is selected. That is very good. However, the access policy cannot be set until after the node has been created, and the access policy selection is only available on the access tab. While I like the tab for many reasons, I sort of wish that users had a little more control over the access policy during creation.
I have considered that I can actually achieve all of my goals with a single access policy. Rather than have "Public" and "Private" policies, I could just have one, and then allow a field control whether the content is public or private. This way I could choose not to display any of this on the access tab, and actually not even expose the access tab, defaulting to the one access policy. The only thing I don't like about this approach is that the visible fields would not display conditionally based on the value in the "public or private" field, in the same way they do based on access policy. I suppose I could always introduce conditional fields module haha. Anyway will link this to the support request.
I did just notice the description on the public access policy type:
"Do not restrict view access. Control edit and delete access with permissions."
So it is starting to sound like maybe this is a matter of me just not understanding something.
In case this issue should actually be a support request, and that I am just trying to use this module incorrectly, I just want to have an access policy that allows everyone to view, but only specified users (via a field on a piece of content) to edit. I thought this was going to be very easy when I started, but then got blocked very quickly when I saw that I could not add access rules to a public access policy.
MegaKeegMan → created an issue.
I realize I am saying a lot, but if you respond to anything, I think I am most curious about the answer to my question in comment 8:
Would someone performing these bulk operations on group members require the permission to change the values in the user field?
Yes, it occurs no matter which field name I choose. I checked my config and found no traces of any of the fields. I don't believe the error to be accurate. I will investigate it again, but I have some other priorities at the moment.
About splitting up the access policies, I am not sure that I would do it the way you suggest exactly. Rather I was considering having 2 access policies:
- Public - All users can view, and therefore will not include fields pertaining to view access (Groups or users with view access). Will still have a field for users with edit access.
- Private - Only referenced groups and users referenced in the users with view access field can view. And of course will have the users with edit access field too.
Though I should still experiment with the selection sets of multiple access policies, as I would like to get a better idea of how that works and what it is like to implement.
So looks like it will be a tad simpler for now. For the short term, I will just be using groups to manage read access on content, and not for any write access. All write access will be managed by the user reference fields on the node. This may change later in development. With that being said, I am very much appreciating the flexibility that this module provides.
As far as whether I should reduce the two group reference fields (on the node) to one, this has highlighted some questions I need to discuss with our client, will follow up once I have clarification.
Would someone performing these bulk operations on group members require the permission to change the values in the user field?
Thanks for all of the feedback. It is very helpful. I will play with your suggestions a bit more and put some consideration into your bulk operations idea.
Okay, but the main issue I think I have:
groups permissions are taxonomy based. This does not necessarily have to be an issue. But A user should be able to add or remove a group (term) from another user's term reference field on the condition that they themselves are a manager of that group.
Ideally (for me) group access would be managed centrally, and not from a user reference field. I am not sure if it will be possible to restrict what values can be added or removed from this field based on the current user's access to that group, which could be granted from a variety of sources:
- edit access to that group (user reference field on node)
- edit access to that group (term reference on their account)
To clarify, in my current implementation, I have basically followed the private tutorial, and I have one access policy (though I think I will add another later). Let's just assume the one for now though.
I have four relevant fields on my node:
- Users with edit access (user reference)
- Users with view access (user reference)
- Groups with edit access (term reference)
- Groups with view access (term reference)
And I have added 4 access rules:
- Users with edit access field has reference to current user
- Users with view access field has reference to current user
- Compare Groups with edit access with user
- Compare Groups with view access with user
And user accounts have 2 related fields:
- Groups editable
- Groups viewable
Let's say I have Group 1 in my Groups editable field. In that case, I should be able to add or remove Group 1 from anyone else's Group's editable or Group's viewable fields. If I did not have Group 1 in my Groups editable field, I should not be able to do this. Though if Group 2 was in my Groups editable field, I should be able to add or remove Group 2 from someone else's account fields. Is it possible to do this in a secure way?
If yes, then the next question would be: are there any recommendations about how I could administer group management and membership all in one place, without having to edit the term reference fields on the user? (It is okay for these fields to be used still, but I just want an interface where I can administer managers and members, such that the values in these user fields are not manipulated manually.
Making progress in understanding how to achieve my goals. Maybe this is also documented somewhere, but I am configuring the access rules for my policy:
I am concerned that if I have the validation operator set to "Any" then it could grab the first access rule that the user meets the criteria for. In my example above, would a user that meets all of the rules above always be granted access by the most permissive rules provided here?
You are right. I am unable to reproduce this on a fresh Drupal instance. I do not understand either why I am hitting this error on the site for which I am looking to use this module. All I know is that it does not occur when this module is not enabled. I will report back if I learn anything. Thanks getting back to me!
Oh cool. I started following along the group content by department guide, and I got the sense that if one user was given the Content manager role, then they would essentially be a manager of every group for which they had the taxonomy term assigned to them, where I actually want them to be managers of some, and only members of others. Is that not the case, and is it actually just that every user should have both roles?
MegaKeegMan → created an issue.
MegaKeegMan → created an issue.
MegaKeegMan → created an issue.
simonbaese → credited MegaKeegMan → .
Going the route of Endroid QR code module. This module allows you to display link fields as a QR code. This is great, but in order to display the link to the currently viewed node page, you must enter the current nodes URL into a link field, which is awkward. To get around this, I have built the short alias module. This module allows you to automatically generate short aliases for your entites (which are actually redirects under the hood), and then display them. The plan is to create a sub-module for this that integrates Endroid QR codes link field formatter, so that these short alias links can be displayed as a QR code, or as a URL and a QR code.