@cmlara This is indeed, exactly my point (explained far more eloquently than I managed) and I can't see that any existing mechanisms mitigate that issue, hence my chosen course of action.
I do want to mention there is a good chance D.O. Staff will eventually override you either through site ownership queue or the Project Update Working Group and force either a D11 fix or a new maintainer into the project
To clarify, I have no issue with the project being passed on to a properly vetted user. I just don't have the time / resources to ascertain who that might be.
Or in your case: https://www.drupal.org/node/2332703#s-giving-up-a-project →
That still reads as though the onus would be on me (to manage an issue in this project's queue, and another in the Project Ownership project queue), and (more importantly) doesn't state anywhere how any such new owners would be vetted and whether I would need to invest time in the process. If there was a clear process for this I would follow it, but there's not and I've already spent *far* too much time debating this already.
I will be supporting this module until D10 goes end of life. I will not be accepting patches for D11 compatibility. I will not be releasing, or supporting a D11 version. This issue will remain as "Closed (won't fix)".
Abandoning means anyone could become co-maintainer without your intervention. They will be vetted by the projectownership team (Drupal.org site moderators).
I haven't seen any documentation that clearly states that that is a valid process. The document you linked to puts the onus on me to find and vet a suitable replacement. Perhaps https://www.drupal.org/node/2332703 → needs to be clearer if that is an option.
I don't understand why you keep closing it
Because I don't have the bandwidth to deal with it. My closing the issue doesn't stop someone taking the existing code and fixing up any issues if they want to, and it doesn't stop them releasing a D11 version of the module.
Also you can have other people do the vetting, you don't have to bother with that if you don't want to.
If there's a defined process for that happy to hear about it.
Please explain how an compatibility issue for D11 that is not merged, has the status needs work or needs review would make it look the module is compatible?
It sets an expectation that the changes will be merged at some point. They won't.
Well that basically means you are abandoning the module
I am not offering a version at Drupal 11 or above. As I said previously in this thread I do not have the time to vet co-maintainers, and transferring ownership to an unvetted new owner would be a significant security risk.
Just going to jump in here. As the upgrade bot is stating, just merging this patch/MR would make the module compatible with D11. That would take no more as 5 minutes, so in the time you've written those two comments, you could have probably merged it and tagged a new release 😉.
That's a big assumption. I have *no* idea of whether that is true or not, however in order to be a responsible maintainer I would have to spin up a Drupal site, and test in order to be happy to release. I don't track Drupal core development and I have no idea whether or not other changes would be required and I'm not willing to just push a release based on automated fixes without testing that it works myself.
Note that no one in this issue is asking for co-maintainership, the issue you are referring (which you closed) was indeed a bit... far fetched to be granted. But that should not hold back any other contributions being made to this module.
I am not willing to spend the time reviewing, testing and being responsible for contributions to this module. I no longer work with Drupal day-to-day and my open-source time contributions are focussed elsewhere. In the absence of that, contributions to this will not be accepted, beyond my existing commitments to support it on Drupal ^8.9 || ^9 || ^10 - hence the closure of this issue.
> So at least, let's keep this issue open so people needing it can use Drupal Rector to facilitate the patch from this issue to proceed with their upgrade path to Drupal 11.
That would set an expectation that the module is supported on Drupal 11, which it is not.
@hexabinaer Are you offering to fund my time to port & support it on Drupal 11?
In absence of that, I do not have the time to carry out the work, or to verify suitable stewardship* for the project going forward.The project is open source, so anyone willing to maintain it is empowered to fork it and release it with Drupal 11 compatibility.
*Simply signing it over to an unvetted maintainer would be a potential security issue for those 700+ active sites and is (in my opinion) a much worse option than deprecating it.
I'm not looking to take on co-maintainers of the project, or to hand over the project to others (I have neither the time, nor the means to verify the suitability of anyone to take over). If you want to release/support a fork of this module under a different name/slug for Drupal 11 or above, then you're of course free to do so.
Hi;
I'm not looking to take on co-maintainers of the project, or to hand over the project to others. If you want to release/support a fork of this module under a different name/slug for Drupal 11 or above, then you're of course free to do so.
No plans to support Drupal 11.
No further information provided as requested.
Module supports d10.
Hi;
Unfortunately Drupal 7 branches cannot be re-opened as per https://www.drupal.org/project/drupalorg/issues/3375317 ✨ [D7EOL] - Do not allow Drupal 7 branches of projects to be re-supported after Aug 1st Fixed
Glad you've got it sorted. The main product page already states the following regarding Views integration:
You can access the data in the login tracker tables either as a base view, or more usefully as a relationship against the user table.
Hi;
You need to build the view based on user logins with a relationship to user, I suspect you've done it the other way around?
Here's a screenshot of a view that works how I think you're suggesting:
https://www.dropbox.com/s/4b12dgw16o1ap42/Screenshot%202023-10-24%20at%2...
That produces the following output:
https://www.dropbox.com/s/884johd2oln6i7i/Screenshot%202023-10-24%20at%2...
Hi;
I'm afraid this patch is far from complete. If the module is going to implement hook_help then it should yield a page that is:
a) properly formatted (wrapping a markdown file in
tags doesn't count) b) translatable If you want to update the patch accordingly I'd happily merge.
Hi @dobe,
Can you turn SQL rewriting back on, and post a copy of the generated SQL *without* the patch in #195 and also *with* the patch in #195?
#195 works for me on d7.