GRCPRD-2712 - Unable to delete folders. Priority: Major

Hi Matias,

Thanks for reaching out to support with your issue.

Based on our wiki, it appears as though the current Folder Deletion process requires the content to be removed prior to removing the content folder.

In the case of a folder containing private content, this would imply that a user with access permissions would have to remove the private content first; I could see how this can be an issue in some circumstances.

There may be a way to get a list of private content from the backend; I will look into this, but that doesn't appear to be a viable solution in this case. It's also possible to migrate user content elsewhere upon the user's deletion, but again, that's not an acceptable workaround here. What you're after (the force-delete role or option) would need to be implemented as a software enhancement.

In order to submit this developer task request, I'll have to replicate the behavior, and your steps are exactly what I'm looking for, I just need a bit more information -

Could you provide details on the build date of the affected instance found at <url:port>/info.jsp?

Also, could you provide details on the role configuration of User A and B?

Thanks,

Eric

Hi Matias,

Did a little more digging on this, this query may be of use to you in the meantime -

https://community.yellowfinbi.com/topic/how-can-i-find-content-owned-by-deleted-users

There is also an idea that has been submitted that has some overlap -

https://community.yellowfinbi.com/topic/allow-a-power-useradmin-to-view-all-content-irrespective-of-security

There's been some recent movement on this task but developers are a bit wary of security implications, I could simply add you to this task if you think this would cover your needs.

Thanks,

Eric

Hi Eric,

Thanks for your quick reply. We have been able to delete the folders / their content through the database when our customers complain about it. But we keep getting these requests and it's really not viable for us to do this kind of thing on the regular.

Thanks for the idea link. I +1'd it.

The roles are what we call Report Writer (see attached "Report Writer Permissions.png") for a role that can create private reports, and Report Admin (see attached "Report Admin Permissions.png") for a role that has access to some administrative tasks and would like to delete folders where users no longer in the system have created reports (they can also create private reports so it could be two Admins).

System information

Application Version: 7.35 Build: 20180427 Java Version: 1.8.0_192 Operating System: Linux 4.14.109-80.92.amzn1.x86_64 (amd64)

Cheers,

Matias

Hi Matias -

Thanks for the additional information here, so I could fully test your setup. Just wanted to confirm the steps I've taken for replication -

-using the report writer role for user a, I cannot create a content folder.

-using the report admin role for user a, I cannot create a report.

I had to "flip-flop" the two roles roles appropriately, and was then able to make the folder and add reports with user A as per your instructions.

I then made user B a "report admin" with the role permissions provided.

I was not able to see either report, which is expected based on security settings of the folder and report....

Also was not able to delete either folder from the browse or admin console sections. received the error you're experiencing.

Afterwards, just to make sure it wasn't a role based issue, I made a "super admin" with all roles - still not able to delete the affected folder or subfolder.

So it's confirmed- there's not a way to "delete" folders with private content without enabling user access at the folder or report level. I had this hunch but it's nice to confirm, thanks for the instructions.

So it looks like what we need is a role permission that gives the ability to bypass this error message, something like this:

Does this sound like an appropriate approach to this enhancement request? If so I can send it off to developers for review.

Thanks,

Eric

Thanks Eric, I also used my 'super admin' role and a normal Report Admin role to test this last (Report Admin creates folders and reports, then super admin tries to delete; just as you tried) and that's why my reproduction steps don't align properly with the roles I provided afterwards, my bad.

Your proposed enhancement would work for this specific scenario, however what I think would be more broadly useful, would be a role permission to view and edit private content of other users. Sometimes when a user leaves a company, other users not only want to clean up the environment and delete the previous user's folders, but some of those inaccessible reports would be useful for the user's replacement. Force-deletion would fix the clean-up part, but would also mean that all that work is lost and needs to be redone.

Cheers,

Matias

Hi Matias,

you have a good point here, there is the option to migrate content upon deactivation or deletion of a user -

but there's not the option to do this outside the user deactivation or deletion process.

Would you like to go forward with a possible role creation that would have this ability?

Thanks,

Eric

Hi Eric,

I wasn't aware of that option since our users never actually delete or deactivate another user in YF directly (we serve YF as part of our whole product platform and thus have user management at a higher level outside of YF). But yeah I think a role option to have this 'super admin' ability would be the most ideal, both for our particular implementation of YF, as well as in general for other people's implementations.

Cheers,

Matias

Hi Matias,

Thanks for clarifying with me. I have gone ahead and submitted an enhancement request to developers on your behalf - "User Role - View / Edit private reports." This ticket has been attached to the task, and your organziation included as an affected client. Updates to the task will be provided here as they are available. I will in turn mark this as Idea Logged; feel welcome to reply to this ticket with related inquiries.

Thanks,

Eric