how to refactor user-permission system?

Question

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 (making a total of 7)?

Answer 1

One way of doing it is to have a table of features, and each user type can have some subset of features. Write some function(s) that checks a user for a feature and wrap various blocks of code.

if (hasFeature(user,feature)){
 ...
}


if (hasAnyFeature(user,features...)){
 ...
}


if (hasAllFeature(user,features...)){
 ...
}

Answer 2

You could do a partial refactor, working towards something like a role-based system. Everywhere it's currently testing fake-user, replace that with a call to a function, passing in the desired capability. In the function - for now - return the value of fake-user, ignoring the parameter. As new requests come in and the proper design makes itself known, it will be easier to transition because you've got a head start on it.

And if that time never comes, at least you've got an arguably more expressive design for current needs.