[MAGNOLIA-3386] MgnlRole.addPermission() writes the permission property as a string, where as it should be a number (long) Created: 15/Nov/10  Updated: 09/Oct/12  Resolved: 16/Nov/10

Status: Closed
Project: Magnolia
Component/s: security
Affects Version/s: 4.3.8
Fix Version/s: 4.3.9, 4.4

Type: Bug Priority: Major
Reporter: Ernst Bunders Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File role.tar.gz    
Issue Links:
relation
is related to MAGNOLIA-4480 MgnlContext.getUser().inGroup("xxx") ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

The consequence is that adding permissions this way does not work. The RoleEditDialog does it right, so if you add a permisson to a role, and then open the role in the dialog editor and save it again, the permission works.
Jan created a patch for this bug, which i will attach here.



 Comments   
Comment by Ernst Bunders [ 15/Nov/10 ]

Jan's patch to this bug.

Comment by Ernst Bunders [ 15/Nov/10 ]

A consideration: perhaps this bug is present in other security classes as well? I guess it would be a good idea to check on that.

Comment by Jan Haderka [ 15/Nov/10 ]

Let's try to get this out in 4.4 ... will also need to backport on 4.3

Comment by Jan Haderka [ 16/Nov/10 ]

Done as of r39130 on 4.4 and 39183 on 4.3 branches.

Comment by Dominic Bevacqua [ 17/Sep/12 ]

I am seeing the same behaviour in the RoleManager running in an install task:

RoleManager roleManager = Security.getRoleManager();
Role anon = roleManager.getRole(UserManager.ANONYMOUS_USER);
roleManager.addPermission(anon, RepositoryConstants.WEBSITE, "/articles", Permission.READ);
roleManager.addPermission(anon, "uri", "/articles/*", Permission.READ);
roleManager.addPermission(anon, "uri", "/resources/*", Permission.READ);

Only when I re-save the ACLs in the edit dialogue for the anonymous user do they take effect.

My Magnolia version is 4.5.3

Comment by Jan Haderka [ 18/Sep/12 ]

Hi Dominic,

what you see is most likely MAGNOLIA-4480

HTH,
Jan

Comment by Dominic Bevacqua [ 18/Sep/12 ]

Thanks, Jan, but I don't think that this is the case. There are no NPEs (caught or uncaught) thrown by my code snippet (in fact, none thrown throughout the installation process of which this code is a part). Also, MAGNOLIA-4480 seems poorly defined - MgnlContext.getUser().inGroup() is a method of the interface User, when presumably the NPE is thrown for a particular implementation (or perhaps more than one).

The behaviour does seem identical to that originally reported in this ticket.

Generated at Mon Feb 12 03:45:59 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.