This module, Automated Logout Alterable, provides a way to administrate session limit. The session timeout can be set per user role or by a global session timeout. Just like the module automated logout.
This module, however, also make it possible to easily alter the session timeout by other modules through an event system or even an api for client induced alterations. That way user last activity and session time left can be controlled by other modules or even other systems. For example in a decoupled setup where session expiry is controlled by a common cross envoirment service. The module works of course also without alterations from other module. Then the administred settings has priority.
Comments
Comment #2
vishal.kadamThank you for applying!
Please read Review process for security advisory coverage: What to expect for more details and Security advisory coverage application checklist to understand what reviewers look for. Tips for ensuring a smooth review gives some hints for a smoother review.
The important notes are the following.
phpcs --standard=Drupal,DrupalPracticeon the project, which alone fixes most of what reviewers would report.To the reviewers
Please read How to review security advisory coverage applications, Application workflow, What to cover in an application review, and Tools to use for reviews.
The important notes are the following.
For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues.
Comment #3
vishal.kadamComment #4
vishal.kadam1. Fix phpcs issues.
2. FILE: autologout_alterable.libraries.yml
version: VERSIONVERSION is only used by Drupal core modules. Contributed modules should use a literal string that does not change with the Drupal core version a site is using.
3. FILE: autologout_alterable.module
The usual description for a .module file is Hook implementations for the [module name] module. where [module name] is the module name given in the .info.yml file.
The description for that hook should also say for which form that hook is implemented, either by indicating that with the name of the class that implements the form (namespace included) or the form ID (which is usually indicated by
getFormId()).4. FILE: src/EventSubscriber/AutologoutSubscriber.php
FILE: src/Utility/AutologoutProfile.php
The documentation comment for constructors is not mandatory anymore, If it is given, the description must be Constructs a new [class name] object. where [class name] includes the class namespace.
Comment #5
andersmosshall commented@vishal.kadam
Good inputs. I have now taken care of the suggested changes.
But, the phpcs issue is a mysterium. When running phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml autologout_alterable/ I also got the "Use statements should be sorted alphabetically." error and the order that has been updated now makes sence for a human.
But ci in gitlabs has a different opinion of what "sorted alphabetically" means.
see: https://git.drupalcode.org/project/autologout_alterable/-/jobs/3129616
It seems like in gitlab ci "autologout_alterable" should be sorted after "Core", e.g. uppercase "C" goes before lowercase "a". Could that be system dependent?
I would very much keep it in the now updated order, which also is what phpstorm ide autoformat it to. But at the same time I dont want gitlab ci to fail on phpcs. Any idea how to resolve it?
Comment #6
andersmosshall commentedComment #7
vishal.kadamIf you have enabled GitLab CI for the project, and the phpcs job runs for each commit, fix what reported by that GitLab CI job. Clearly, that is valid if the phpcs job has not been customized to avoid most of the PHP_CodeSniffer errors/warnings.
Comment #8
andersmosshall commentedYes, but that is the thing. If I make phpcs locally happy (with the alphabetical sort order) gitlab-ci complains and vice versa.
Phpcs locally, and for you obviously, want it sorted one way. Gitlab-ci want is sorted an other. Having different views of how uppercase/lowercase fits in the alphabetical order.
Comment #9
andersmosshall commentedMaybe its a bug in gitlab-ci phpcs? Worst case I could make a skip for that phpcs rule but thats is not ideal.
Comment #10
andersmosshall commentedAha, it seems like there is not yet a consensus of what the use statement order should be
https://www.drupal.org/project/coding_standards/issues/1624564
It makes sence that I implement it as gitlab-ci wants it (even if we don't really agree with it at the moment) and change once/if the standard gets in place in gitlab-ci.
I push a revert of the alphabetical sort now to the 1.0.x
Comment #11
vishal.kadamRest looks fine to me.
Let’s wait for other reviewers to take a look; if everything goes fine, you will get the role.
Comment #12
rushikesh raval commentedI am changing priority as per Issue priorities.
Comment #13
rushikesh raval commentedI am changing priority as per Issue priorities.
Comment #14
avpadernosrc/Controller/AutologoutController.php
Since that class does not use any method from the parent class, it does not need to use
ControllerBaseas parent class. Controllers do not need to have a parent class; as long as they implement\Drupal\Core\DependencyInjection\ContainerInjectionInterface, they are fine.Comment #15
avpadernoThank you for your contribution and for your patience with the review process!
I am going to update your account so you can opt into security advisory coverage any project you create, including the projects you already created.
These are some recommended readings to help you with maintainership:
You can find more contributors chatting on Slack or IRC in #drupal-contribute. So, come hang out and stay involved!
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
I thank the dedicated reviewers as well.
Comment #17
avpaderno