Have seen some other posts, but am confused about something that should be much simpler than I'm understanding. I've tried searching, but the results are vague, or not relevant to "own", etc..

I have a custom User Group that I wish to allow Adding/Editing/Deleting of records. They should ONLY see records that they have created, and never see records created by other users. Relying on Admins to publish/unpublish is not an option, and public viewing is not a big concern because the saved records are actually being used elsewhere (not in a standard list for public viewing).

I've tried following the steps described at www.j-cook.pro/forum/14-news-a-chillout/2149-userguide#2168 , but my User Group can still see Items from other users.

Once installed, I use my Component Parameters from the back-end to set the following: These settings seem correct to me, so I presume there's something in Cook that I am not setting up correctly.

Configure	Denied
Access Administration Interface	Denied
Create	Allowed
Delete	Denied
Edit	Denied
Edit State	Allowed
View own	Allowed
Edit own	Allowed
Delete own	Allowed

Again, while editing from the Front-End, my users should NEVER see records added by other users.

Thank you in advance for your assistance.

P.S. I should mention that the user cannot edit the records for other users (CHAPTERLISTS_ACL_UNAUTORIZED_TASK), but I don't want them on the list to beging with.

Hi @gdpodesta and welcome to cook!

OK, one thing to understand relating to your aim of users only being able to see their own records is that you will require a publishing wizard too.

What the publishing wizard does and how it will help

1. By setting an item to published = 1 or published = true means it is viewable by anyone with view access to your component - i.e. everyone
2. By setting published = 0 or published = false, that item will not be publicly viewable on the site. This is what you want, right?

Therefore, the first thing you need to do is to add a publishing wizard. The steps are described perfectly by @VeCrea in the post here...

**** ADD ****
As he says in his post, you need to pre-fill the published value with 0 to ensure that the records aren't published.
***************

Your config is correct and I believe that with the addition of the publishing field, you should have the behaviour you desire.

Hope it helps,

Gez

Sounds like this is what I want, but if I want the owner of the record to "actually publish" the record, making it "active" for the site, will this then then make that record visible for editing to others that did not create it?

No, because your config states that editing is not possible to that group. They can only edit own but, providing they have viewing rights, users will be able to see others' published records.

Hope it helps,

Gez

I see, then, given that I only want anyone to see their own records for edting, I'll have to stick to keeping them unpublished, is that right?

The application involves Professors that will be creating Video Playlists. Only they can create/edit the lists, and the site is shared across various Institutions, so they cannot be allowed to see Playlist records created by other users. Ultimately, the Professor will be creating "Access codes" that will be used to allow the student to view a subset of the Playlist records that he/she has created.

Is it possible to use the Publish Wizard twice in a table - Once for the purposes described above, and a second instance named "Active" for the Professor to have some limited publishing control?

gdpodesta wrote:
In essence, NO. You cannot instantiate 2 publishing wizards as such however, you could have another field that performs that function... But, that may not be the only way to go about it!

Give me 15 mins to get a breath of fresh air and a coffee and I'll answer this more completely...

BRB,

Gez

Ah, a man after my own heart, lol. Well, while you enjoy that coffee, here's the scenario I'm trying to accomplish, and attempting to understand the best was to use COOK to get there:

1. Users in Group "Professor" create/edit Playlists in my Cook Component
2. Professors are all from different schools, so cannot view each other's records
3. Professors should be able to "activate" their lists when they are complete and ready for the students
4. Another component/view will allow Professors to create "Access Codes" that are essentially pointers to which Playlists he wants to use.
5. Access Codes will be given to students who arrive at the site and simply enter them (without registration), and will be shown a list of whatever Playlists are associated with the Access code

Do you think Cook can handle all of this, or will there be customization of the generated code?

OK, had a brief wiff of 'fresh' air and coffee in hand. Here we go...

Before I get into your last post (I was gonna ask more about those too), here are a couple of considerations:There are a couple of considerations here:

1. I presume that the records that you're talking about here are playlist items, not playlist themselves right?
2. Presumably, you will have 2 groups, Professors & Students?

If the answer to both of these questions is yes then, one way to go would maybe be to force public (i.e. students) to view only items that are published and belong to published playlists. The only way to do this would be to write some custom code in your cook-built component - no problem! There are loads of posts here and great support from users and admin to help you along the way.

So your table and fields setup would be something like:

• playlist- id, title, description, published etc...
• tracks - id, title, description, published & playlist_id (foreign key linking to playlist.id) etc...

So, you'd basically point your student users to a playlists page that would display all published playlists that would list tracks that were associated with the playlist by the tracks.playlist_id field without giving them access to the tracks (item view), right?

Alternatively, you could have for example, a media table that your professors publish all of the tracks and details in - as above however, without the playlist_id field. Then, create a join table, tracks, that stores 2 keys, the playlist_id and track_id - maybe an added published field too. Tracks could be added here by creating a custom function to multi-select tracks into a new/existing playlist (table).

Then, on the front-end, you drive your students to a view of your playlists that grab the items from your join table tracks as opposed to media. This way, you avoid having any confusion around having 2 publishing type fields (1 wizard and another that makes it available to front-end students.

Personally, I would do it this way... It makes for a more normalised dataset in addition to allowing Professors to easily add a media item to multiple playlists, un-publish or remove a media item (track) from 1 or more playlists completely independently.

What do you think?

I'm sort of in the middle of something very similar myself - a project management component for songwriting/recording projects that I deliver in multiple schools although, the media part of it is a small part of the overall application. Have you decided on which player you'll use? I'd recommend JW Player for it's open JS api and ability to track plays amongst other things. This will be useful for allowing tracks to be played a limited number of times and loads of other cool stuff!

Anyway, I hope this helps a bit. Any probs, gimme a shout!

Gez

gdpodesta wrote:
Hope it helps,

Gez

This is all very helpful. You've got the general idea.... As far as the media itself is concerned, we've got all that in another database, indexed, managed, etc., and the Cook editing layout will be interfacing with that to allow them to choose which pieces of which videos they want, then to order those "chapters" however they'd like, with a narrative, and bundle everything up and "save it somewhere". Ultimately, it will be a list of video IDs with start/stop times to be used in a true playlist that is generated on the fly based on what the professor wants.

You've got my ACL correct. Professors are a user group, and students are just public visitors. The access code mentioned will drive what they will ever be allowed to see.

I think the clearest path for me is to use the native Cook Publishing approach, but just don't allow anyone anywhere to actually publish the items in the true sense of the function. The playlists will never be used in a list anywhere in a traditional sense like, say the Joomla content table, where a user could search for them.

So, my next lessons will be to learn how to JOIN a COOK created table to an existing table in our system (like it does with #__users, though I have no idea so far how to use the data from the joined table).

That's not too tricky:

1. Replicate your table(s) with dummy table(s) in COOK
2. Relate all of your data inside cook as if it were your own
3. Once built, remove all of your models, views and controllers for your dummy tables
4. Search and replace the references to your dummy table(s) throughout the rest of your code with the actual table names

What you using, Music Collection or something outside of Joomla?

Gez

It's our own media system which we use with most of the major educational media providers in the country (we house/stream educational videos to 80% of the US). We build the interface to let schools buy the licenses to view it, then components like this manage who gets to see what.

You've been an awesome resource. I'm not new to Joomla, but this is my first new project in v2.5, and my very first stab with Cook (with which I'm most impressed), so am trying to figure what, and how much of the project can be done here, then where/how to most effectively implement the custom code (which there will be plenty of, lol).

That's pretty cool!

Well, for the most part, COOK can build probably 85-90% of the admin side with the remaining 10-15% of stuff needing custom coding - mostly the really deep stuff that I'm sure you can imagine is pretty damn hard to account for with so many variables/uses by developers.

As for the front end, there's probably another 20% of custom work to do (so about 60% can be achieved with Cook alone) to get everything looking as you want it with neat UI stuff like jquery and ajax etc. But some really cool features have been integrated to allow front-end editing which I'm sure will be useful to you... The good news is that a lot of devs here are making promising noises about it's compatibility with J3.0!

Anyway, best of luck with it!

Gez

Knew full well that there'd be a ton of custom coding, so with this being a my first new J2.5 project, I'm essentially trying to get as much mileage out of Cook to get all the core Joomla files created "the right way" and in the "right places". From there, I can figure out the rest, so figured a few days of learning Cook greatly outweighed the experimentation in Joomla. .

indeed!

Cook has also improved some native stuff too - like redirections for instance. Good luck with it!

Gez