Is this project retired?

[mikestopcontinues]

I really like Keystone, but I don't want to commit my next site to a retired library. What's the plan going forward? Are you looking for new maintainers? Thanks!

[christroutner]

I've built dozens of sites with KeystoneJS, while using very few of the updates made in v4.0. Why does this project need to keep growing to be useful? It's the code in the project that is the most stable, that provides the most value to me, as a website and web app developer.

And also, while I'm not one of the primary devs, I feel I can safely say this project is not retired.

[mikestopcontinues]

Because they are halfway to a version upgrade with a lot of cool new features and breaking changes. There are a lot of open issues and pull requests, and no meaningful updates in a while. I wouldn't be very responsible to my future self if I invested in a project without leadership when I could choose another or roll my own. I'm not looking to do either, but if I have to, I have to...

[Takumiiino]

@christroutner

So, how do you implement "User role" or "Permission" in AdminUI for your dozens of sites? E.g. only admin can edit specific model, default filter for non-admin user to protect or hide others item. I googled about a month and i still stuck about permission problem. Do you have any hints?

Already checked those issue or pull request:

#803
keystonejs/keystone-test-project#21
keystonejs/keystone#334

etc...
none of them save me.

[christroutner]

@Takumiiino I rolled my own admin system in ConnextCMS. I have three levels: 'superusers', 'admins', and 'users'. Four if you count non-users. You can read about in in the ConnextCMS Documentation:

http://connextcms.com/documentation/configuration.html#superusers

If you look at the API handlers under the /routes/api directory of the ConnextCMS repo, you can see where I do the checks. All the models in ConnextCMS are manipulated through API calls, so permission are checked there.

[Takumiiino]

@christroutner

Thanks for your reply. I have already read some info of ConnextCMS.
However, "multiple CMS" in my opinion is not a good solution to deal with Permission/User Role. Adding frameworks or extensions sometimes are worth because of saving time, code less etc... but if the frameworks are too large or complicated, they are not worth spend much time to implement within a project which already in a complicated framework, like keystone.

All we need is a permission system which base on keystone model, keep it clear and simple like hidden: true, defaultSort: 'name'.

Maybe something like:

var aList = new keystone.List('aList', {
	track: true,
	defaultFilter: {'createdBy': _req_user}
});

Or
what @JedWatson mentioned in keystonejs/keystone-test-project#21

Please, if any Contributor still here, please complete those issues.

[christroutner]

@Takumiiino why can't you be the contributor? Create a change, submit a pull request. That's how changes get made to open source projects.

[mikestopcontinues]

@christroutner There's only been a trickle of accepted PRs in the last six months, and plenty to choose from. Most have been ignored. Most accepted have been trivial. That doesn't inspire participation.

[JedWatson]

Sorry for the lack of communication. Despite the recent trickle of public contributions, we're absolutely committed to the project and it's not going away.

(There are, unsurprisingly, reasons for the lack of progress in the last six months but I'm going to save that for a post I'm writing on medium at the moment rather than making this a really long reply)

We are still progressing towards a final release of 4.0 and have been putting together a roadmap I'll link separately so everyone can follow along. We've also learned a lot in the process and have been working on prototypes for the future that we wanted to flesh out more completely before sharing (I really don't like promising things for the future, prefer showing things that are real) but obviously the lack of commuication hasn't been a great alternative.

After 4.0 we have some big plans for Keystone that are already in progress and am really excited to start sharing information (including some new contributors who will be coming on board to help manage and drive the project) but we need flesh it out a bit more first.

One of the highest priorities for the project has always been backwards compatibility and/or a smooth upgrade path between versions - sometimes, honestly, to our detriment because this has frequently taken dev effort that probably could have been better invested moving forward - but it's still a massive commitment. Given that almost everything was rewritten between v3 and v4, and there were really only minor backwards incompatible changes (e.g. the new File field) I think our history backs that up and is part of why people are confident building on Keystone.

It's probably also worth mentioning we would love to revitalise the community and invite more contributors once we can be organised about how to best manage it and not waste anybody's time.

So in short, no, Keystone isn't dead or abandoned, we’ve just been really busy. We still use Keystone extensively ourselves and have no plans to let it languish.

[Kalcode]

Appreciate your follow-up. I've enjoyed working with this CMS and feel its only lacking a few things here and there that would really help it stand out. Really glad it not being forgotten about.

[mikestopcontinues]

Thanks, Jed! That's above and beyond what I was hoping. I'll be watching closely for any way I can pitch in. Also, I consider this thread closed, but I'll leave it open just in case you'd like to get a few more eyeballs on your response. Thanks again!

[VinayaSathyanarayana]

@JedWatson - Appreciate it. We all love Keystone.

[areknow]

@JedWatson Thats great news, thanks for the update! We are all looking forward to the release and the future of Keystone.

[teamhail]

@JedWatson, awesome to hear from you. Hope all is well with everyone. Terrific project and thanks very much for everyone's effort.

[w0rldart]

@JedWatson thanks for the update. I was wondering how are you planning to tackle the currently open 116 pull requests and 296 issues now, and for future term? Will the new contributors take care of that, or is something that you are looking to keep internal?