Rename limited permission to drafter, Members menu item to Co-Bloggers?
Team, we have three permission rights when we invite someone to join a blog: admin (becomes a co-owner of blog, can do anything including delete the blog), author (can publish blog entries and moderate comments, but not alter the blog's design), and limited (can save as draft blog articles but can't publish them -- someone else has to review the draft and then publish.) I'm wondering if we should rename limited to drafter. Although drafter as a person who writes drafts is not a common usage of this term, the access rights that drafter provides is clearer than limited and doesn't have as much a negative connotation to an employee assigned this role that limited has. This is just a GUI change, the internal codes saved to the database in roller_permissions (admin, post, edit_draft) will remain the same. Also, the menu item Members on our Preferences Tab (which contains Settings | Members | Pings | Maintenance), which contains the list of people authorized to work on the blog along with their roles, I'm inclined to rename to a more active-sounding Co-Bloggers--or is that too informal? WDYT? Thanks, Glen
Re: Rename limited permission to drafter, Members menu item to Co-Bloggers?
-1 original names for these much more clear, no need to change. - Dave On Tue, Jul 29, 2014 at 6:52 AM, Glen Mazza glen.ma...@gmail.com wrote: Team, we have three permission rights when we invite someone to join a blog: admin (becomes a co-owner of blog, can do anything including delete the blog), author (can publish blog entries and moderate comments, but not alter the blog's design), and limited (can save as draft blog articles but can't publish them -- someone else has to review the draft and then publish.) I'm wondering if we should rename limited to drafter. Although drafter as a person who writes drafts is not a common usage of this term, the access rights that drafter provides is clearer than limited and doesn't have as much a negative connotation to an employee assigned this role that limited has. This is just a GUI change, the internal codes saved to the database in roller_permissions (admin, post, edit_draft) will remain the same. Also, the menu item Members on our Preferences Tab (which contains Settings | Members | Pings | Maintenance), which contains the list of people authorized to work on the blog along with their roles, I'm inclined to rename to a more active-sounding Co-Bloggers--or is that too informal? WDYT? Thanks, Glen
Re: Rename limited permission to drafter, Members menu item to Co-Bloggers?
OK, I'll keep them as-is. Glen On 07/29/2014 07:14 AM, Dave wrote: -1 original names for these much more clear, no need to change. - Dave On Tue, Jul 29, 2014 at 6:52 AM, Glen Mazza glen.ma...@gmail.com wrote: Team, we have three permission rights when we invite someone to join a blog: admin (becomes a co-owner of blog, can do anything including delete the blog), author (can publish blog entries and moderate comments, but not alter the blog's design), and limited (can save as draft blog articles but can't publish them -- someone else has to review the draft and then publish.) I'm wondering if we should rename limited to drafter. Although drafter as a person who writes drafts is not a common usage of this term, the access rights that drafter provides is clearer than limited and doesn't have as much a negative connotation to an employee assigned this role that limited has. This is just a GUI change, the internal codes saved to the database in roller_permissions (admin, post, edit_draft) will remain the same. Also, the menu item Members on our Preferences Tab (which contains Settings | Members | Pings | Maintenance), which contains the list of people authorized to work on the blog along with their roles, I'm inclined to rename to a more active-sounding Co-Bloggers--or is that too informal? WDYT? Thanks, Glen
Re: YUI3 - JQuery UI switch
Very nice work! - Dave On Mon, Jul 28, 2014 at 11:04 AM, Glen Mazza glen.ma...@gmail.com wrote: Hi team, with the exception of some CSS files not offered by JQuery, Apache Roller is now a full JQueryUI shop, YUI3 is gone. Leaving out image files, we replaced 60-70 YUI3 files each in separate folders with just two JQuery UI files (one JS, one CSS), and I hope our Sonar scores will jump back up again as a result. Our JQuery UI stuff is now kept in a single folder (roller-ui/jquery-ui-1.11.0), so it can be deleted and replaced as a unit whenever we upgrade the library for newer versions, different themes, or more widgets than the three or four that Roller presently uses. I chose a blue-ish theme (Redmond) similar to what we had with YUI3 but don't really care about which theme we use, so long as we're on JQuery UI I'm happy. I created a README in webapp/roller-UI: http://svn.apache.org/viewvc/ roller/trunk/app/src/main/webapp/roller-ui/JQueryUI-README.txt?view=markup explaining the JQueryUI update process, including how I created the download via the JQuery Download builder (http://jqueryui.com/download/) -- to keep CSS and JS size manageable I just included the widgets we use. Comments welcome. Cheers, Glen
Permissions inconsistencies for an author w.r.t. Bookmarks and Categories
Hi Team, we're inconsistent right now in what we allow folks with author permission to do -- currently: Categories -- menu item is *visible* -- they can't add categories (throws a permission error) -- they can edit (rename) them -- they can delete them Bookmarks -- menu item is *invisible* -- they can still add bookmarks if they know the URL -- they can't edit them -- they can't delete them I'd like to make these consistent for each group above -- allow all or disallow all. For Bookmark, shut off the ability for them to add a bookmark, as I guess it was never intended for them to be able to, as they don't have a bookmark menu option anyway. For categories? Because the author is not allowed to alter other presentation matters such as the theme or (apparently) bookmarks, I'm leaning that the task of configuring categories should remain with the Admin, let the author suggest to the Admin the categories that the blog should have. I.e., take out the Categories tab for authors as well as their ability to edit/rename them. Or, are we going to allow authors to modify categories? In this case I'll need to open up Category Add for them to make it consistent. Regards, Glen
Re: Upgrading fauxcoly theme to Foundation CSS
Hello Glen, Yes, I still remember that issue that is why I though of adding to this theme. Also, It good to add to velocity/weblog.vm so all themes can use it. Thanks for appreciation :) Ok. I will place the widgets to the right side and will see that in mobile it comes to the left. For now we can leave rate this template, I just places to occupy the space. So, the YUI3 is gone. Isn't that we were thinking of upgrading from YUI2 to YUI3 or I missed out of some discussion ? Yes, once theme is ready we can get rid of YUI3 folder definitely. Regards, Gaurav On Monday 28 July 2014 08:29 PM, Glen Mazza wrote: Hi Gaurav, can you see to it that the updated Fauxcoly theme does *not* use YUI3's CSS grids -- it's the only thing in Roller using it today and we can get rid of its folder http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/roller-ui/yui3/ once it's gone from the theme. Thanks, Glen On 07/28/2014 09:39 AM, Gaurav Saini wrote: Hello Matt, Yes, definately I will add some widgets to the right. For now I have just made it in html so some rough mockup. There is a tree in the bottom (blog archive widget). I am planning to include that in the theme. What you think about it, wordpress and blogger already have this type of tree. If you have some more ideas, Please let me know. I want to make it look great :) Thanks Gaurav On Monday 28 July 2014 06:57 PM, Matt Raible wrote: I think it looks OK, but maybe there should be something more under the search on the right. Perhaps a tag cloud or most recent posts listing? On Mon, Jul 28, 2014 at 7:23 AM, Gaurav Saini gauravsain...@gmail.com wrote: Hello Team, As discussed before, about upgrading the fauxoly theme to Foundation CSS framwork. I have prepared initial rough mockup of the theme. I tried to have it similar to old theme with a large background image on the top. Please get in with some reviews about it. So, I can go forward with it. (Its responsive in nature and adapts well on mobile and tablets also.) http://awesomescreenshot.com/0ee37zej4b Note: Original Foundation components (buttons, icons, and other css components might look a bit different). -- Regards, Gaurav Saini Developer and Internet Marketing -- Regards, Gaurav Saini Developer and Internet Marketing
Re: Upgrading fauxcoly theme to Foundation CSS
Yes, I did upgrade from YUI2 to YUI3, but found that YUI3 is just very inconvenient/clumsy to keep in a web application (one file per folder, 70-80 files, 70-80 folders, no SSL CDN.) Plus I need to learn JQuery... :) Glen On 07/29/2014 01:23 PM, Gaurav Saini wrote: Hello Glen, Yes, I still remember that issue that is why I though of adding to this theme. Also, It good to add to velocity/weblog.vm so all themes can use it. Thanks for appreciation :) Ok. I will place the widgets to the right side and will see that in mobile it comes to the left. For now we can leave rate this template, I just places to occupy the space. So, the YUI3 is gone. Isn't that we were thinking of upgrading from YUI2 to YUI3 or I missed out of some discussion ? Yes, once theme is ready we can get rid of YUI3 folder definitely. Regards, Gaurav On Monday 28 July 2014 08:29 PM, Glen Mazza wrote: Hi Gaurav, can you see to it that the updated Fauxcoly theme does *not* use YUI3's CSS grids -- it's the only thing in Roller using it today and we can get rid of its folder http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/roller-ui/yui3/ once it's gone from the theme. Thanks, Glen On 07/28/2014 09:39 AM, Gaurav Saini wrote: Hello Matt, Yes, definately I will add some widgets to the right. For now I have just made it in html so some rough mockup. There is a tree in the bottom (blog archive widget). I am planning to include that in the theme. What you think about it, wordpress and blogger already have this type of tree. If you have some more ideas, Please let me know. I want to make it look great :) Thanks Gaurav On Monday 28 July 2014 06:57 PM, Matt Raible wrote: I think it looks OK, but maybe there should be something more under the search on the right. Perhaps a tag cloud or most recent posts listing? On Mon, Jul 28, 2014 at 7:23 AM, Gaurav Saini gauravsain...@gmail.com wrote: Hello Team, As discussed before, about upgrading the fauxoly theme to Foundation CSS framwork. I have prepared initial rough mockup of the theme. I tried to have it similar to old theme with a large background image on the top. Please get in with some reviews about it. So, I can go forward with it. (Its responsive in nature and adapts well on mobile and tablets also.) http://awesomescreenshot.com/0ee37zej4b Note: Original Foundation components (buttons, icons, and other css components might look a bit different). -- Regards, Gaurav Saini Developer and Internet Marketing
upgrading to HTML5...
We're fine to upgrade to HTML5 now, correct? I checked 5 sites (Bootstrap, JQuery, Foundation, CNN our JIRA) and they are all on that standard. It appears just a header switch in our tiles-*.jsp is all that's needed, as the closing tag stuff that's used in XHTML is still supported although not encouraged. Glen
Re: upgrading to HTML5...
Yes, especially since it's only affects the admin UI. My site has been HTML5 for years. On Tue, Jul 29, 2014 at 1:03 PM, Glen Mazza glen.ma...@gmail.com wrote: We're fine to upgrade to HTML5 now, correct? I checked 5 sites (Bootstrap, JQuery, Foundation, CNN our JIRA) and they are all on that standard. It appears just a header switch in our tiles-*.jsp is all that's needed, as the closing tag stuff that's used in XHTML is still supported although not encouraged. Glen
Consolidate the security properties in roller.properties?
Hi Team, it may be a good time for us to consolidate our security settings in roller.properties from our current three properties to just one. It would be best to get such a change into Roller 5.1 because for backward compatibility reasons we're not going to be able to put it into a subsequent minor patch release. Presently we have three different security flags: authentication.cma.enabled = true/false (i.e., tomcat-users.xml file) users.sso.enabled = true/false (i.e., LDAP) authentication.openid = disabled/hybrid/only (Roller DB only, either Roller DB or OpenID, OpenID only) The problem with coding three properties where one will do is that security holes start to develop as we code with just one or two of the properties where we actually need all three. Also, users may inadvertently set unsupported combinations of the three and as a result not get the security they're expecting. Finally, it's not obvious as it could be from the above settings the type of security offered by each setting. I propose we switch to one flag in 5.1 called authentication.method and it will have only one of five possible values: db (use roller database, this will be the default value defined in roller.properties) ldap (equivalent to old users.sso.enabled=true) db-openid (hybrid above, users can use DB or OpenID but not both) openid (only above, openID alone supported) cma (= authentication.cma.enabled=true). If db seems too terse/vague, we can use rollerdb instead to clarify the DB it's using. If we have additional auth methods in the future, we'll add other constants, using hyphens such as db-openid above instead of additional properties if we're allowing multiple auth methods simultaneously. [Incidentally, I'm not sure if authentication.cma.enabled (i.e., tomcat-users.xml file) even works in Roller today--the web.xml probably won't support it--but we have some coding for it within the application. We may wish to pull this option out.] Another advantage of this switch is that by leaving the ambiguous users.sso.enabled (sso can mean multiple things--OpenID, LDAP, CMA) and replacing it with an explicit ldap flag, we can possibly start moving towards LDAP security without the users needing to modify their security.xml, they would just need to configure their roller-custom.properties instead. WDYT? Regards, Glen
