I've written some code to allow for a Draggable Table of all email fields attached to parties in the configuration. The highest (existing) of which will be added as a mail property to the party on saving that party.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1885274-3-temporary_fix_for_multiple_emails.patch | 2.98 KB | andrewbelcher |
| #1 | party-1885274-allow_multiple_primary_email_fields_ui.patch | 7.19 KB | yanniboi |
Comments
Comment #1
yanniboi commentedComment #2
yanniboi commentedComment #3
andrewbelcher commentedI think long term we want something exportable, but for the mean time here is a patch that allows us to get past the problem.
Comment #4
rlmumford#3: 1885274-3-temporary_fix_for_multiple_emails.patch queued for re-testing.
Comment #5
rlmumfordThanks, guys! We'll do something better than this with rules eventually
Comment #6
joachim commented'email2'? That's not a good pattern! (http://c2.com/cgi/wiki?ZeroOneInfinityRule)
Comment #7
andrewbelcher commentedYes, it is a bad pattern, but it is an extremely temporary fix. We are thinking that a good solution to it is to make use of Rules. We can set up some triggers and then let rules do all the processing. It already has the whole data selector UI, traversing through data sets, exportability and overrides, sorting etc. It also allows us to introduce conditions so we can do more complicated logic than simply sorting if we wanted to. This would also apply to the name label stuff which is really just another case of 'primary field'. But we'll create another issue to discuss that properly!
Comment #8
joachim commented> We are thinking that a good solution to it is to make use of Rules
Please NO not Rules!