0.9.5 Home Stretch Part 2

MODX Staff
12,272 Posts

Ryan Thrash Reply #1, 19 years, 11 months ago

With the hopefully final beta released to the public, I’d like to focus on critical bugs, minor usability tweaks, adding in final/latest snippet versions (at least for Jot), and a detailed translation review for both the core snippets and the main language file (many tweaks to the main language file to date). Let’s get a full release out ASAP! It’d be great for someone to take ownership of the following list of things to do (which will be updated as we identify other issues).

Code related:
[*] ~~complete permissions review of the menu. David has identified an issue with the Tools menu and permissions for instance.~~
[*] address critical bugs assigned to 0.9.5 or identified in beta 5 from the bug tracker
[*] review languages for hard coded "\n" characters... lots of them and they come through the front end now due to the language strings being wrapped in single quotes. Also lots of hard coded style info like: <span style="color:#990000">
[*] language translation updates
[*] ~~increase contrast of tabs/text in MODx Light theme + login box colors~~ 1805
[*] ~~thorough review of other themes~~
[*] ~~remove what’s new from the installer, and remove the extra image in the footer and replace with a proper copyright, license line~~ 1803
[*] ~~add a toggle to select all/unselect all/toggle all for the optional snippet/plugins/chunks/modules to be installed in the installer~~ save for a future release unless someone does this quickly
[*] others?

Marketing related:
[*] prepare announcement text for MODx forums, Stylegala what’s new sidebar, Digg, Hotscripts, Sitepoint, and select Macintosh news outlets (since it works so nicely in Safari now!), etc.
[*] prepare Sourceforge mirror site content to serve as a marketing vehicle... we’ll upload snapshots to SVN there from time to time to keep the activity rating going

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

7,075 Posts

davidm Reply #2, 19 years, 11 months ago

Quote from: rthrash at Oct 24, 2006, 10:03 AM

[*] complete permissions review of the menu. David has identified an issue with the Tools menu and permissions for instance.

For reference, you can find details here

I did not file a bug report because it appeared to me that this couldn’t fit the current permission system, plus I admit I have a poor understanding of how permissions work (TobyL helped clarify this a bit -> see link above).

If you need me to do so, I’ll take a few minute to try and write a decent bug report about this. I am afraid several things might pop up in the area of permissions, and not sure this would not result in re-building at least part of the permission system (should I hunt down other inconsistencies for 0.9.5 ? or do we wait 0.9.7 to patch the permission system ?)

Quote from: rthrash

[*] language translation updates

I have updated the french language file with the new strings. I have people test it right now, released it just after the beta5 public release. Once everything is ironed out and I have all translation ready (eForm, DocManager, QuickEdit... etc), I’ll post a package.

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id

7,075 Posts

davidm Reply #3, 19 years, 11 months ago

Logged the Tools menu permission issue in FlySpray, along with a suggestion for modification :
http://modxcms.com/bugs/task/599

I’ll continue digging for inconsistencies in that area...
For instance, there is one thing that doesn’ seem consistent : for user to be able to run quickedit, I have to set the permission to execute a module. But I don’t want users being able to execute every module : for instance DocManager shouldn’t be put in all hands... I’ll write a bug report about that, one I have sorted this out.

Edit : Posted a bug report for this Module issue : http://modxcms.com/bugs/task/600

I don’t know how I modify the menu.php file to hide the top level item (e.g for Tools, I can modifiy permissions and have import and export no show anymore, but Tools does appear to the user... not good. Same for Module) : how do I do that ?

Edit : Seems that when the top item for Module does dispappear when no item are under it. So it’s the Tools top item which is faulty...

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id

1,097 Posts

PaulGregory Reply #4, 19 years, 11 months ago

On the Language front, I’ll collect together things tomorrow.

There are three issues regarding permissions and the menu:
1) presence of links in the menu
2) the ability for users to run certain features
3) 1 and 2 again, but on a per-module basis

Many of us seem happy enough to just hide features from our clients - the priority is to stop them from pressing the wrong button and screwing the site up. Whilst I’ve pointed out in FlySpray that a proper permissions solution will have to allow for certain things to be fully removed rather than just hidden, and whilst what I’m about to propose is probably too big too late for 0.9.5, it needs saying:

Editable/configurable menus.

Ideally, I’d like to see Admin users deciding what menu options are available, and the starting configuration, and then have other Manager users able to arrange them as they see fit to suit their own workflow. Crucially, Modules could be mixed in with other menus, making it truly configurable - eg DocManager under Site, a catalogue manager under Resources. Heck, someone might even have a Manager that had *none* of the traditional Manager menus, just custom forms.

Longer term, we’d need More Permission Flags and Module Permissions to be truly secure, but the direction I’d like us to go in is editable menus. I could firm up a proposal on this if there’s any interest in it.

No, I don't know what OpenGeek's saying half the time either.
MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
Forum: Where to post threads about add-ons | Forum Rules
Like MODx? donate (and/or share your resources)
Like me? See my Amazon wishlist
MODx "Most Promising CMS" - so appropriate!

1,097 Posts

PaulGregory Reply #5, 19 years, 11 months ago

Quote from: davidm at Oct 25, 2006, 05:40 AM

Edit : Seems that when the top item for Module does dispappear when no item are under it. So it’s the Tools top item which is faulty...

Actually, looking at the spiffy new menu.php, the Module menu isn’t shown if you don’t have exec permission. If there were no modules but you had exec permission, it would still show Modules.

If you look at the Users menu, you’ll see that it’s doing a IF has-any-of-the-permissions-needed-to-see-a-subitem THEN show top item etc:

<?php if($modx->hasPermission('new_user') || $modx->hasPermission('edit_user') || $modx->hasPermission('new_role') || $modx->hasPermission('edit_role') || $modx->hasPermission('access_permissions')||$modx->hasPermission('new_web_user') || $modx->hasPermission('edit_web_user') || $modx->hasPermission('web_access_permissions')) { ?>
<li id="limenu2"><a href="#menu2" onclick="new NavToggle(this); return false;"><?php echo $_lang["users"]; ?></a>

A similar line is needed on Tools, and also Reports, as these both have every menu item behind a permission check.

None of the Site menu items have a permission check on display - not even New Document.

Just so we can discuss this properly, I’m going to go through the menu.php logic and post it here in English so that it’s easier for us all to understand.

EDIT: In effect, I’m taking on the "complete permissions review of the menu" and the first step is writing out what it’s doing in a way that non-programmers like David can follow.

No, I don't know what OpenGeek's saying half the time either.
MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
Forum: Where to post threads about add-ons | Forum Rules
Like MODx? donate (and/or share your resources)
Like me? See my Amazon wishlist
MODx "Most Promising CMS" - so appropriate!

7,075 Posts

davidm Reply #6, 19 years, 11 months ago

Quote from: PaulGregory at Oct 25, 2006, 07:19 AM

Actually, looking at the spiffy new menu.php, the Module menu isn’t shown if you don’t have exec permission. If there were no modules but you had exec permission, it would still show Modules.

Yeah even I got that part, that’s why i changed

<?php if($modx->hasPermission(’exec_module’))

into

<?php if($modx->hasPermission(’new_module’))

for the time being. Not optimal by a long stretch, but it does the job.

Quote from: PaulGregory

A similar line is needed on Tools, and also Reports, as these both have every menu item behind a permission check. None of the Site menu items have a permission check on display - not even New Document.

I was just about to report in FlySpray about this... I’ll let you handle this one, I am not the most qualified to do that.

Quote from: PaulGregory

Just so we can discuss this properly, I’m going to go through the menu.php logic and post it here in English so that it’s easier for us all to understand.

EDIT: In effect, I’m taking on the "complete permissions review of the menu" and the first step is writing out what it’s doing in a way that non-programmers like David can follow.

Thanks Paul for taking the ball on this one !
Most needed improvements in the area of permissions...

Question is : should it wait till next release or do you think you can fix a few problems for 0.9.5 already ?

PS : Don’t worry, I can get most of the meaning, while I don’t write php I can read it a bit... But it sure will be nice if the code is commented

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id

MODX Staff
12,272 Posts

Ryan Thrash Reply #7, 19 years, 11 months ago

I think the menu permissions should be fixed as much as possible for the 095 release. The logic just needs to be analyzed and suggested changes discussed, and then implemented once we reach consensus of a few of the key folks who are true coders and familiar with the core. This in reality shouldn’t take long I don’t think.

While we’re at it, we might as well look at tweaking any language strings, like on the configuration page tabs, why is "setting" tacked on the end of everything... totally redundant IMO.

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

MODX Staff
12,272 Posts

Ryan Thrash Reply #8, 19 years, 11 months ago

Updated the top post to include some marketing items. Can anyone give me a hand with those?

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

1,097 Posts

PaulGregory Reply #9, 19 years, 11 months ago

Firstly, I should just point out how nice the new menu.php file is.

This is my best attempt at making this logic clear in pseudo-code, and pointing out potential errors in logic (although most of them are unlikely to ever actually happen in practice). Hopefully we can reach consensus here on the minor changes that can be made for the 0.9.5 release.

There are IFs around some entire menus, and around some menu lines, so I’m showing the IFs on the same line as the menu item, and the IFs (or EVERYONE if there isn’t an IF) at the top of each menu. I think this makes sense. Any menu item that starts a line without an IF is visible to anyone who can see that particular menu. I’ve then pointed out potential problems after each menu.

EVERYONE {
* Site
* * Home
* * Launch_site
* * Refresh_site
* * Search
* * Add_document
* * Add_weblink
}
FAULT? Is this right, can all Manager users Add documents and weblinks, or is this just included because there are other links in the manager to these features (which may lead to a "sorry you can’t do that dave" message) and so we may as well keep these visible too?

IF ’new_template’ OR ’edit_template’ OR ’new_snippet’ OR ’edit_snippet’ OR ’new_plugin’ OR ’edit_plugin’ {
* Resources
* * Resource_management
IF ’file_manager’ { * * manage_files }
IF ’manage_metatags’ { * * manage_metatags }
}
FAULT? While the menu permissions are right for Resource management, there could theoretically be someone with only the ’file_manger’ or ’manage_metatags’ permssions - he wouldn’t see the menu. I think the current IF should be copied and wrapped around the Resource_management menu item, with the other two permissions added to the main menu IF.

IF ’exec_module’ {
* Modules
IF ’new_module’ OR ’edit_module’ { * * module_management }
* * [each module]
}
MINOR FAULT? In practice this is fine, but for fully pedantic permissions this should allow for users who have ’new_module’ OR ’edit_module’ but not ’exec_module’ to manage modules.

IF ’new_user’ OR ’edit_user’ OR ’new_role’ OR ’edit_role’ OR ’access_permissions’ OR ’new_web_user’ OR ’edit_web_user’ OR ’web_access_permissions’ {
* Users
IF ’new_user’ OR ’edit_user’ { * * user_management_title }
IF ’new_web_user’ OR ’edit_web_user’ { * * web_user_management_title }
IF ’new_role’ OR ’edit_user’ { * * role_management_title }
IF ’access_permissions’ { * * manager_permissions }
IF ’web_access_permissions’ { * * web_permissions }
}
FAULT: edit_role will display menu, but not any menu items. Is the edit_user check for role_management_title a mistake?

EVERYONE {
* Tools
IF ’bk_manager’ { * * bk_manager }
IF ’settings’ { * * remove_locks }
IF ’new_document’ { * * import_site }
IF ’edit_document’ { * * export_site }
IF ’settings’ { * * edit_settings }
}
FAULT 1: As David spotted, this needs an IF bk_manager OR settings.. etc wrapped around it.
FAULT 2: The permissions used for Import and Export site are not ideal. Changing to ’settings’ as David proposes is a bit naff but the best option if we can’t just have two new permissions.

EVERYONE {
* Reports
* * Site_schedule
IF ’view_eventlog’ { * * eventlog_viewer }
IF ’logs’ { * * view_logging }
IF ’settings’ { * * view_sysinfo }
}
Yay! Everyone can see Site Schedule, therefore this menu is logically OK.

The next thing to do will be to make sure that these permissions match up with the permissions needed by the actual routines; I have not done this as yet. Another worthwhile (but time-consuming) exercise would be to actually check what each MODx permission lets you do, but that’s certainly an area for a future release to focus on tidying up.

I still maintain that editable user-specific menus is the way to go, and it looks considerably easier to do this than I previously thought. In fact, I am definitely going to replace menu.html with hacked versions on practically all our client sites (keeping Content for those familiar with 0.9.2.1 and spreading the Modules out to relevant menus). However, it is important to have a logical default menu first. If we can get some agreement on the above changes, then we’re pretty much there.

No, I don't know what OpenGeek's saying half the time either.
MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
Forum: Where to post threads about add-ons | Forum Rules
Like MODx? donate (and/or share your resources)
Like me? See my Amazon wishlist
MODx "Most Promising CMS" - so appropriate!

7,075 Posts

davidm Reply #10, 19 years, 11 months ago

Quote from: rthrash at Oct 25, 2006, 08:46 AM

Updated the top post to include some marketing items. Can anyone give me a hand with those?

That’s why I am here !

Quote from: rthrash at Oct 24, 2006, 10:03 AM

Marketing related:
[*] prepare announcement text for MODx forums, Stylegala what’s new sidebar, Digg, Hotscripts, Sitepoint, and select Macintosh news outlets (since it works so nicely in Safari now!), etc.
[*] prepare Sourceforge mirror site content to serve as a marketing vehicle... we’ll upload snapshots to SVN there from time to time to keep the activity rating going

Let me take the ball on this one

The only thing I would need is a synthetized version of the changelog, we have had so many changes I have a bit of trouble synthetizing those into a manageable list...

Also about hotscripts, who has the login/pass to edit this one :
http://www.hotscripts.com/Detailed/54181.html

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id