The Permission Spreadsheet



  • Continuing the discussion from In case HTML changes the spec one day...:

    @presidentsdaughter said:

    Hey, don't mock. I bet the poor soul has a manager that says "STATIC CODE ANALYSIS!", and we all know those tools hate 'magic' values.

    Speaking of code analysis, those guys definitely win in the "Useless LOC" olympiad. Though I guess they owe their medals to the client...

    For purposes of anonymization, let's assume we're dealing with a bug-tracking software (which surprisingly isn't also a forum). Tehre are various bug categories (UI bugs, functionality bugs, security bugs...), a total of ten, and each one has a slightly different workflow - and gets directed to different users.

    What I was told to do was to document the permission system - basically, what are the conditions for you to be able to see this tab, or edit this field - in a form of an Excel spreadsheet. I expected maybe a few user roles, and a straightforward logic. Boy was I wrong.

    The "SecurityClasses" folder consists of 15 classes. Each of those classes has from 10 to 60 different boolean properties - for example, the UIPermissions class would have the UICanSeeBugDescription, UICanEditReproduceScenario, etc, etc. It's way overengineered, but it wouldn't be so bad - just tedious.

    The bad part happened when someone didn't like the fact that permissions were specified explicitly, and decided to impose a hierarchy on those properties.

    So now instead of a few straightforward ORs and ANDs per each permission, you'd get a complicated hierarchy - for example, you can edit the bug description if bug description is visible to you and you're the client contact for this particular bug report; the bug description is visible to you if you're either the client contact or the team member, and the bug has passed the triage, and you can see the bug if blah, blah, blah.

    Often you'd have to drill through five or six levels of various properties to finally get to the end point.What makes the matter even worse is that some conditions are role-specific, some depend on report status, some of its properties, and other on whether or not you've been assigned to the report. Good goddamn luck mapping it to an Excel spreadsheet.

    I've spent a week drilling through all the code, finally coming up with a spreadsheet which roughly approximated this mess. And then I get another task:

    "Replace the property names in spreadsheet with functionality they represent".

    So, for each of a total of almost 200 properties, I need to hunt it down in each of the workflows, see what it does from the user standpoint, and document that. Oh, and there's no "admin override" option to have all those permissions - if you don't see an UI element, tough luck, go find it in code, go find the control on which it appears, the tab on which the control appears, the page on which the tab appears...

    Fucking hell.

    Oh, and the cherry on the cake are the "common permission idioms". So instead of isUITeamManager || isUITeamMember || isClientContact || isAdministrator, you'll have a isUITeamManagerOrUITeamMemberOrClientContactOrAdministrator, which has been refactored, since this particular combination of permissions is used exactly twice.

    (and this name is not an exaggeration either - one of the properties has eight user roles lumped into it).


  • ♿ (Parody)

    Welcome to Real World Requirements!



  • I am dealing with something similar from our company, where we have a published application matrix [excel document] each week. I built a tool that slurps up the excel document from it's published location,, and imports the data into a database based on excel sheet for sane consumption.

    I strongly recommend you consider the same. It took about a day to get all the wrinkles ironed out, but it's saved me metric assloads of time in creating actionable items, auditing permissions, automating flags of requiring setup/permission changes/terminations, etc.



  • I belive that the term is over-engineering



  • @chubertdev said:

    I belive that the term is over-engineering

    That's what he said.

    @Maciejasjmj said:

    It's way overengineered



  • Hidden in the TL;DR, yeah



  • @HardwareGeek said:

    That's what he said.

    Worst punchline ever.

    @Matches said:

    I am dealing with something similar from our company, where we have a published application matrix [excel document] each week. I built a tool that slurps up the excel document from it's published location,, and imports the data into a database based on excel sheet for sane consumption.

    The point is, we don't even have the Excel document. We have a pile of WTFy code. And I'd rather fuck myself with a cactus than parse that.

    I've considered putting the whole thing into Prolog, then I remembered I can't do Prolog.



  • Wait, wait wait wait. Your spreadsheet comes without a spreadsheet? D:



  • No, my code comes without a spreadsheet, which I have to make. Nor any design documents. Nor any client correspondence. Just a pile of code.



  • ClosedXml to the rescue! :D


  • ♿ (Parody)

    @Maciejasjmj said:

    No, my code comes without a spreadsheet, which I have to make. Nor any design documents. Nor any client correspondence. Just a pile of code.

    This is what xhtml is good for. I was in this situation recently (last year or so), but our permissions are generally expressed as a disabled attribute in JSF tags. Since all of our stuff was xhtml, it was pretty easy to run it through an xml library and build the spreadsheet.


Log in to reply