You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Glen Mazza <gl...@gmail.com> on 2014/08/13 03:15:42 UTC
simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Hi team, one or both of these methods are heavily called within the
application, indeed for almost every action run:
public List<String> requiredWeblogPermissionActions() {
return Collections.singletonList(WeblogPermission.xxxxx);
}
public List<String> requiredGlobalPermissionActions() {
return Collections.singletonList(GlobalPermission.xxxxxx);
}
I've checked every implementation of both methods within the application
-- about 20-25 in all -- every one returns just a single permission
requirement, not a list of items.
I think it would be good to optimize these methods by having them return
just a string or a fast and lightweight enumeration constant. The only
thing lost I can see would be the ability to require multiple
permissions, but again within the app today and through 12-14 years of
Roller it just hasn't been needed. WDYT?
Regards,
Glen
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Glen Mazza <gl...@gmail.com>.
I'm still not persuaded on the wisdom of retaining the userrole database
table (#2 below), even if we skip the other proposals. However, as the
team hasn't shown much enthusiasm in making changes to our permissions
subsystem I'll let the matter drop, we'll keep Roller's security
subsystem unchanged.
As I see it, the userrole table buys us the ability to assign multiple
roles to the same user, a need that internally Roller has never had, as
we just have two roles: editor and admin, and assigning a user the
latter gives them the former's permissions. So the only OOTB Roller
need is to add a ROLE column to the roller_user table and it's all set,
95%+ users are unaffected and have one fewer DB table in their model.
As we have so few permissions, basically just two coded: weblog and
admin (even though we list four--including login and comment) there's
not much need to assign multiple roles to a user, as one could just
create a new role with the desired total permissions and give the user
that role:
i.e., from:
role.names=editor,admin
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin
to:
role.names=editor,admin,aaa <-- new role "aaa"
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin
role.action.aaa=login,comment,weblog,bbb <-- new role with new
permission "bbb"
Even assuming we would want to give multiple roles to the same user, the
same syntactic sugar can be had by allowing roles to be assigned to
another role, allowing a user to still just have one role:
role.names=editor,admin,aaa
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin
role.action.aaa=editor, bbb (= login,comment,weblog,bbb)
Now if Roller were to be incorporated into a larger CMS solution with
dozens of roles and hundreds of permissions (something where having
multiple roles per user might be indicated), they are in all likelihood
not going to be using our own simple userrole table but their own table
anyway.
Whenever you add additional functionality that has to be maintained,
other areas of the code begin to suffer (opportunity costs), so you have
to make sure there's enough demand for the additional functionality, and
that you gain more users than you lose due to other, more important
areas getting less attention. Also, people are naturally attracted to
simple, easy-to-understand applications that take care of their needs
with a minimum of bloat. When we remove code and database tables that
98% of users don't need, we gain more users just by having a leaner app
than we lose. And as for the 2% inconvenienced by having Roller
slightly harder to hack for their unique needs, they would probably be
more than compensated anyway due to the additional bells and whistles
added to Roller that come naturally from having a larger user community.
Regards,
Glen
On 08/15/2014 11:27 AM, Glen Mazza wrote:
> Thanks for the clarification, Anil, I didn't realize the difference
> between roles and permissions.
>
> Glen
>
> On 08/15/2014 10:34 AM, Anil Gangolli wrote:
>>
>> I agree. I think we should leave as is.
>>
>> There may be confusion about the model in place:
>> * specific permissions are checked on actions
>> * roles are defined as sets of permissions
>> * users are assigned roles
>> I think this is pretty conventional, and I think there's value in
>> keeping with that.
>>
>> --a.
>>
>> On 8/14/14 11:40 PM, Greg Huber wrote:
>>> Personally I would leave as is. Having multiple roles/authorities per
>>> action, is kind of useful if you want to extend roller. The
>>> overhead is
>>> also minimal compared with what struts does internally.
>>>
>>>
>>> On 14 August 2014 23:35, Glen Mazza <gl...@gmail.com> wrote:
>>>
>>>> Does anyone else on the team have a view? #5 below I'm no longer
>>>> sure on
>>>> so I'm withdrawing that proposal but feedback on #1-#4 below is most
>>>> welcome.
>>>>
>>>> Glen
>>>>
>>>> On 08/13/2014 04:27 PM, Dave wrote:
>>>>
>>>>> I don't see the need for this change and I would leave those
>>>>> permissions
>>>>> in
>>>>> place. They existed to support and may still be used to support
>>>>> real uses
>>>>> cases like private blogging, where only registered users can see
>>>>> blogs and
>>>>> only those with special permissions can comment.
>>>>>
>>>>> Even if they do not work fully now, they give people a way to hook
>>>>> their
>>>>> own rules into their own custom versions of Roller, perhaps by
>>>>> adding new
>>>>> code, ServletFilters, etc. And they are a starting point for
>>>>> people who
>>>>> want private blogging to be fully supported in Roller.
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza <gl...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> OK, checking Global Permission, we have these three levels:
>>>>>> /** Allowed to login and edit profile */
>>>>>> public static final String LOGIN = "login";
>>>>>>
>>>>>> /** Allowed to login and do weblogging */
>>>>>> public static final String WEBLOG = "weblog";
>>>>>>
>>>>>> /** Allowed to login and do everything, including site-wide
>>>>>> admin */
>>>>>> public static final String ADMIN = "admin";
>>>>>>
>>>>>> We don't use "weblog" though, we save it as "editor" in the userrole
>>>>>> table. We also don't use "login" for anything other than to make
>>>>>> it the
>>>>>> minimum required setting on pages that don't require an ADMIN
>>>>>> setting.
>>>>>> All
>>>>>> newly registered users are given "editor" as a minimum, meaning
>>>>>> we could
>>>>>> raise minimum from "login" to "editor" and do away with the login
>>>>>> role
>>>>>> without any difference in application behavior.
>>>>>>
>>>>>> On top of this, we allow the roles additional subroles per the
>>>>>> roller.properties file:
>>>>>>
>>>>>> # Role name to global permission action mappings
>>>>>> role.names=editor,admin
>>>>>> role.action.editor=login,comment,weblog
>>>>>> role.action.admin=login,comment,weblog,admin
>>>>>>
>>>>>> "comment" is also never used in the application, further, in the
>>>>>> above
>>>>>> list we're inconsistently assigning admin to admin but weblog to
>>>>>> editor.
>>>>>> Since the permissions are all Russian doll (login < comment <
>>>>>> weblog/editor < admin), it's sufficient to just store the highest
>>>>>> role,
>>>>>> as
>>>>>> the lower ones are all implied, i.e., we don't need these
>>>>>> properties.
>>>>>>
>>>>>> My proposal is to:
>>>>>>
>>>>>> 1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
>>>>>> enumeration, EDITOR and ADMIN. Later, if we have user demand for
>>>>>> LOGIN
>>>>>> and
>>>>>> COMMENT, and somebody actually coding in logic that uses those
>>>>>> values, we
>>>>>> can easily add in the enumerations for them. (I don't like LOGIN
>>>>>> much,
>>>>>> however, if we don't trust them not to blog they shouldn't be
>>>>>> lurking
>>>>>> around the UI.)
>>>>>>
>>>>>> 2.) The "userrole" database table will be dropped, replaced with
>>>>>> a new
>>>>>> varchar column ROLE in the Roller_User table. I'll update the
>>>>>> migration
>>>>>> script to copy the user's highest role into that column.
>>>>>>
>>>>>> 3.) The three properties "role.name, role.action.editor, and
>>>>>> role.action.admin" will be removed.
>>>>>>
>>>>>> 4.) List<String> requiredGlobalPermissionActions() will return a
>>>>>> single
>>>>>> enumeration constant instead (EDITOR or ADMIN), stating the minimum
>>>>>> accepted value.
>>>>>>
>>>>>> 5.) WeblogPermissions looks fine, except I'll just switch the string
>>>>>> array
>>>>>> of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same
>>>>>> values
>>>>>> and have requiredWeblogPermissionActions() return an enumeration
>>>>>> constant
>>>>>> instead.
>>>>>>
>>>>>> How does this sound? I have other things to work on so I'll wait 72
>>>>>> hours
>>>>>> before proceeding to give time for others to evaluate this change.
>>>>>>
>>>>>> Regards,
>>>>>> Glen
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/13/2014 08:33 AM, Glen Mazza wrote:
>>>>>>
>>>>>> If the methods return just a single permission instead of a
>>>>>> collection
>>>>>>> of
>>>>>>> permissions, at least for GlobalPermissionActions, that means we
>>>>>>> can
>>>>>>> move
>>>>>>> to "Russian doll" type role levels, where each permission level
>>>>>>> includes
>>>>>>> all the permission levels below it (de facto the way Roller runs
>>>>>>> now).
>>>>>>> If
>>>>>>> we can officially be on that, that means we can toss out the
>>>>>>> userrole
>>>>>>> table
>>>>>>> and just place a single column "rolename" (indicating the
>>>>>>> highest role a
>>>>>>> person has) in the roller_user table, a very sleek change. (I'm
>>>>>>> not
>>>>>>> talking about Roller_Permission, i.e., permissions a user has on
>>>>>>> each
>>>>>>> blog
>>>>>>> -- that table is still needed, but the userrole table indicating
>>>>>>> whether
>>>>>>> one's a global admin or not.)
>>>>>>>
>>>>>>> Glen
>>>>>>>
>>>>>>> On 08/13/2014 07:54 AM, Dave wrote:
>>>>>>>
>>>>>>> I don't have a strong opinion, but this seems like change just
>>>>>>> for the
>>>>>>>> sake
>>>>>>>> of change. I doubt that impacts performance in any significant
>>>>>>>> way,
>>>>>>>> especially when compared to all the database calls that are
>>>>>>>> made during
>>>>>>>> JSP
>>>>>>>> or page template processing.
>>>>>>>>
>>>>>>>> - Dave
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi team, one or both of these methods are heavily called
>>>>>>>> within the
>>>>>>>>
>>>>>>>>> application, indeed for almost every action run:
>>>>>>>>>
>>>>>>>>> public List<String> requiredWeblogPermissionActions() {
>>>>>>>>> return
>>>>>>>>> Collections.singletonList(WeblogPermission.xxxxx);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public List<String> requiredGlobalPermissionActions() {
>>>>>>>>> return
>>>>>>>>> Collections.singletonList(GlobalPermission.xxxxxx);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I've checked every implementation of both methods within the
>>>>>>>>> application
>>>>>>>>> -- about 20-25 in all -- every one returns just a single
>>>>>>>>> permission
>>>>>>>>> requirement, not a list of items.
>>>>>>>>>
>>>>>>>>> I think it would be good to optimize these methods by having them
>>>>>>>>> return
>>>>>>>>> just a string or a fast and lightweight enumeration constant.
>>>>>>>>> The only
>>>>>>>>> thing lost I can see would be the ability to require multiple
>>>>>>>>> permissions,
>>>>>>>>> but again within the app today and through 12-14 years of
>>>>>>>>> Roller it
>>>>>>>>> just
>>>>>>>>> hasn't been needed. WDYT?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Glen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Glen Mazza <gl...@gmail.com>.
Thanks for the clarification, Anil, I didn't realize the difference
between roles and permissions.
Glen
On 08/15/2014 10:34 AM, Anil Gangolli wrote:
>
> I agree. I think we should leave as is.
>
> There may be confusion about the model in place:
> * specific permissions are checked on actions
> * roles are defined as sets of permissions
> * users are assigned roles
> I think this is pretty conventional, and I think there's value in
> keeping with that.
>
> --a.
>
> On 8/14/14 11:40 PM, Greg Huber wrote:
>> Personally I would leave as is. Having multiple roles/authorities per
>> action, is kind of useful if you want to extend roller. The overhead is
>> also minimal compared with what struts does internally.
>>
>>
>> On 14 August 2014 23:35, Glen Mazza <gl...@gmail.com> wrote:
>>
>>> Does anyone else on the team have a view? #5 below I'm no longer
>>> sure on
>>> so I'm withdrawing that proposal but feedback on #1-#4 below is most
>>> welcome.
>>>
>>> Glen
>>>
>>> On 08/13/2014 04:27 PM, Dave wrote:
>>>
>>>> I don't see the need for this change and I would leave those
>>>> permissions
>>>> in
>>>> place. They existed to support and may still be used to support
>>>> real uses
>>>> cases like private blogging, where only registered users can see
>>>> blogs and
>>>> only those with special permissions can comment.
>>>>
>>>> Even if they do not work fully now, they give people a way to hook
>>>> their
>>>> own rules into their own custom versions of Roller, perhaps by
>>>> adding new
>>>> code, ServletFilters, etc. And they are a starting point for
>>>> people who
>>>> want private blogging to be fully supported in Roller.
>>>>
>>>> - Dave
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza <gl...@gmail.com>
>>>> wrote:
>>>>
>>>> OK, checking Global Permission, we have these three levels:
>>>>> /** Allowed to login and edit profile */
>>>>> public static final String LOGIN = "login";
>>>>>
>>>>> /** Allowed to login and do weblogging */
>>>>> public static final String WEBLOG = "weblog";
>>>>>
>>>>> /** Allowed to login and do everything, including site-wide
>>>>> admin */
>>>>> public static final String ADMIN = "admin";
>>>>>
>>>>> We don't use "weblog" though, we save it as "editor" in the userrole
>>>>> table. We also don't use "login" for anything other than to make
>>>>> it the
>>>>> minimum required setting on pages that don't require an ADMIN
>>>>> setting.
>>>>> All
>>>>> newly registered users are given "editor" as a minimum, meaning we
>>>>> could
>>>>> raise minimum from "login" to "editor" and do away with the login
>>>>> role
>>>>> without any difference in application behavior.
>>>>>
>>>>> On top of this, we allow the roles additional subroles per the
>>>>> roller.properties file:
>>>>>
>>>>> # Role name to global permission action mappings
>>>>> role.names=editor,admin
>>>>> role.action.editor=login,comment,weblog
>>>>> role.action.admin=login,comment,weblog,admin
>>>>>
>>>>> "comment" is also never used in the application, further, in the
>>>>> above
>>>>> list we're inconsistently assigning admin to admin but weblog to
>>>>> editor.
>>>>> Since the permissions are all Russian doll (login < comment <
>>>>> weblog/editor < admin), it's sufficient to just store the highest
>>>>> role,
>>>>> as
>>>>> the lower ones are all implied, i.e., we don't need these properties.
>>>>>
>>>>> My proposal is to:
>>>>>
>>>>> 1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
>>>>> enumeration, EDITOR and ADMIN. Later, if we have user demand for
>>>>> LOGIN
>>>>> and
>>>>> COMMENT, and somebody actually coding in logic that uses those
>>>>> values, we
>>>>> can easily add in the enumerations for them. (I don't like LOGIN
>>>>> much,
>>>>> however, if we don't trust them not to blog they shouldn't be lurking
>>>>> around the UI.)
>>>>>
>>>>> 2.) The "userrole" database table will be dropped, replaced with a
>>>>> new
>>>>> varchar column ROLE in the Roller_User table. I'll update the
>>>>> migration
>>>>> script to copy the user's highest role into that column.
>>>>>
>>>>> 3.) The three properties "role.name, role.action.editor, and
>>>>> role.action.admin" will be removed.
>>>>>
>>>>> 4.) List<String> requiredGlobalPermissionActions() will return a
>>>>> single
>>>>> enumeration constant instead (EDITOR or ADMIN), stating the minimum
>>>>> accepted value.
>>>>>
>>>>> 5.) WeblogPermissions looks fine, except I'll just switch the string
>>>>> array
>>>>> of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same
>>>>> values
>>>>> and have requiredWeblogPermissionActions() return an enumeration
>>>>> constant
>>>>> instead.
>>>>>
>>>>> How does this sound? I have other things to work on so I'll wait 72
>>>>> hours
>>>>> before proceeding to give time for others to evaluate this change.
>>>>>
>>>>> Regards,
>>>>> Glen
>>>>>
>>>>>
>>>>>
>>>>> On 08/13/2014 08:33 AM, Glen Mazza wrote:
>>>>>
>>>>> If the methods return just a single permission instead of a
>>>>> collection
>>>>>> of
>>>>>> permissions, at least for GlobalPermissionActions, that means we can
>>>>>> move
>>>>>> to "Russian doll" type role levels, where each permission level
>>>>>> includes
>>>>>> all the permission levels below it (de facto the way Roller runs
>>>>>> now).
>>>>>> If
>>>>>> we can officially be on that, that means we can toss out the
>>>>>> userrole
>>>>>> table
>>>>>> and just place a single column "rolename" (indicating the highest
>>>>>> role a
>>>>>> person has) in the roller_user table, a very sleek change. (I'm not
>>>>>> talking about Roller_Permission, i.e., permissions a user has on
>>>>>> each
>>>>>> blog
>>>>>> -- that table is still needed, but the userrole table indicating
>>>>>> whether
>>>>>> one's a global admin or not.)
>>>>>>
>>>>>> Glen
>>>>>>
>>>>>> On 08/13/2014 07:54 AM, Dave wrote:
>>>>>>
>>>>>> I don't have a strong opinion, but this seems like change just
>>>>>> for the
>>>>>>> sake
>>>>>>> of change. I doubt that impacts performance in any significant way,
>>>>>>> especially when compared to all the database calls that are made
>>>>>>> during
>>>>>>> JSP
>>>>>>> or page template processing.
>>>>>>>
>>>>>>> - Dave
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi team, one or both of these methods are heavily called
>>>>>>> within the
>>>>>>>
>>>>>>>> application, indeed for almost every action run:
>>>>>>>>
>>>>>>>> public List<String> requiredWeblogPermissionActions() {
>>>>>>>> return
>>>>>>>> Collections.singletonList(WeblogPermission.xxxxx);
>>>>>>>> }
>>>>>>>>
>>>>>>>> public List<String> requiredGlobalPermissionActions() {
>>>>>>>> return
>>>>>>>> Collections.singletonList(GlobalPermission.xxxxxx);
>>>>>>>> }
>>>>>>>>
>>>>>>>> I've checked every implementation of both methods within the
>>>>>>>> application
>>>>>>>> -- about 20-25 in all -- every one returns just a single
>>>>>>>> permission
>>>>>>>> requirement, not a list of items.
>>>>>>>>
>>>>>>>> I think it would be good to optimize these methods by having them
>>>>>>>> return
>>>>>>>> just a string or a fast and lightweight enumeration constant.
>>>>>>>> The only
>>>>>>>> thing lost I can see would be the ability to require multiple
>>>>>>>> permissions,
>>>>>>>> but again within the app today and through 12-14 years of
>>>>>>>> Roller it
>>>>>>>> just
>>>>>>>> hasn't been needed. WDYT?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Glen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Anil Gangolli <an...@busybuddha.org>.
I agree. I think we should leave as is.
There may be confusion about the model in place:
* specific permissions are checked on actions
* roles are defined as sets of permissions
* users are assigned roles
I think this is pretty conventional, and I think there's value in
keeping with that.
--a.
On 8/14/14 11:40 PM, Greg Huber wrote:
> Personally I would leave as is. Having multiple roles/authorities per
> action, is kind of useful if you want to extend roller. The overhead is
> also minimal compared with what struts does internally.
>
>
> On 14 August 2014 23:35, Glen Mazza <gl...@gmail.com> wrote:
>
>> Does anyone else on the team have a view? #5 below I'm no longer sure on
>> so I'm withdrawing that proposal but feedback on #1-#4 below is most
>> welcome.
>>
>> Glen
>>
>> On 08/13/2014 04:27 PM, Dave wrote:
>>
>>> I don't see the need for this change and I would leave those permissions
>>> in
>>> place. They existed to support and may still be used to support real uses
>>> cases like private blogging, where only registered users can see blogs and
>>> only those with special permissions can comment.
>>>
>>> Even if they do not work fully now, they give people a way to hook their
>>> own rules into their own custom versions of Roller, perhaps by adding new
>>> code, ServletFilters, etc. And they are a starting point for people who
>>> want private blogging to be fully supported in Roller.
>>>
>>> - Dave
>>>
>>>
>>>
>>>
>>> On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza <gl...@gmail.com> wrote:
>>>
>>> OK, checking Global Permission, we have these three levels:
>>>> /** Allowed to login and edit profile */
>>>> public static final String LOGIN = "login";
>>>>
>>>> /** Allowed to login and do weblogging */
>>>> public static final String WEBLOG = "weblog";
>>>>
>>>> /** Allowed to login and do everything, including site-wide admin */
>>>> public static final String ADMIN = "admin";
>>>>
>>>> We don't use "weblog" though, we save it as "editor" in the userrole
>>>> table. We also don't use "login" for anything other than to make it the
>>>> minimum required setting on pages that don't require an ADMIN setting.
>>>> All
>>>> newly registered users are given "editor" as a minimum, meaning we could
>>>> raise minimum from "login" to "editor" and do away with the login role
>>>> without any difference in application behavior.
>>>>
>>>> On top of this, we allow the roles additional subroles per the
>>>> roller.properties file:
>>>>
>>>> # Role name to global permission action mappings
>>>> role.names=editor,admin
>>>> role.action.editor=login,comment,weblog
>>>> role.action.admin=login,comment,weblog,admin
>>>>
>>>> "comment" is also never used in the application, further, in the above
>>>> list we're inconsistently assigning admin to admin but weblog to editor.
>>>> Since the permissions are all Russian doll (login < comment <
>>>> weblog/editor < admin), it's sufficient to just store the highest role,
>>>> as
>>>> the lower ones are all implied, i.e., we don't need these properties.
>>>>
>>>> My proposal is to:
>>>>
>>>> 1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
>>>> enumeration, EDITOR and ADMIN. Later, if we have user demand for LOGIN
>>>> and
>>>> COMMENT, and somebody actually coding in logic that uses those values, we
>>>> can easily add in the enumerations for them. (I don't like LOGIN much,
>>>> however, if we don't trust them not to blog they shouldn't be lurking
>>>> around the UI.)
>>>>
>>>> 2.) The "userrole" database table will be dropped, replaced with a new
>>>> varchar column ROLE in the Roller_User table. I'll update the migration
>>>> script to copy the user's highest role into that column.
>>>>
>>>> 3.) The three properties "role.name, role.action.editor, and
>>>> role.action.admin" will be removed.
>>>>
>>>> 4.) List<String> requiredGlobalPermissionActions() will return a single
>>>> enumeration constant instead (EDITOR or ADMIN), stating the minimum
>>>> accepted value.
>>>>
>>>> 5.) WeblogPermissions looks fine, except I'll just switch the string
>>>> array
>>>> of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same
>>>> values
>>>> and have requiredWeblogPermissionActions() return an enumeration
>>>> constant
>>>> instead.
>>>>
>>>> How does this sound? I have other things to work on so I'll wait 72
>>>> hours
>>>> before proceeding to give time for others to evaluate this change.
>>>>
>>>> Regards,
>>>> Glen
>>>>
>>>>
>>>>
>>>> On 08/13/2014 08:33 AM, Glen Mazza wrote:
>>>>
>>>> If the methods return just a single permission instead of a collection
>>>>> of
>>>>> permissions, at least for GlobalPermissionActions, that means we can
>>>>> move
>>>>> to "Russian doll" type role levels, where each permission level includes
>>>>> all the permission levels below it (de facto the way Roller runs now).
>>>>> If
>>>>> we can officially be on that, that means we can toss out the userrole
>>>>> table
>>>>> and just place a single column "rolename" (indicating the highest role a
>>>>> person has) in the roller_user table, a very sleek change. (I'm not
>>>>> talking about Roller_Permission, i.e., permissions a user has on each
>>>>> blog
>>>>> -- that table is still needed, but the userrole table indicating whether
>>>>> one's a global admin or not.)
>>>>>
>>>>> Glen
>>>>>
>>>>> On 08/13/2014 07:54 AM, Dave wrote:
>>>>>
>>>>> I don't have a strong opinion, but this seems like change just for the
>>>>>> sake
>>>>>> of change. I doubt that impacts performance in any significant way,
>>>>>> especially when compared to all the database calls that are made during
>>>>>> JSP
>>>>>> or page template processing.
>>>>>>
>>>>>> - Dave
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi team, one or both of these methods are heavily called within the
>>>>>>
>>>>>>> application, indeed for almost every action run:
>>>>>>>
>>>>>>> public List<String> requiredWeblogPermissionActions() {
>>>>>>> return Collections.singletonList(WeblogPermission.xxxxx);
>>>>>>> }
>>>>>>>
>>>>>>> public List<String> requiredGlobalPermissionActions() {
>>>>>>> return Collections.singletonList(GlobalPermission.xxxxxx);
>>>>>>> }
>>>>>>>
>>>>>>> I've checked every implementation of both methods within the
>>>>>>> application
>>>>>>> -- about 20-25 in all -- every one returns just a single permission
>>>>>>> requirement, not a list of items.
>>>>>>>
>>>>>>> I think it would be good to optimize these methods by having them
>>>>>>> return
>>>>>>> just a string or a fast and lightweight enumeration constant. The only
>>>>>>> thing lost I can see would be the ability to require multiple
>>>>>>> permissions,
>>>>>>> but again within the app today and through 12-14 years of Roller it
>>>>>>> just
>>>>>>> hasn't been needed. WDYT?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Glen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Greg Huber <gr...@gmail.com>.
Personally I would leave as is. Having multiple roles/authorities per
action, is kind of useful if you want to extend roller. The overhead is
also minimal compared with what struts does internally.
On 14 August 2014 23:35, Glen Mazza <gl...@gmail.com> wrote:
> Does anyone else on the team have a view? #5 below I'm no longer sure on
> so I'm withdrawing that proposal but feedback on #1-#4 below is most
> welcome.
>
> Glen
>
> On 08/13/2014 04:27 PM, Dave wrote:
>
>> I don't see the need for this change and I would leave those permissions
>> in
>> place. They existed to support and may still be used to support real uses
>> cases like private blogging, where only registered users can see blogs and
>> only those with special permissions can comment.
>>
>> Even if they do not work fully now, they give people a way to hook their
>> own rules into their own custom versions of Roller, perhaps by adding new
>> code, ServletFilters, etc. And they are a starting point for people who
>> want private blogging to be fully supported in Roller.
>>
>> - Dave
>>
>>
>>
>>
>> On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza <gl...@gmail.com> wrote:
>>
>> OK, checking Global Permission, we have these three levels:
>>>
>>> /** Allowed to login and edit profile */
>>> public static final String LOGIN = "login";
>>>
>>> /** Allowed to login and do weblogging */
>>> public static final String WEBLOG = "weblog";
>>>
>>> /** Allowed to login and do everything, including site-wide admin */
>>> public static final String ADMIN = "admin";
>>>
>>> We don't use "weblog" though, we save it as "editor" in the userrole
>>> table. We also don't use "login" for anything other than to make it the
>>> minimum required setting on pages that don't require an ADMIN setting.
>>> All
>>> newly registered users are given "editor" as a minimum, meaning we could
>>> raise minimum from "login" to "editor" and do away with the login role
>>> without any difference in application behavior.
>>>
>>> On top of this, we allow the roles additional subroles per the
>>> roller.properties file:
>>>
>>> # Role name to global permission action mappings
>>> role.names=editor,admin
>>> role.action.editor=login,comment,weblog
>>> role.action.admin=login,comment,weblog,admin
>>>
>>> "comment" is also never used in the application, further, in the above
>>> list we're inconsistently assigning admin to admin but weblog to editor.
>>> Since the permissions are all Russian doll (login < comment <
>>> weblog/editor < admin), it's sufficient to just store the highest role,
>>> as
>>> the lower ones are all implied, i.e., we don't need these properties.
>>>
>>> My proposal is to:
>>>
>>> 1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
>>> enumeration, EDITOR and ADMIN. Later, if we have user demand for LOGIN
>>> and
>>> COMMENT, and somebody actually coding in logic that uses those values, we
>>> can easily add in the enumerations for them. (I don't like LOGIN much,
>>> however, if we don't trust them not to blog they shouldn't be lurking
>>> around the UI.)
>>>
>>> 2.) The "userrole" database table will be dropped, replaced with a new
>>> varchar column ROLE in the Roller_User table. I'll update the migration
>>> script to copy the user's highest role into that column.
>>>
>>> 3.) The three properties "role.name, role.action.editor, and
>>> role.action.admin" will be removed.
>>>
>>> 4.) List<String> requiredGlobalPermissionActions() will return a single
>>> enumeration constant instead (EDITOR or ADMIN), stating the minimum
>>> accepted value.
>>>
>>> 5.) WeblogPermissions looks fine, except I'll just switch the string
>>> array
>>> of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same
>>> values
>>> and have requiredWeblogPermissionActions() return an enumeration
>>> constant
>>> instead.
>>>
>>> How does this sound? I have other things to work on so I'll wait 72
>>> hours
>>> before proceeding to give time for others to evaluate this change.
>>>
>>> Regards,
>>> Glen
>>>
>>>
>>>
>>> On 08/13/2014 08:33 AM, Glen Mazza wrote:
>>>
>>> If the methods return just a single permission instead of a collection
>>>> of
>>>> permissions, at least for GlobalPermissionActions, that means we can
>>>> move
>>>> to "Russian doll" type role levels, where each permission level includes
>>>> all the permission levels below it (de facto the way Roller runs now).
>>>> If
>>>> we can officially be on that, that means we can toss out the userrole
>>>> table
>>>> and just place a single column "rolename" (indicating the highest role a
>>>> person has) in the roller_user table, a very sleek change. (I'm not
>>>> talking about Roller_Permission, i.e., permissions a user has on each
>>>> blog
>>>> -- that table is still needed, but the userrole table indicating whether
>>>> one's a global admin or not.)
>>>>
>>>> Glen
>>>>
>>>> On 08/13/2014 07:54 AM, Dave wrote:
>>>>
>>>> I don't have a strong opinion, but this seems like change just for the
>>>>> sake
>>>>> of change. I doubt that impacts performance in any significant way,
>>>>> especially when compared to all the database calls that are made during
>>>>> JSP
>>>>> or page template processing.
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi team, one or both of these methods are heavily called within the
>>>>>
>>>>>> application, indeed for almost every action run:
>>>>>>
>>>>>> public List<String> requiredWeblogPermissionActions() {
>>>>>> return Collections.singletonList(WeblogPermission.xxxxx);
>>>>>> }
>>>>>>
>>>>>> public List<String> requiredGlobalPermissionActions() {
>>>>>> return Collections.singletonList(GlobalPermission.xxxxxx);
>>>>>> }
>>>>>>
>>>>>> I've checked every implementation of both methods within the
>>>>>> application
>>>>>> -- about 20-25 in all -- every one returns just a single permission
>>>>>> requirement, not a list of items.
>>>>>>
>>>>>> I think it would be good to optimize these methods by having them
>>>>>> return
>>>>>> just a string or a fast and lightweight enumeration constant. The only
>>>>>> thing lost I can see would be the ability to require multiple
>>>>>> permissions,
>>>>>> but again within the app today and through 12-14 years of Roller it
>>>>>> just
>>>>>> hasn't been needed. WDYT?
>>>>>>
>>>>>> Regards,
>>>>>> Glen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Glen Mazza <gl...@gmail.com>.
Does anyone else on the team have a view? #5 below I'm no longer sure
on so I'm withdrawing that proposal but feedback on #1-#4 below is most
welcome.
Glen
On 08/13/2014 04:27 PM, Dave wrote:
> I don't see the need for this change and I would leave those permissions in
> place. They existed to support and may still be used to support real uses
> cases like private blogging, where only registered users can see blogs and
> only those with special permissions can comment.
>
> Even if they do not work fully now, they give people a way to hook their
> own rules into their own custom versions of Roller, perhaps by adding new
> code, ServletFilters, etc. And they are a starting point for people who
> want private blogging to be fully supported in Roller.
>
> - Dave
>
>
>
>
> On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>> OK, checking Global Permission, we have these three levels:
>>
>> /** Allowed to login and edit profile */
>> public static final String LOGIN = "login";
>>
>> /** Allowed to login and do weblogging */
>> public static final String WEBLOG = "weblog";
>>
>> /** Allowed to login and do everything, including site-wide admin */
>> public static final String ADMIN = "admin";
>>
>> We don't use "weblog" though, we save it as "editor" in the userrole
>> table. We also don't use "login" for anything other than to make it the
>> minimum required setting on pages that don't require an ADMIN setting. All
>> newly registered users are given "editor" as a minimum, meaning we could
>> raise minimum from "login" to "editor" and do away with the login role
>> without any difference in application behavior.
>>
>> On top of this, we allow the roles additional subroles per the
>> roller.properties file:
>>
>> # Role name to global permission action mappings
>> role.names=editor,admin
>> role.action.editor=login,comment,weblog
>> role.action.admin=login,comment,weblog,admin
>>
>> "comment" is also never used in the application, further, in the above
>> list we're inconsistently assigning admin to admin but weblog to editor.
>> Since the permissions are all Russian doll (login < comment <
>> weblog/editor < admin), it's sufficient to just store the highest role, as
>> the lower ones are all implied, i.e., we don't need these properties.
>>
>> My proposal is to:
>>
>> 1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
>> enumeration, EDITOR and ADMIN. Later, if we have user demand for LOGIN and
>> COMMENT, and somebody actually coding in logic that uses those values, we
>> can easily add in the enumerations for them. (I don't like LOGIN much,
>> however, if we don't trust them not to blog they shouldn't be lurking
>> around the UI.)
>>
>> 2.) The "userrole" database table will be dropped, replaced with a new
>> varchar column ROLE in the Roller_User table. I'll update the migration
>> script to copy the user's highest role into that column.
>>
>> 3.) The three properties "role.name, role.action.editor, and
>> role.action.admin" will be removed.
>>
>> 4.) List<String> requiredGlobalPermissionActions() will return a single
>> enumeration constant instead (EDITOR or ADMIN), stating the minimum
>> accepted value.
>>
>> 5.) WeblogPermissions looks fine, except I'll just switch the string array
>> of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same values
>> and have requiredWeblogPermissionActions() return an enumeration constant
>> instead.
>>
>> How does this sound? I have other things to work on so I'll wait 72 hours
>> before proceeding to give time for others to evaluate this change.
>>
>> Regards,
>> Glen
>>
>>
>>
>> On 08/13/2014 08:33 AM, Glen Mazza wrote:
>>
>>> If the methods return just a single permission instead of a collection of
>>> permissions, at least for GlobalPermissionActions, that means we can move
>>> to "Russian doll" type role levels, where each permission level includes
>>> all the permission levels below it (de facto the way Roller runs now). If
>>> we can officially be on that, that means we can toss out the userrole table
>>> and just place a single column "rolename" (indicating the highest role a
>>> person has) in the roller_user table, a very sleek change. (I'm not
>>> talking about Roller_Permission, i.e., permissions a user has on each blog
>>> -- that table is still needed, but the userrole table indicating whether
>>> one's a global admin or not.)
>>>
>>> Glen
>>>
>>> On 08/13/2014 07:54 AM, Dave wrote:
>>>
>>>> I don't have a strong opinion, but this seems like change just for the
>>>> sake
>>>> of change. I doubt that impacts performance in any significant way,
>>>> especially when compared to all the database calls that are made during
>>>> JSP
>>>> or page template processing.
>>>>
>>>> - Dave
>>>>
>>>>
>>>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi team, one or both of these methods are heavily called within the
>>>>> application, indeed for almost every action run:
>>>>>
>>>>> public List<String> requiredWeblogPermissionActions() {
>>>>> return Collections.singletonList(WeblogPermission.xxxxx);
>>>>> }
>>>>>
>>>>> public List<String> requiredGlobalPermissionActions() {
>>>>> return Collections.singletonList(GlobalPermission.xxxxxx);
>>>>> }
>>>>>
>>>>> I've checked every implementation of both methods within the application
>>>>> -- about 20-25 in all -- every one returns just a single permission
>>>>> requirement, not a list of items.
>>>>>
>>>>> I think it would be good to optimize these methods by having them return
>>>>> just a string or a fast and lightweight enumeration constant. The only
>>>>> thing lost I can see would be the ability to require multiple
>>>>> permissions,
>>>>> but again within the app today and through 12-14 years of Roller it just
>>>>> hasn't been needed. WDYT?
>>>>>
>>>>> Regards,
>>>>> Glen
>>>>>
>>>>>
>>>>>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Dave <sn...@gmail.com>.
I don't see the need for this change and I would leave those permissions in
place. They existed to support and may still be used to support real uses
cases like private blogging, where only registered users can see blogs and
only those with special permissions can comment.
Even if they do not work fully now, they give people a way to hook their
own rules into their own custom versions of Roller, perhaps by adding new
code, ServletFilters, etc. And they are a starting point for people who
want private blogging to be fully supported in Roller.
- Dave
On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza <gl...@gmail.com> wrote:
> OK, checking Global Permission, we have these three levels:
>
> /** Allowed to login and edit profile */
> public static final String LOGIN = "login";
>
> /** Allowed to login and do weblogging */
> public static final String WEBLOG = "weblog";
>
> /** Allowed to login and do everything, including site-wide admin */
> public static final String ADMIN = "admin";
>
> We don't use "weblog" though, we save it as "editor" in the userrole
> table. We also don't use "login" for anything other than to make it the
> minimum required setting on pages that don't require an ADMIN setting. All
> newly registered users are given "editor" as a minimum, meaning we could
> raise minimum from "login" to "editor" and do away with the login role
> without any difference in application behavior.
>
> On top of this, we allow the roles additional subroles per the
> roller.properties file:
>
> # Role name to global permission action mappings
> role.names=editor,admin
> role.action.editor=login,comment,weblog
> role.action.admin=login,comment,weblog,admin
>
> "comment" is also never used in the application, further, in the above
> list we're inconsistently assigning admin to admin but weblog to editor.
> Since the permissions are all Russian doll (login < comment <
> weblog/editor < admin), it's sufficient to just store the highest role, as
> the lower ones are all implied, i.e., we don't need these properties.
>
> My proposal is to:
>
> 1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
> enumeration, EDITOR and ADMIN. Later, if we have user demand for LOGIN and
> COMMENT, and somebody actually coding in logic that uses those values, we
> can easily add in the enumerations for them. (I don't like LOGIN much,
> however, if we don't trust them not to blog they shouldn't be lurking
> around the UI.)
>
> 2.) The "userrole" database table will be dropped, replaced with a new
> varchar column ROLE in the Roller_User table. I'll update the migration
> script to copy the user's highest role into that column.
>
> 3.) The three properties "role.name, role.action.editor, and
> role.action.admin" will be removed.
>
> 4.) List<String> requiredGlobalPermissionActions() will return a single
> enumeration constant instead (EDITOR or ADMIN), stating the minimum
> accepted value.
>
> 5.) WeblogPermissions looks fine, except I'll just switch the string array
> of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same values
> and have requiredWeblogPermissionActions() return an enumeration constant
> instead.
>
> How does this sound? I have other things to work on so I'll wait 72 hours
> before proceeding to give time for others to evaluate this change.
>
> Regards,
> Glen
>
>
>
> On 08/13/2014 08:33 AM, Glen Mazza wrote:
>
>> If the methods return just a single permission instead of a collection of
>> permissions, at least for GlobalPermissionActions, that means we can move
>> to "Russian doll" type role levels, where each permission level includes
>> all the permission levels below it (de facto the way Roller runs now). If
>> we can officially be on that, that means we can toss out the userrole table
>> and just place a single column "rolename" (indicating the highest role a
>> person has) in the roller_user table, a very sleek change. (I'm not
>> talking about Roller_Permission, i.e., permissions a user has on each blog
>> -- that table is still needed, but the userrole table indicating whether
>> one's a global admin or not.)
>>
>> Glen
>>
>> On 08/13/2014 07:54 AM, Dave wrote:
>>
>>> I don't have a strong opinion, but this seems like change just for the
>>> sake
>>> of change. I doubt that impacts performance in any significant way,
>>> especially when compared to all the database calls that are made during
>>> JSP
>>> or page template processing.
>>>
>>> - Dave
>>>
>>>
>>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>>> wrote:
>>>
>>> Hi team, one or both of these methods are heavily called within the
>>>> application, indeed for almost every action run:
>>>>
>>>> public List<String> requiredWeblogPermissionActions() {
>>>> return Collections.singletonList(WeblogPermission.xxxxx);
>>>> }
>>>>
>>>> public List<String> requiredGlobalPermissionActions() {
>>>> return Collections.singletonList(GlobalPermission.xxxxxx);
>>>> }
>>>>
>>>> I've checked every implementation of both methods within the application
>>>> -- about 20-25 in all -- every one returns just a single permission
>>>> requirement, not a list of items.
>>>>
>>>> I think it would be good to optimize these methods by having them return
>>>> just a string or a fast and lightweight enumeration constant. The only
>>>> thing lost I can see would be the ability to require multiple
>>>> permissions,
>>>> but again within the app today and through 12-14 years of Roller it just
>>>> hasn't been needed. WDYT?
>>>>
>>>> Regards,
>>>> Glen
>>>>
>>>>
>>>>
>>
>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Glen Mazza <gl...@gmail.com>.
OK, checking Global Permission, we have these three levels:
/** Allowed to login and edit profile */
public static final String LOGIN = "login";
/** Allowed to login and do weblogging */
public static final String WEBLOG = "weblog";
/** Allowed to login and do everything, including site-wide admin */
public static final String ADMIN = "admin";
We don't use "weblog" though, we save it as "editor" in the userrole
table. We also don't use "login" for anything other than to make it the
minimum required setting on pages that don't require an ADMIN setting.
All newly registered users are given "editor" as a minimum, meaning we
could raise minimum from "login" to "editor" and do away with the login
role without any difference in application behavior.
On top of this, we allow the roles additional subroles per the
roller.properties file:
# Role name to global permission action mappings
role.names=editor,admin
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin
"comment" is also never used in the application, further, in the above
list we're inconsistently assigning admin to admin but weblog to
editor. Since the permissions are all Russian doll (login < comment <
weblog/editor < admin), it's sufficient to just store the highest role,
as the lower ones are all implied, i.e., we don't need these properties.
My proposal is to:
1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
enumeration, EDITOR and ADMIN. Later, if we have user demand for LOGIN
and COMMENT, and somebody actually coding in logic that uses those
values, we can easily add in the enumerations for them. (I don't like
LOGIN much, however, if we don't trust them not to blog they shouldn't
be lurking around the UI.)
2.) The "userrole" database table will be dropped, replaced with a new
varchar column ROLE in the Roller_User table. I'll update the migration
script to copy the user's highest role into that column.
3.) The three properties "role.name, role.action.editor, and
role.action.admin" will be removed.
4.) List<String> requiredGlobalPermissionActions() will return a single
enumeration constant instead (EDITOR or ADMIN), stating the minimum
accepted value.
5.) WeblogPermissions looks fine, except I'll just switch the string
array of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the
same values and have requiredWeblogPermissionActions() return an
enumeration constant instead.
How does this sound? I have other things to work on so I'll wait 72
hours before proceeding to give time for others to evaluate this change.
Regards,
Glen
On 08/13/2014 08:33 AM, Glen Mazza wrote:
> If the methods return just a single permission instead of a collection
> of permissions, at least for GlobalPermissionActions, that means we
> can move to "Russian doll" type role levels, where each permission
> level includes all the permission levels below it (de facto the way
> Roller runs now). If we can officially be on that, that means we can
> toss out the userrole table and just place a single column "rolename"
> (indicating the highest role a person has) in the roller_user table, a
> very sleek change. (I'm not talking about Roller_Permission, i.e.,
> permissions a user has on each blog -- that table is still needed, but
> the userrole table indicating whether one's a global admin or not.)
>
> Glen
>
> On 08/13/2014 07:54 AM, Dave wrote:
>> I don't have a strong opinion, but this seems like change just for
>> the sake
>> of change. I doubt that impacts performance in any significant way,
>> especially when compared to all the database calls that are made
>> during JSP
>> or page template processing.
>>
>> - Dave
>>
>>
>> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com>
>> wrote:
>>
>>> Hi team, one or both of these methods are heavily called within the
>>> application, indeed for almost every action run:
>>>
>>> public List<String> requiredWeblogPermissionActions() {
>>> return Collections.singletonList(WeblogPermission.xxxxx);
>>> }
>>>
>>> public List<String> requiredGlobalPermissionActions() {
>>> return Collections.singletonList(GlobalPermission.xxxxxx);
>>> }
>>>
>>> I've checked every implementation of both methods within the
>>> application
>>> -- about 20-25 in all -- every one returns just a single permission
>>> requirement, not a list of items.
>>>
>>> I think it would be good to optimize these methods by having them
>>> return
>>> just a string or a fast and lightweight enumeration constant. The only
>>> thing lost I can see would be the ability to require multiple
>>> permissions,
>>> but again within the app today and through 12-14 years of Roller it
>>> just
>>> hasn't been needed. WDYT?
>>>
>>> Regards,
>>> Glen
>>>
>>>
>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Glen Mazza <gl...@gmail.com>.
If the methods return just a single permission instead of a collection
of permissions, at least for GlobalPermissionActions, that means we can
move to "Russian doll" type role levels, where each permission level
includes all the permission levels below it (de facto the way Roller
runs now). If we can officially be on that, that means we can toss out
the userrole table and just place a single column "rolename" (indicating
the highest role a person has) in the roller_user table, a very sleek
change. (I'm not talking about Roller_Permission, i.e., permissions a
user has on each blog -- that table is still needed, but the userrole
table indicating whether one's a global admin or not.)
Glen
On 08/13/2014 07:54 AM, Dave wrote:
> I don't have a strong opinion, but this seems like change just for the sake
> of change. I doubt that impacts performance in any significant way,
> especially when compared to all the database calls that are made during JSP
> or page template processing.
>
> - Dave
>
>
> On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>> Hi team, one or both of these methods are heavily called within the
>> application, indeed for almost every action run:
>>
>> public List<String> requiredWeblogPermissionActions() {
>> return Collections.singletonList(WeblogPermission.xxxxx);
>> }
>>
>> public List<String> requiredGlobalPermissionActions() {
>> return Collections.singletonList(GlobalPermission.xxxxxx);
>> }
>>
>> I've checked every implementation of both methods within the application
>> -- about 20-25 in all -- every one returns just a single permission
>> requirement, not a list of items.
>>
>> I think it would be good to optimize these methods by having them return
>> just a string or a fast and lightweight enumeration constant. The only
>> thing lost I can see would be the ability to require multiple permissions,
>> but again within the app today and through 12-14 years of Roller it just
>> hasn't been needed. WDYT?
>>
>> Regards,
>> Glen
>>
>>
Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?
Posted by Dave <sn...@gmail.com>.
I don't have a strong opinion, but this seems like change just for the sake
of change. I doubt that impacts performance in any significant way,
especially when compared to all the database calls that are made during JSP
or page template processing.
- Dave
On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza <gl...@gmail.com> wrote:
> Hi team, one or both of these methods are heavily called within the
> application, indeed for almost every action run:
>
> public List<String> requiredWeblogPermissionActions() {
> return Collections.singletonList(WeblogPermission.xxxxx);
> }
>
> public List<String> requiredGlobalPermissionActions() {
> return Collections.singletonList(GlobalPermission.xxxxxx);
> }
>
> I've checked every implementation of both methods within the application
> -- about 20-25 in all -- every one returns just a single permission
> requirement, not a list of items.
>
> I think it would be good to optimize these methods by having them return
> just a string or a fast and lightweight enumeration constant. The only
> thing lost I can see would be the ability to require multiple permissions,
> but again within the app today and through 12-14 years of Roller it just
> hasn't been needed. WDYT?
>
> Regards,
> Glen
>
>