Ticket #870 (closed Task: fixed)

Opened 5 years ago

Last modified 5 years ago

dm4-sign-up plugin: should this plugin react upon "accounts_enabled" property?

Reported by: Malte Owned by: Malte
Priority: Major Milestone: Release 4.8
Component: 3rd Party Plugins Version: 4.7
Keywords: Cc: jri, JuergeN
Complexity: 3 Area:
Module:

Description

This is a question, as jri mentioned it once that the sign-up plugin needs to be aware of the value of the "dm4.security.new_accounts_are_enabled" property?

I don't understand immediately why this should be of concern to the sign-up account creation plugin. An account is created, if it is then "Enabled" or "Disabled" could also just be up to the ACLService, no?

Thanks for your thoughts on this.

Change History

comment:1 Changed 5 years ago by jri

My note was about the notification mail(s). If we want the sign-up plugin to work also in a dm4.security.new_accounts_are_enabled=false environment the notification mail(s) should reflect the different workflow.

The email sent to the registering user should (roughly) state:

Click this link in order to activate your account. Your account is ready to use immediately.

OR

Click this link to proceed with the sign-up process. You'll receive another mail once your account is activated by an administrator. This may need 1 or 2 days.

... depending on dm4.security.new_accounts_are_enabled is true or false.

AND

in case of dm4.security.new_accounts_are_enabled=false ANOTHER notification should be sent once the administrator has activated the account:

Your account is now active.

The latter is not trivial as the Access Control service must know if a created account is the result of a sign-up process (in contrast to a manually created account).

comment:2 Changed 5 years ago by Malte

Ok, now i understand what this was about.

Just a reminder: In case of a manaally created account, currently DM4 does not know anything about an E-Mail Address (associated into the system workspace) and thus no notification mail can be send. At best sign-up could send a notification to the administrator, but therefore the dm4-accesscontrol would need to fire an event upon which sign-up could react and then send a notification mail to administration. Which seems odd to me.

For now i will take into the upcoming release:

  • notification mails with differing content relative to the new_accounts_are_enabled-setting (as proposed in #870#comment:1

Another task will probably (depending on the upcoming release cycle) be:

  • moving "E-Mail Address" topics into the "Administration" workspace instead of using "System"

For anything else i need more time and thoughts.
Cheers!

comment:3 Changed 5 years ago by Malte

To support the

  • "Your account is now active." notification another plugin should fire such an Event (config?, acl?)

Listening to this, the dm4-sign-up could happily send out such a notification mail.

comment:4 Changed 5 years ago by jri

Your plugin can use the regular postCreateTopic and postUpdateTopic listeners to react on account creation/activation. No custom events are required.

But I'm wondering how your plugin could differentiate the sign-up case from manual account creation? That is, when an administrator creates/activates an account manually in the webclient, independently from a sign-up process. No email notification must be sent in this case. No email address is required in this case.

comment:5 follow-up: ↓ 6 Changed 5 years ago by Malte

Ok, fine. So, as i understand it now, we wish to complete the plugins functionality through:

  • adapting the notification mails content regarding the new_accounts_are_enabled platform setting
  • listening to all updates on topics of type dm4.accesscontrol.login_enabled to be able to send out notification mails for "activation" (and not de-activation) of a "user account"
  • adapting it to the recently introduced "Administration" workspace #855#comment:3 (move "Email Addresses")

Regarding the latter (Administration workspace), i need to know how to deal with the most current changes which came with #846 (as i was unable to deploy one of my plugins with the current 4.8-SNAPSHOT build from source).

But I'm wondering how your plugin could differentiate the sign-up case from manual account creation? That is, when an administrator creates/activates an account manually in the webclient, independently from a sign-up process. No email notification must be sent in this case. No email address is required in this case.

If no Email is related to a "username" topic (as associated automatically by the dm4-sign-up process) no email even could be send, so why care? From my point of view this provides us a sufficient rule/distinction for the desired notification-logic.

comment:6 in reply to: ↑ 5 Changed 5 years ago by jri

Replying to Malte:

But I'm wondering how your plugin could differentiate the sign-up case from manual account creation? That is, when an administrator creates/activates an account manually in the webclient, independently from a sign-up process. No email notification must be sent in this case. No email address is required in this case.

If no Email is related to a "username" topic (as associated automatically by the dm4-sign-up process) no email even could be send, so why care? From my point of view this provides us a sufficient rule/distinction for the desired notification-logic.

We should not be careless with such a crucial aspect of sending notification mails to users we don't know. Instead we should do proper modeling here in order to reflect the nature of the task (as always). That is to explicitly model a "Sign-up process".

You're saying: "when no email address is attached to a username, we know the account was not created through a sign-up". This means we don't model the task right in the first place, and then make our logic rely on a crippled model. This is not the way to go in my view.

We might want attach an email address for manually created accounts too. On the other hand a notification mail must never to be sent to a user who didn't sign-up.

However, we are not required to do this now. We can postpone it. For myDM to work we don't need that feature (Sign-up plugin in conjunction with new_accounts_are_enabled=false) at all. My suggestion would be to concentrate on the must-have myDM features first.

Note: in the other case (new_accounts_are_enabled=true) the Sign-up plugin in its current state is fine. Modeling a Sign-up process is not strictly required as the logic is simple.

comment:7 Changed 5 years ago by Malte

  • Status changed from new to closed
  • Resolution set to fixed

For myDM to work we don't need that feature (Sign-up plugin in conjunction with new_accounts_are_enabled=false) at all.

Sure, but please respect that the next sign-up plugin release does not only need to meet the needs of myDM.

The sign-up process now models the notification logic properly via a custom Association Type ("Users Mailbox") which specifically expresses a relation of an "Email Address" (used for the initial confirmation and notification purposes) to a "Username" (during a sign-up process).

Now Optional: Email confirmation workflow:
Additionally, notifications to registrants are only sent if the "Sign-up Configuration" has checked (set) the "Email Confirmation Required" option (to "true"). The default setting for that is "false" and thus the Email based confirmation workflow is not active on plugin installation. As it is the requirement of the WTUI installation.

New Configuration option on "Administrator" notification:
Administrators receive notifications about account creations in both cases (Email Confirmation Required yes or no) as they may need to "Enable" an account. The only requirement for that is that a value in the "Sign-up Config: Admin Mailbox" must be set (and not be empty) otherwise no system notification to administratos will be sent. The new default upon plugin installation is an empty "Admin Mailbox" value, thus no "Postfix" installation is required to deploy the sign-up plugin.

Existing installations:
A migration is provided to support an existing SNAPSHOT installation (as it is the case with the current myDM).

See:
https://github.com/mukil/dm4-sign-up/commit/03e542d7ae62973a5472aa4c414c287cb394bce2

Note: See TracTickets for help on using tickets.