Mike Kupfer wrote:
"Jim" == Jim Walker <[email protected]> writes:
Jim> Once you start using the new role / editing rights based approach
Jim> you have defined, it's going to be harder to untangle things.
It's not obvious to me that that's true. With the current scheme,
permissions will be granted based on existing tables in the auth
database. My understanding is that these tables already exist, and
that they will continue to exist whether or not they are used for
granting permissions.
If we change the authorization mechanism, I'd expect that to be a code
change, plus maybe some manual work to populate an additional
authorizations table. Why would those be easier if done prior to the
migration?
I assumed the db would be reloaded just prior to the actual
transition. Prior to use, it's easy to reload the table and
try out new schemes. Once you turn it loose and people start
updating elements from all directions it gets harder fast.
Jim> It would be best if you can get some or all of it untangled before
Jim> you have 200,000+ users to deal with.
I'm not following you. Are you concerned about a community backlash if
people get write access due to the migration, and then lose it again as
a result of decoupling permissions from governance status? I'd be
surprised if more than a very small fraction of users would even notice.
Yes. For example, if I'm a leader of a large community, project or user group
and spend time setting users up and get familiar with the terminology and
then it changes or I have to do it all over again, I may be upset. And,
I think even within the first 24 hours, many if not most collective leaders
will setup users as they see fit. So, many if not most website leaders and
editors would notice (ie. our most active website contributors will notice).
Cheers,
Jim
_______________________________________________
website-discuss mailing list
[email protected]
