<div dir="ltr">Absolutely, should be a requirement of any custom or off-the-shelf solution implemented.<div class="gmail_extra"><br clear="all"><div>-- B</div><div><br></div><div class="gmail_quote">On Mon, Sep 22, 2014 at 10:10 AM, Avri Doria <span dir="ltr"><<a href="mailto:avri@acm.org" target="_blank">avri@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">agree completely.<br>
<span class="HOEnZb"><font color="#888888"><br>
avri<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 22-Sep-14 04:40, Tapani Tarvainen wrote:<br>
> Which brings me to one technical issue I've been harping about<br>
> to various people privately for some time: I see little point<br>
> in maintaining three distinct member databases, when two<br>
> are (required to be) subsets of the third. It would be much<br>
> easier to maintain just NCSG member database and have<br>
> constituency membership there as an attribute<br>
> (of course still leaving it up to each constituency to<br>
> decide who they accept as their members, they just would<br>
> not need to maintain members' contact info &c separately).<br>
> This would make for an easy workflow for the three ECs,<br>
> one place for members to check their membership details, &c.<br>
<br>
</div></div></blockquote></div><br></div></div>