| | 73 | |
| | 74 | Cases where we might want to send a message, but lack a pentity, include: |
| | 75 | * Temporary users during registration processing. |
| | 76 | * The approver, currently only denoted by an email address. |
| | 77 | * Distribution list members, who may not be site users. |
| | 78 | |
| | 79 | Two main options for supporting addresses without associated pentities: |
| | 80 | * Add a bare address field to the outbound message queue elements. |
| | 81 | * Give the bare addresses a pentity, and a pr_contact entry. |
| | 82 | |
| | 83 | The give-it-a-pentity option is appealing because it allows any form of bare address, not just email. It also avoids (to some extent) the need to modify queue processing. For registration, one might hand this pentity over to the temporary user on successful completion of registration...or just get rid of it when the user completes registration and receives their "real" pentity. |
| | 84 | |
| | 85 | For a bare address field in the queue entry, if we want to allow other than email, we'd need to specify the type somehow (e.g. by including the IANA scheme in the address or also adding a type field). |
| | 86 | |
| | 87 | A case in which assigning a pentity is awkward is the approver. We shouldn't ask the site to create a user for their approver and then enter the pe_id in their config file. It's mainly awkward because we don't have web setup. Once we have web setup, we'll have to deal with saving site config info somewhere -- file or database or... -- so saving the pe_id of the approver won't be different from saving the key for any other selected configuration item that's a record in the database. There's an additional awkwardness in that the site will have to add the approver as a user before they can configure them as the approver, so they'll have to get that user in before they can start registering other users normally. Is this case sufficient to derail the option of giving bare addresses pentities and contact records? |
