Basie and its issues with tags and permission

Basie is far from perfect “forge” software, and that means that issues occur on all steps of the development. Our company tries to address issues as they pop up and solve them before new problems with software arise. Permission changes for tags have been a plague for our experts for a long time, and this prompted us to spread out and share our project with affiliated companies.

What the issue is and how to address it

We understand the complex nature of this matter, and thus we sent requests to underlying companies and writers to check the problem and give their opinion. This online brainstorming session had a goal to increase the chance of finding a solution in a reasonable time frame.

problem-solvedNow, here is a transcript in which one of the contributors addresses the tag permission issue and came up with some interesting answers through experimentation.

“The problems stem from tags being project-agnostic. I think the pros in this outweigh the cons, but your mileage may vary. I could change things, so each project has its own set of tags, but then I’d either have to extend the Tag model (add a project attribute) and duplicate bits of Django-tagging, or I run into the N+1 queries problem Tony was talking about earlier. For instance, when displaying all the tags for a project, we’d need to iterate through all the tags making sure each tag has least one object in the project.)

I had implemented what you suggested to start off with – the ‘remove tag’ option was available whenever you were inside a project where you have to write permission. Here removing a tag could have two interpretations. One is deleting the tag object, which would cascade delete all tag-object join table entries. This is bad, as someone would be able to un-tag objects in other projects where they didn’t have write permission.

The other option would be deleting all the tag-object join table rows in the current project, as you suggested. I found this was even more confusing, as the user could still have read access to other projects which used the tag”.

– While talking about “remove tag” issue, our correspondent gave us an insight into another problem that is related to the previous one.

“While we’re on the topic, I’d like to talk about a similar problem. Currently, the ‘tag list’ page displays all the tags in the system. If a user clicks on one, the resulting labeled item list could be empty, because the user may not have read privileges for that object. Greg and Tony were discussing a similar situation a few days back – never delete tags (right), and instead filter the results whenever a ‘list tags’ page is shown (wrong).