Anything related to work in the current sprint is fixed, we don't even consider them bugs and do not write them up as such. We only consider something a bug if it is part of something we already considered Done.
When a new bug arises, we add it to the backlog and it get prioritized by our stakeholders. If we have time remaining in a sprint, we tend to tackle easier bugs that may have lower priority but are something we can complete in the time remaining.
Scrum, Kanban or any other Agile methodology is primarily a methodology focused on software development projects. In other words, it is a project management practice by its very nature.
As much as you desperately want you and your team to be doing project work, you will find that Agile will just simply not work in your organization because of the fact that you really are not doing "project" work or devoting yourselves as a team to a "project commitment".
You may organize a mini project around a complex feature, but in reality you have no connection to business analysts or the end users so how can you verify that you are delivering on User Stories when you have no way of really knowing what it is the user wants?
Your only stakeholder is your boss, and he basically ensures that your team doesn't exist to serve the other stakeholders of the project, you exist as a team to serve him and his needs regardless how this affects the other stakeholders.
On top of all of that, he is giving individual tasks to individuals and probably reprioritizing things immediately as he decides that they should go. You can't function in an Agile project methodology if individual project resources are going to reprioritized at a moments notice, or if the sprint will be put on hold.
It is not supposed to work like that
A sprint is a commitment by the entire team to deliver a subset of user stories by a specified date. Once started, a sprint should be gone through to completion before any reprioritization or changes are to occur. How is a project supposed to be managed when run in such a chaotic ad-hoc environment?
You don't work in an environment that is conducive to Agile project management methodologies. You don't even work in an environment conducive to Waterfall methodologies. You work in a monarchy and you are merely the kings pawns doing his bidding and putting out fires.
This is not the makings of a software development project team.
So in a very obscure way I am answering your question in saying that in your situation that it really doesn't matter if individuals are playing multiple roles. You have much bigger problems on your hands. You are asking how to get water stains out of carpet on a house without a roof.
Best Answer
Read this excellent article from Ron Jeffries and you will understand what needs to be done.
If you want to do Scrum, you have to follow the rules. If you don't follow the rules, it's not Scrum. And you shouldn't expect it to work.
There is plenty of space in Scrum to adapt the rules to the local team, but only once the basics have been mastered. This sounds like a prime example of a group of people who decided to alter the rules before they truly understood what they were doing. The principle of Shu-Ha-Ri applies here (and in many other places).