Digital Asset Management anyone?

This would a big job, and certainly would be an add-on, not part of the core, but I wonder if anyone out there might be interested in working on a DAM module? To be honest I haven't even thought through the benefits of basing a DAM system on Etomite/Modx, but based on where it seems to be heading, at least my right brain says it's a good idea. Any thoughts?

I think it is a great idea, but I don't think the API is there yet.

Things I think the core still desperately needs to do this properly:

1. A unified and extensible permissioning system.
2. Content versioning/rollback
3. A proper way to interface third party content into the TV system

Of course, those are just observations from the top of my head and without really thinking things through (at all)...

Things I think the core still desperately needs to do this properly:

1. A unified and extensible permissioning system.
2. Content versioning/rollback
3. A proper way to interface third party content into the TV system

I agree here too.

1.)
The permission system isn't bad from what I've seen so far but I wonder if the same system that MAMBO uses (apGL -- or whatever it is called) wouldn't be a bad idea.

2.)
Interesting. Would love to see more in regards to this idea.

3.)
AHHH ... the holy grail of APIs.
This is a definite vote "yes" from me.

Actually, this is where I have been imagining that MODx will be heading.


Lot's of cool ideas here

The permission system isn't bad from what I've seen so far but I wonder if the same system that MAMBO uses (apGL -- or whatever it is called) wouldn't be a bad idea.

The actual system isn't that bad, but the implementation is somewhat flawed, IMO. For instance: there is no way for a snippet to easily check permissions or even add new permissions of their own. For instance, a media snippet that allows selected people to upload new content. How would it check?

Something I did several months ago was to abstract the permissions to the point where even the WYSIWYG editor could control who could select font colors, tables, image uploads, bold/italics, etc based on security profiles.

This would a big job, and certainly would be an add-on, not part of the core, but I wonder if anyone out there might be interested in working on a DAM module? To be honest I haven't even thought through the benefits of basing a DAM system on Etomite/Modx, but based on where it seems to be heading, at least my right brain say it's a good idea. Any thoughts?

I've been thinking about this myself, mainly focused on how better to manage images, pdfs, etc. Right now we have the MODx file manager and the HTMLarea image picker. Unless I'm doing something wrong, the HTMLarea image picker can't see folders and images created in the file manager. There needs to be a unified method to manage all assets. If we're switching to FCKeditor, it is worth taking a look at their image manager. There should ideally be a "media catalogue" for managing everything. I'm not sure how it is handled now but we should be storing meta data in the DB on who uploaded what and when, etc. I'm actually used to commercial CMSs that store all but the largest media in the DB along with associated data and then publish these assets out. Since we're dealing with a "baked" or static system that's not practical but the lessons learned are.

The actual system isn't that bad, but the implementation is somewhat flawed, IMO. For instance: there is no way for a snippet to easily check permissions or even add new permissions of their own. For instance, a media snippet that allows selected people to upload new content. How would it check?

Remember those isMemberOf API functions I mentioned sometime ago? Just want to let you know they are on their way

Something I did several months ago was to abstract the permissions to the point where even the WYSIWYG editor could control who could select font colors, tables, image uploads, bold/italics, etc based on security profiles.

Wow! I'm thinking do we need to go that far?

What if we were to add a few more roles the user system? Maybe something like image uploads?

Something I did several months ago was to abstract the permissions to the point where even the WYSIWYG editor could control who could select font colors, tables, image uploads, bold/italics, etc based on security profiles.

Wow! I'm thinking do we need to go that far?

What if we were to add a few more roles the user system? Maybe something like image uploads?

I don't know-- I have mixed feelings on that. 3 of my last 4 projects required that level of access, though, so even if we don't, I do think we should have some nice API functions to make these easier to do. At the moment it is a huge headache and are all hardcoded.

It would be so nice if one could merely do something like
$modx->addPermission("content", "Image upload", 0);
to add a new "Image upload" permission to the "Content Management" group with a default of 0 (no).

Then you could check it in the code:
if ($modx->hasPermission("content", "Image upload")) { ... };

Using a system similiar to this, a snippet could register a new permission right during install, along with a default state, and it would autoregister in all roles.

Something else to consider is that by putting these in as API calls, we move a step closer to being able to overload them to, for instance, use a pre-existing authentication system to check for permissions.

Does this make sense to anyone other than me?

I'm all for a more fine-grained and flexible permission system... it makes a TON of sense to me.

Would you be willing to do the work to implement what you're talking about?

I'm all for a more fine-grained and flexible permission system... it makes a TON of sense to me.

Would you be willing to do the work to implement what you're talking about?

Sure thing.

I'll put together some specs before I start so everyone can give feedback before I do it.

Guess that means I should actually get a CVS account so I can work on the pristine sources, too. I'll send you my public key.

Guess that means I should actually get a CVS account so I can work on the pristine sources, too. I'll send you my public key.

Reading my mind.

Send my your requested login name, too. Thanks!

As a general reminder for anyone, SSH public keys should be DSA SSH2 keys at least 1024-bits long. Use PuttyGen (?) for windows, OpenSSH for *nix, and SSH Agent on OS X to generate your key, and just send the .pub part.