how to refactor user-permission system?

Posted by John on Stack Overflow See other posts from Stack Overflow or by John
Published on 2010-04-06T22:53:42Z Indexed on 2010/04/06 23:03 UTC
Read the original article Hit count: 234

Sorry for lengthy question. I can't tell if this should be a programming question or a project management question. Any advice will help.

I inherited a reasonably large web project (1 year old) from a solo freelancer who architected it then abandoned it. The project was a mess, but I cleaned up what I could, and now the system is more maintainable. I need suggestions on how to extend the user-permission system.

As it is now, the database has a t_user table with the column t_user.membership_type. Currently, there are 4 membership types with the following properties:

  • 3 of the membership types are almost functionally the same, except for the different monthly fees each must pay
  • 1 of the membership type is a "fake-user" type which has limited access ( different business logic also applies)

With regards to the fake-user type, if you look in the system's business logic files, you will see a lot of hard-coded IF statements that do something like

if (fake-user)
{ // do something
} else { // a paid member of type 1,2 or 3
// proceed normally
}

My client asked me to add 3 more membership types to the system, each of them with unique features to be implemented this month, and substantive "to-be-determined" features next month.

My first reaction is that I need to refactor the user-permission system. But it concerns me that I don't have enough information on the "to-be-determined" membership type features for next month. Refactoring the user-permission system will take a substantive amount of time. I don't want to refactor something and throw it out the following month. I get substantive feature requests on a monthly basis that come out of the blue. There is no project road map.

I've asked my client to provide me with a roadmap of what they intend to do with the new membership types, but their answer is along the lines of "We just want to do [feature here] this month. We'll think of something new next month."

So questions that come to mind are:

1) Is it dangerous for me to refactor the user permission system not knowing what membership type features exist beyond a month from now?

2) Should I refactor the user permission system regardless? Or just continue adding IF statements as needed in all my controller files? Or can you recommend a different approach to user permission systems? Maybe role-based ?

3) Should this project have a road map? For a 1 year old project like mine, how far into the future should this roadmap project?

4) Any general advice on the best way to add 3 new membership types?

© Stack Overflow or respective owner

Related posts about refactoring

Related posts about roles