Previous Entry Share Next Entry
Release 0.7.2
jducoeur wrote in querki_project
This week was fairly quiet -- really, a tad inefficient -- as I wrestled with the design for the upcoming User Values feature. (The ability to have a Property which has a separate value for each User -- this is how we will be implementing things like Reviews.) Finally cracked that today, and I'm going to start implementing it next week. In the meantime, here's what we've been doing this week.

Address Heartbleed, and other security matters: none of this involved code, and indeed, most of it didn't involve me, but it's the subject that has been top of the news this week. Suffice it to say, Aaron had Querki patched before most news outlets picked up the story. (Indeed, before I heard about it myself -- I simply got a text message of "Can I bounce the server to do an update?", and didn't find out why until the next day.) I think it's unlikely we were affected, but (especially if you use your Querki password anywhere else) it wouldn't be a bad idea to change it as a precaution. You can change your password via the "Your Profile" link in the upper-right hand menu.

Along the way, we discovered that I had managed to completely screw up login (h/t to dsrtao for bringing it to my attention). There was no security breach; quite the opposite, actually. I had moved login to the front page without sanity-checking with Aaron; since the login attempt wasn't HTTPS, the server was bouncing the request. Aaron and I have now fixed that, and I believe that login should now be working as expected again. Please tell me if you find any problems, *especially* if you ever observe a login page that isn't HTTPS.

Conversation Permissions: previously, Conversations had hard-coded access control: any Member could comment on any Thing, and all Conversations were world-readable. That's clearly not acceptable even in the short run, so I've added new Permission Properties for Can Comment and Can Read Comments. These work exactly the same as the existing Permissions: they can be applied at the Thing, Model or Space levels and work as expected. The previous hard-coded values are now the defaults, but you are welcome to change them in your Space.

In order to support this, I've generalized the Permissions stack, so that any subsystem can introduce its own Permissions; this will allow very fine-grained access control, which should be useful for power users. (Coming in the hopefully-near future will be UIs that bundle up common permissions scenarios, so that you don't have to deal with the fine-grained stuff unless you want to.)

This is now structured in a way that wouldn't be terribly hard to expose to the user level, so if you come up with reasons why you want to be able to test the current user's permissions, or even define Space-specific Permissions, please speak up.

Moved the Space Link: one reason why this week was inefficient is that I spent a lot of it out and about on errands. So I spent a lot of time riding the T -- which, conveniently, now has pretty good 4G coverage, so I spent much of that time working in my own Querki Spaces. (Designing a LARP, specifically.) While doing that, I noticed a couple of bugs and annoyances in the mobile browser interface. One of them was such low-hanging fruit that I simply fixed it.

Querki is designed for mobile, and one aspect of that is that the menu bar on top folds up neatly on the small screen, showing just a single button that you click to expose the menus. Which is usually fine, but I realized that I use the link in there to go back to the Space root a *lot* -- in some Spaces, all the time. Having to double-tap to get to that turns out to be a continual irritant. Combine that with the fact that that link was taking up a lot of room in the menubar, and I decided it was time to redesign slightly.

So the link to the Space has been removed from the menubar. It is now displayed as a small breadcrumb above the title of the page instead. This opens up a bit more room for menus, and makes the link more readily available on small screens. It is fairly likely that the link to the current Thing will change the same way at some point, for the same reasons.

Thanks to laurion, who originally suggested this tweak months ago. I've had it in the back of my mind since then, and finally realized he was correct.

Whitelisted the <i> tag: I suspect that some of you are asking, why this tag specifically? The answer is that it's the de facto standard tag for injecting icons in the Bootstrap world. Since Querki is based on Twitter Bootstrap, we have the basic Glyphicon Halflings available. Moreover, we have purchased a full Glyphicons license, so we have access to the complete icon set.

These have actually been available from the beginning, and we use them extensively for Querki's buttons, but there was no way to just use them in pages. This became a hassle for me in writing the documentation. So by whitelisting the i tag, combined with what we already had, we now let you use those icons as you like.

To take a completely random example, you can display the "headphones" icon by saying <i class="icon-headphones"></i>. And you can display an image of the system's edit button by saying <span class="btn btn-mini btn-primary"><i class="icon-edit icon-white"></i></span>.

Feel free to use these -- it's a small detail, but I expect they will prove useful in fancier Spaces.

  • 1
Sorry to say, when attempting to log in at current, I'm being redirected to /dologin, and getting an 'action not found' message for GET /dologin

Odd. (Pokes around.) Ah -- I bet you've bookmarked the old login page, which I really should remove (or redirect). Just go straight to the main index page instead...

Yup, but only on my phone which is why I didn't run into the issue before. Whoops!

  • 1

Log in

No account? Create an account