make "Add a photo" etc. links on acidfree main page available to all sufficiently permissioned users

go to admin/access and configure:

acidfree mass import
create acidfree albums
create acidfree elements
edit own acidfree elements

for your users. If these are configured correctly, the links should show up.

Since as far as I can tell, this is not a bug, I am closing it. If configuring those access settings doesn't work, then there is something else awry. (the settings work for me and my users.)

I had the same problem as an user spazfox, but it was not enough to enable acidfree access control. Now I am happy, cause new version of acidfree miracously fixed that out. Big thanks!
I have another minor problem though. I am using organic groups and mass import dont offfer possibility to choose audience of images like the other acid free types do.
It would be great if it get fixed in future..

"choose audience of images"?

I don't understand what you mean here. Mass import was intended as a quick and easy way to get images into acidfree. You can use 'album contents' to do mass edits.

Choose audience and public boxes is a feature of organic groups module, which allows to restrict node to permissioned group. It looks this way.. http://student.ujep.cz/tmp/audience.png
In mass import it is not taken into account and that cause, user cant even see photos he uploaded.

Before you do anything rash like give all your users admin priviledges, I think I understand what the problem is here. But I am not sure what the correct answer is.

Normally, the links that say "add a photo", etc. are links to something of the form node/add/acidfree/photo/nnnn where nnnn is the album that contains the links. The links show up in albums that the user owns or can edit. However, there is nothing currently to prevent a user from adding photos to an album they don't own (such as the root album) or deleting their own images out of an album they don't own.

So putting links in the root album would mean that all the added items would default to the root album (unless the user selected a different album on the add page -- which not all users would). If this is something that people would like to see special cased for the root album, I might agree to that (since it is owned by user 1 by default).

Is there some way to get more than just your opinion (not that yours doesn't matter, but I would like to hear what other people say too.)

This is my duplicated thoughts on the topic.
No need to retype when you can link.

http://drupal.org/node/37906

I have put all my ideas for this into a patch. This is my first patch so please tell me if you get any errors applying it. It took me more than a few tries to create a patch that did not error when applying it.

What I did was to add a setting to the "Acidfree Display" settings. Giving the admin the choice of when to show the menu. No need to add admin privileges. I am not sure if my choice of wording is the best for the setting, but it seems to work for me.

30 sec after submitting the patch I found a working error. It should be "that are not album owners" not "that or not album owners" Still don't think its worded correctly but if you ignore the typo it should make more sense.

Thank you for making a try NaX. The idea is good, but I am not sure I like the implementation. I suppose this is as good a place as any to have a discussion about how permissions in albums should go.

This is what I think (not much of this is implemented at this time):

1. All permissions should be granted via node_access modules (by setting the view, update and delete grants)
2. The root album may possibly be special cased so that people can add an album or possibly other media to it even though it is owned by admin (and you probably don't want to give out edit rights for the root album).
3. If a person has an update grant for an element (album, photo, etc.,) he may move or copy that element to another album he has an update grant for. You may not move an element to an album that you do not have an update grant for (unless root is special cased).
4. If a person has a delete grant for an element he may delete it. If the element is an album, deleting it will delete all the subalbums and contents recursively, unless he doesn't have a delete grant for a descendent item. For descendent items that did not get deleted, they will be inherited by the closest anscestor, which may be the root album.
5. The add content links will show up in all albums that a user has an update grant for.

How does something like this sound to you?

Ok that all sound great. It will add a lot of flexibility and control. But I have a few questions.

1>
All permissions will be handled by node_access modules. What modules did you have in mind or do you for see having to create this access module? The only module that I know of that comes close to this type of node based control is the "node privacy byrole" module and maybe the "Simple Access" module.

2>
Do you see the scope for adding a admin permission ( administer acidfree elements ) to the acidfree permission. That way a user other than root can administer all acidfree content without having to have administer nodes privileges. This way a very large site can delegate control, but not to much control.

3>
These permissions, will it be role based or view, edit, delete for anybody that has the appropriate acidfree permissions. IE if edit is granted on a album then any user with create acidfree albums permission will be able to edit that album and the contents. (Some thing like that, not to sure how to put my thought into words with that one)

4>
The features you mentioned in point 4 seem to be specific to acidfree and maybe taxonomy. Would this not require the node_access module to be specific to acidfree or will acidfree control the acidfree specific features and only rely on the access module for node by node permission.

5>
You say that not much of this is implemented at this time so do see these features being implemented for drupal 4.6 or will it only come later in 4.7 and then later maybe back ported. If this is the case could my little patch be seen as a temporary measure or maybe some thing similar.

I am going to number my responses to your numbered responses just to keep everything straight.

1. What modules do I have in mind for node_access? Whatever people want. I use one that is homegrown -- originally from the node_access examples on drupaldocs.org. Whatever access module gives them the administration/security control they need.
2. Will we have 'administer acidfree nodes' as an access control? Sure. That is certainly doable.
3. Grant edit means they can actually edit the node in addition to being able to add an element. I agree that this could be too much privilege, but I am still not sure how to work it. It might be nice to have the ability to say 'people can add elements to this album but not edit the album.' I am not sure how I would implement this yet. In the mean time, I am not sure what to do.
4. The features in point 4 have nothing to do with taxonomy and would not require node_access modules to be specific to Acidfree. It simply means that if you have a tree structure that goes like this: root -> vacations -> 2004 -> aruba, and you delete the 2004 album, but you don't have delete rights on some items in aruba, those items will now be put in the vacations album because the 2004 and aruba albums have been deleted.
5. I don't mind putting these features in 4.6. As long as features don't break backwards compatibility with older versions, I am willing to put it in 4.6. But you can use your patch for now if you think that is the best way to go for you.

Ok I am sold, but that sound like a lot of work. A few more questions and then I will stop bugging you.

1. Getting back to what started this discussion. The display of the menu. I see this issue now after seeing your idea as a permissions issue and a user interface issue. What are your thoughts on still have display control over the menu.
   • E.g.1
     If an admin has a small site with just a few albums (lets say less then 5, excluding the root album) and for theming reason does not want the menu to display, but still wants his users to have the appropriate permissions to add content except albums. (And the inverse, small site that wants to display the menu)
   • E.g.2
     If an admin has a very large site with lots of users and wants to display the menu to all users that have the appropriate permissions. (and again the inverse)

   So I think for theming flexibility and user interface control their should be menu display controls, looking passed the permissions issue what do you think.

2. What was your thinking behind displaying the menu only when the user has update permissions ( node_access('update', $node))
3. Simple, do you have a time frame in mind. As far as I know you are not getting paid to develop acidfree, so asking for a time frame is not very fair of me and I don't expect you to have one but if you do what is it.
4. I might consider using my patch for the time being, I don't like having custom modules for upgrade purposes, but before I consider using my patch on a live site, I got to ask, did it work as expected for you.

The add media links could certainly be a setting, but I am not don't think they should be able to override the access controls for the album.

I am not sure exactly which access control method it will end up using to determine whether or not a user has permission to add an element to an album. It might have to start out as node_access('update')

I don't have a time frame yet. I am still trying to get Acidfree ready for 4.7, which seems to be more difficult than I think it should. I guess I must have done some things not quite right according to their API. But as far as features go, I think this would be fairly high priority as the current setup is broken.

You patch did make it so the links showed up, just like you said. It is fairly simple, so if you wanted to just use that for now, it probably would not be a hard thing to keep up to date.

Please keep taxonomy_access in mind for node access.

Acidfree does not use taxonomy. A album is actually a acidfree node. If you were to use taxonomy_access I dont know how it would work.

A clarification: Acidfree does not use taxonomy for its album hierarchy. You can use taxonomy to classify Acidfree nodes if you so desire. But using taxonomy_access should still work.

I accidently made a dupe bug for this here: http://drupal.org/node/59613

vhmauery stated: "The links probably won't show up in the root album. I am trying to figure out how to get that working. But they will show up in an album you create as a normal (non admin) user."

I don't have any links showing up on any album pages for non admin role users.

I have created all of the albums via the admin role.

If I understand correctly, if the album was created by non admin role, there will be links. My question: Is there a way to change the user that created all of these albums? In other words, can I change them to a non admin role and how?

Thanks

To answer my own question...

Log in as admin, edit each album, change "Authoring information" to a non admin user, submit.

Probably not the fastest way but it works... Now I have a lot of albums to change. :-)

Although this works for showing the links to the non admin role that created the album, it doesn't show the links to other non admin roles that should have permissions to add photos...

Is there any possibility to be able to do this? Maybe make it an option so that admins can choose to disply the links to all or not?

It seems that the roles I selected to be able to add photots, albums, etc can it's just that there is no links. I'm going to try to make a custom block in a custom region to shw the links.

Here is the code I'm using to supply the blocks in a custom region:

<?php
global $user;
if ($user->uid): ?>
<ul><li><a href="node/add/acidfree/album">Add a album</a><li><a href="node/add/acidfree/photo">Add a photo</a><li><a href="node/add/acidfree/video">Add a video</a><li><a href="node/add/acidfree/mass">Mass import</a></ul>
<?php else:
    return;
    endif;
?>

Now my questions is, does any one know how to place this on all of the album pages other than typing each url into the "listed pages" area of the block configure form?

Can I use a "Show if the following PHP code returns TRUE " ? What php code could I put there?

BTW, I'm using 4.7 cvs:

I tried using code:

<?php
global $user;
if (in_array('acidfree',$node->type)) {
  return TRUE;
}
else {
return FALSE;
}
?>

But that didn't show the links.  Does anyone know what's wrong with that?  acidfree is the content type correct?

Ok, I got it working.

In 4.7:

1)Make a custome block

2)Insert this in the block body and select php as input type

<?php
global $user;
if ($user->uid): ?>
<ul><li><a href="node/add/acidfree/album">Add a album</a><li><a href="node/add/acidfree/photo">Add a photo</a><li><a href="node/add/acidfree/video">Add a video</a><li><a href="node/add/acidfree/mass">Mass import</a></ul>
<?php else:
    return;
    endif;
?>

3)Then specify "Show if the following PHP code returns TRUE (PHP-mode, experts only)" and insert this into the field:

<?php
if (arg(0) == 'node') {
  $node = node_load(array('nid' => arg(1)));
  return $node->type == 'acidfree';
}
?>

What this will do is display the links in a custom block but only to logged in members and only on acidfree pages. You can then create a custom region if you want and also customize how the list looks by using css.

I'm satisfied with this work around. I think it would be better if we could have more control over who can do what with acidfree but in the mean time, this will work.