Fix for #8916 #8917 #8918 The Community Administrator should not be able to view all communities/collections in the create/edit community and collection sections. Previous PR #9814

[im-shubham-vish]

References

• Fixes The Community Administrator should not view all communities in the edit section DSpace#8916
• Fixes The Community Administrator should not view all collections in the edit section DSpace#8917
• Fixes The Community Administrator should not view all communities in the create collection section DSpace#8918
• Previous PR Fix for #8918 The Community Administrator should not be able to view all communities/collections in the create/edit community and collection sections. DSpace#9814

Description

The Community Administrator should not be able to view all communities/collections in the create/edit community and collection sections.

Instructions for Reviewers

Currently, users can see all communities/collections in the create/edit community and collection sections. However, the expected behaviour is that only the communities/collections where the user is a community or collection admin should be displayed.

List of changes in this PR:

• Added new method getAuthorizedCommunity in community-data.service.ts to get all communities for the user is authorized to.
• Added authorized-community-selector.component.ts wrapper to show the autocomplete results in community edit section instead of using common DSpace Object selector.
• Updated create-collection-parent-selector.component.ts, create-community-parent-selector.component.ts, edit-community-selector.component.ts to get authorized communities list at the time of new collection & community creation.
• Updated edit-collection-selector.component.ts to list out already existing collections in which the user authorized to inside edit collection module.
• Updated src/themes/.../create-community-parent-selector.component.ts to list already existing authorized communities.
• Updated wrapper dso selector create-community-parent-selector.component.html to select authorized communities only inside the create community module.
• Added create-collection-parent-selector.component.html, edit-community-selector.component.html, edit-collection-selector.component.html to select authorized parent communities & collections only inside the create and edit community & collection module.
• Added authorized-community-selector.component.spec.ts against the new dso selector wrapper added to test the listing of all authorized communities and collections in edit and create section.
• Updated create-community-parent-selector.component.spec.ts, edit-community-selector.component.spec.ts, create-collection-parent-selector.component.spec.ts, edit-collection-selector.component.spec.ts to test the listing of all authorized communities & collections inside edit & create community and collection module.

How to Test

1. Make a user the admin of a few communities.
2. Navigate to the “New” section and click on "Community" or “Collection”. Only the communities where the user is community admin should be displayed.
3. For the Edit section:
   o Go to Edit > click “Community”. Again, only the communities where the user is an admin should be shown.
   o For collections, go to Edit > click “Collection”. Only the collections where the user is a collection or community admin should be listed. If the user is a community admin for a community, all collections within that community should also be shown.

Bug Reproduction Steps

1. New Section:
   o Log in as a community admin, go to New > Community. Currently, all communities are shown in the list.
   o Similarly, for collections, go to the New section > click Collection. Here, all collections are shown in the list.
2. Edit Section:
   o Log in as a community admin, go to Edit > Community. Currently, all communities are shown in the list.
   o Similarly, for collections, go to Edit > click Collection. Here, all collections are shown in the list.

[PitbaranK]

@alanorth,
Could you please help test this again, as you had tested it earlier as well?
Reference: DSpace/DSpace#9814 (comment)

[EikLoe]

Hi @im-shubham-vish ,
Thanks for the PR, it is really helpful. I tested it locally and it worked good for me! 👍🏾 I couldn't find any problems caused.

[tdonohue]

Thanks @im-shubham-vish ! Overall, this looks great. However, I've found a bug in one scenario. Here's what works and doesn't work for me:

• New -> Community/Collection (Both are fixed to limit to only showing the parent Communities that you have Admin privileges within)
• New -> Item (Still works to find Collections that you have submit privileges for)
• Edit -> Community (Fixed to limit to only showing Communities that you have Admin privileges within)
• Edit -> Collection (BROKEN. Shows Collections that you have submit privileges for, like New->Item. It should instead show Collections that you have admin privileges for.)

I believe I've found the issue, which is that the <ds-authorized-collection-selector> defaults to only checking for submit privileges. Another minor comment inline below.

Basically, this solution is looking better. You just have one more bug to fix in "Edit -> Collection".

[tdonohue]

Tiny thing. The phrase "entity type" has no meaning here. This probably should just say something like describe('when search is called'). Or you could just remove this nested describe and just go right to the it() method below.

[PitbaranK]

Thanks @tdonohue,
We have incorporated the changes requested.

[tdonohue]

👍 Thanks @im-shubham-vish and @PitbaranK ! This looks good to me now and works well. I've flagged this for automatic backport to 9.x and 8.x. Unfortunately, though we'd likely need a separate PR for 7.6.x (dspace-7_x) because it used *ngIf instead of @if (see my note inline below).

[tdonohue]

NOTE: I don't believe this @if syntax will work for DSpace 7, because it was introduced in Angular 17 (which we first used in DSpace 8). In DSpace 7, this same behavior was controlled via *ngIf.

So, this just means that I'm only attempting to backport this to DSpace 8.x and 9.x. If we want to backport also to 7.6.x, we'd need a separate PR.

[dspace-bot]

Backport failed for dspace-8_x, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin dspace-8_x
git worktree add -d .worktree/backport-4639-to-dspace-8_x origin/dspace-8_x
cd .worktree/backport-4639-to-dspace-8_x
git switch --create backport-4639-to-dspace-8_x
git cherry-pick -x 5aab53e064a2cbb03f11435b1763b7cc800b8d82 a26c718db47d71b2e986389f664b73a5c087fe98 15d9cb0ea8f4053163a0ac8b15b752870351ed9b

[dspace-bot]

Successfully created backport PR for dspace-9_x:

• [Port dspace-9_x] Fix for #8916 #8917 #8918 The Community Administrator should not be able to view all communities/collections in the create/edit community and collection sections. Previous PR #9814 #4721

[tdonohue]

I take it back, this PR can only be backported to 9.x. In 8.x, it looks like we also used *ngIf instead of @if, which is why this PR cannot be backported easily into dspace-8_x. So, a separate PR would be necessary to backport this to dspace-8_x and dspace-7_x. @PitbaranK or @im-shubham-vish , if you are interested in backporting it, let me know.

Otherwise, this will only be fixed in 9.2 and 10.0

[PitbaranK]

Hi @tdonohue,
Thanks! We have raised the backport PR #4724 for dspace-8_x & dspace-7_x against the same. Kindly align reviewer.

[tdonohue]

Backported to 8.x in #4724 and 7.x in #5123