Problem/Motivation

When a user masquerades, using the Masquerade module, there may be times when these events need to be logged.

Steps to reproduce

N/A

Proposed resolution

Add a submodule to ELT that includes the ability to log these events.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Issue fork events_log_track-3528891

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

tregonia created an issue. See original summary.

tregonia opened merge request !78

solideogloria made their first commit to this issue’s fork.

solideogloria’s picture

solideogloria commented

It looks like the commits were added to the 4.0.x branch instead of to the issue-specific branch '3528891-masquerade-support'. I'm not able to pull the changes, because the 4.0.x branch tracks origin/4.0.x

solideogloria changed the visibility of the branch 4.0.x to hidden.

solideogloria’s picture

solideogloria commented
Version: 4.0.2 » 4.0.x-dev
Status: Active » Needs work

I'm merging the changes into the issue branch.

https://git.drupalcode.org/issue/events_log_track-3528891/-/merge_reques...

solideogloria’s picture

solideogloria commented

When it comes to my thoughts on the feature, I was just about to try creating a custom module to do just this. I'm all for it, as masquerading is something that should be easy to audit.

solideogloria’s picture

solideogloria commented

I would suggest some changes, however. Being able to masquerade doesn't necessarily mean you are an admin. I think the code should use "user" and "target_user", the same way the Masquerade module does.

solideogloria opened merge request !79

solideogloria’s picture

solideogloria commented

MR !79 is now the correct MR to work on, as it's from the issue branch into the project branch.

solideogloria’s picture

solideogloria commented
Status: Needs work » Needs review

Please review MR !79

solideogloria’s picture

solideogloria commented
Assigned: tregonia » Unassigned
solideogloria’s picture

solideogloria commented

I will also note that I've never used this module before, and I have not tested it. If this feature gets added, I will have a reason to use it.

tregonia’s picture

tregonia commented

Found that the handlers were overriding the config handlers, but setting the records as type user. Updated the instances to user masquerade.

tregonia’s picture

tregonia commented

@solideogloria

I would suggest some changes, however. Being able to masquerade doesn't necessarily mean you are an admin. I think the code should use "user" and "target_user", the same way the Masquerade module does.

Setting the handlers to user makes sense, but would need the module to refactor the $handlers['user'] to not override the existing user module; plus it would need a dependency on the event_log_track_user module. Instead, these have been updated to isolate them just to Masquerade.

  $handlers['masquerade'] = [
    'title' => t('Masquerade'),
    'operations' => [
      'Masquerade',
      'Unmasquerade',
    ],
  ]
smustgrave’s picture

smustgrave commented
Version: 4.0.x-dev » 5.0.x-dev
Status: Needs review » Needs work

Can this be converted to OOP hooks for the 5.0.x branch. With test coverage please

smustgrave opened merge request !91

smustgrave’s picture

smustgrave commented
Status: Needs work » Fixed

I went ahead and merged to 4.0.x since it was done. Then opened a separate MR for 5.0.x with test coverage

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • smustgrave committed 82650209 on 5.0.x 
    feat: #3528891 Add support for tracking Masquerade events

smustgrave closed merge request !78

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.