How to expand and integrate privileges in Attachments (ATT-9)

In the attachment module basically, the user can see attachment page , only if the user has “” privilege. So inside the attachment.jsp none of the “gallery” or “file upload” div can’t be displayed if the user has that mentioned privilege because of the if statement.

But when i have changed the privilege name inside the if statement to a different one still above 2 div components is loading in the page. What can be the reason for that ?

You mean if you put a random string here instead of "App:"?

<% if (context.hasPrivilege("App:")) { %>
<% } %>

yes , i am talking about changing that statement.

Could it be that you are logged in with a user that has full privileges?
If so then whatever you do, the privileges won’t be checked against this user (I think).

The best way to check this is to log as a user whose roles don’t encompass the App: privilege.

I would suggest to have a look in the wiki for resources about roles & privileges and play around. Does that make sense?

1 Like

Actually, you are right. It happens when a user has full privileges and then the system won’t check any privileges against that user. Since I was creating users using manage user page I had no other option than to create user accounts with full privileges. But later I try with system administration page and I was able to create users without assign full privileges.

But I create a user who is having App: privilege and then change the privilege name inside the above mentioned if statement. SO then that user not able to load the attachment page since the user has no matching privilege. I think now I understand how it works. Thank you very much for your help and awesome explanation.

And one more question, So let’s say we put some new privileges to our attachment module (UI side ) and use that privileges to access some functionality. But we are not adding that privileges to the main system. So my question is that if some user has full privileges (admin), does that newly added privileges ( which user haven’t yet ) will be a problem for them? ( since the system won’t check any privileges against that user )

Yes you anticipate correctly that by adding privileges to parts of the app that didn’t require them until then, we would lock users out of functionalities that they have been using.

One way to workaround this is to ensure that all roles that contain the original privilege get added our new privileges through the same commit that introduces those new privileges. That way the users won’t notice any changes, until their administrator(s) starts dispatching the new privileges according to their business needs.

Technically we can do this with a Liquibase <insert/> chanset in the role_privilege table.

@dkayiwa how is this handled in general? How is it dealt with when more restrictive privileges are introduced? I browsed a few JIRA tickets but couldn’t find such a commit…

1 Like

Are you looking for something like this?

Yes! Perfect. @ridmal the commit in question is here. See the changes made to liquibase-update-to-latest.xml.

1 Like

Yes, i saw that. Thank you @dkayiwa for your help. so can we do the same with the attachment module? I am talking about adding upload and delete privileges. Which means do we provide upload or delete functionalities based on existing privileges?

Or add additional two privileges in the system directly such as App: attachments.attachments.upload and App: attachments.attachments.delete for provide those functionalities?

@ridmal I’m not sure I fully understand your question(s). Would you mind rephrasing?

No, I will explain it again.

So as described in ATT-9 we need to add two different privileges to the user for upload and delete functions in attachment module. So I am asking

  1. do we need to directly add those two new privileges in the system and assign them to users


  1. Do we assign those new privileges to the user based on the existing privileges ( with the help of liquibase-update-to-latest.xml) without directly added them to the system?

Actually, I am not sure about the accuracy of this questions. So if these questions do not make any sense please ignore it.Thank you @mksd for asking again about this.

  1. Yes the PR/commit will create those new privileges and will not associate them to roles. The way it works is that you create roles as a collection of privileges. And then you grant roles to users, you don’t really just grant a privilege directly to a user.

  2. Liquibase will be used for backward compatibility only here. Just to ensure that all the roles that were granted the currently existing privilege will also be granted the two new privileges. That’s just to not lock users out of the functionalities that they had been using.

Ok, Understood perfectly. Thank you very much @mksd or clarifications. I can work on this now.