@alex.bukach, I tested your MR in a sandbox with drupal/countdown 8.x-1.10 and Drupal 10.2.8 and Drupal 11.0.4. The timer now counts down as expected. I see the seconds and minutes changing in real time. I will plan to test it more properly and report back.
Thank you, @alex.bukach. I tested your MR, and it is counting down as expected now. I will comment over in that ticket as well.
laura.gates → credited hannakras → .
Also confirming the module doesn't work as expected. I tested alex's patch ( https://www.drupal.org/project/countdown/issues/1591730#comment-15756791 🐛 Countdown not counting down at all Needs review ) in a sandbox with Drupal 10.3 and branch 8.x-1.x-dev, but the only apparent change was the numbers are now displaying in italics per the tags. The timer is still not counting down dynamically, but only shows a change in countdown time when you refresh/visit the page.
I could also use this feature on a project, +1. I agree that checking for duplicates should be a global module setting, and it would be nice to also have the option to update existing entities instead of just skipping them. That way the single source of truth is not confused.
laura.gates → credited hannakras → .
hannakras → created an issue.
hannakras → created an issue.
Apologies for commenting on a closed issue, but I wanted to add that I could also use this functionality (and will be implementing the custom module solution you provided, thanks!) should you wish to explore adding it in future.
Hey @john.oltman, I was using the same node to test my changes. If I updated the field instance config, then the changes were not displaying in my current node. I tried updating the confirmation message and redirect, neither worked as expected. I exported the config and cleared cache as well. When I create a new node, the confirmation message and redirect changes are reflected. It appears that registration_settings_field_data is storing the confirmation message and redirect in the database. I didn't realize the confirmation message and redirect could be set per node, and what I was affecting were actually the defaults on the content type > registration field settings, so those defaults weren't affecting previously created nodes. Now that I got that figured out, everything works as expected.
hannakras → created an issue.
Ah yes makes sense. Good call. Thanks!
Hey thanks for your responsiveness to this post and my previous one. Appreciate the change in 3.1.4.
Yes, that's correct. I wanted a user to be able to view/edit/delete registrations on the host entities / content they create but not be able to view/edit/delete registrations on content they did not create. Cordoning off access to only registrations for host entities you authored or can edit, like you said.
However, I think after reading your second paragraph and testing, I have a good enough solution. I was worried "View any registration" would provide too much access, but it seems like "Manage registrations for editable entities - Manage registrations of this type for host entities to which a user has edit access." paired with "View any registration" provides me enough functionality and the correct functionality.
In my testing, "View any registration" seemingly does nothing without "Manage registrations for editable entities" because only the host entity editor gets the 'Manage Registrations' button. Together these allow only the editor of the host entity to view any registration. So pairing these two together works for me. The host entity editor can view a listing of the registrations instead of just a summary with these two permissions. The non-host cannot view anything because they do not get the 'Manage Registrations' button. I attached two screenshots showing the different views. Is this expected behavior?
I'm fine with my users only having View capability and do not require Edit/Delete, so I can close this out unless you want to pursue this.
hannakras → created an issue.
hannakras → created an issue.
I've been looking for a module that has the above features. Any plans to work on this?
This is almost a year old now, so maybe you've found your solution, but I wanted to offer some thoughts in case you or someone else need them.
You could duplicate the admin view of the references, something like admin/content/bibcite/reference/export. Then make that duplicated view accessible to non-admins. You can use the built-in 'Bulk update' while also changing the 'Pager' settings to allow users to view 10, 50, 100, 200, or All rows. Then a user can export all records if necessary using 'Bulk update' without having to page through. I was able to do this with 1,000 rows by changing the settings to 'Allow user to display all items.'
Views Bulk Operations does allow you to create custom code for adding different options, so that could also work if you wanted to build out an 'Export reference' option.
I used Views Data Export to add an export button to the bottom of my view, but the only option that works out of the box is CSV. I tried selecting export as BibTeX, but it did not work to display the button.
The patch (2993688-117) → with "Distinct" and "Disable automatic base field for relationships" both checked works well for me to deduplicate items, but it breaks the view's autocomplete filters.
I re-rolled the patch from #97 for Drupal 10.2. There was one tiny change that broke the patch for me.
laura.gates → credited hannakras → .
laura.gates → credited hannakras → .
hannakras → created an issue.
This patch fixes the small change in the README file name in the .module file.
hannakras → created an issue.
@jurgenhaas, thank you for the etiquette tip. Will be sure to do that in future.
And thank you for pointing me in the right direction. I was able to make my workflow work using two actions, Current user: load and User: switch current account.
I'm having a similar issue. I use a custom SAML module to check whether a user logging in has the Alpha role. If that user does not have the Alpha role, then it assigns that user the role. I have a use case where some users now require a restricted role. I could update the custom module, but it sounded like ECA could do what I needed. I need to remove the Alpha role from a user upon log in and add the Alpha Restricted role. This does not work. If the user logging in has the administrator role, then it can assign itself the Alpha Restricted role, but a plain Alpha user cannot assign itself the Restricted role - due to permissions as stated by jurgenhaas.
I'm not sure what this means: "But if you enhance your model such that you switch the user context to a permitted account, then it should be working there too." I wonder if someone can offer some more details on what it means to switch the user context?
I am using ECA, ECA CM, ECA UI, ECA User.
Is it necessary to make it configurable? Emails will only fire if they are assigned to specific workflows. If you don't want Publish >> Publish to send an email, then don't assign one to it. Unless I'm missing something, it seems like this would be an okay feature to add to the module without also needing to add options/settings to the config.
Is it necessary to make it configurable? Emails will only fire if they are assigned to specific workflows. If you don't want Publish >> Publish to send an email, then don't assign one to it. Unless I'm missing something, it seems like this would be an okay feature to add to the module without also needing to add options/settings to the config.