Improve UX (features depending on ACL)

Sorry to rush back. Is there any chances to have this Feature?

I am quite busy with paid work, I see no important use cases for this feature, and nobody else has (so far) requested this feature.

There is two ways to speed up development of a requested feature:

1. If you're a developer, develop the feature yourself, post a patch, and get it RTBC.
2. If you're not a developer, sponsor its development (i.e. pay the maintainer to develop the feature).

Abarpetia, if I understand your request correct then I need this too. If you're working on this I'm available for additional testing.

Maybe this issue is duplicate of: https://www.drupal.org/node/2233121

@System Lord and @abarpetia,

I've now updated the project with more extensive permissions.

The latest dev snapshot of the project should let you set Flexi Access for own content, and you have individual CRUD permissions.

For details about these permissions, please see README.txt.

Please test, and report back here.

Changing status.

Thanks, gisle! Testing now. One thing I see right off is if I want to provide "View" only grants "Manage view permission" to my node authors "Update" and "Delete" options are still available to the authors under the Flexi Access tab. I don't think your commit addresses this particular issue (View only permission). As for authors being able to manage their own node access this fix is perfect.

I see that I commented that this may be a duplicate of 2233121 (above). I see now what abarpetia was requesting and its not a duplicate.

Mark

I want to set "Automatic ACL creation" so that the node is restricted by all users. But, this seems to include the node author as well. As a user/author when I create a node I lose access right after saving. The node author should have/maintain view/edit/delete.

@System Lord,
I pushed a new snapshot that should fix the problem you mention in comment #9, to the repo.

I am unable to reproduce the problem you mention in #8. Please check the permissions and make sure that the role in question (e.g. authenticated user) is not granted the permission "Administer all nodes". This permission should only be given admins. You want ordinary users to have the permission "Administer own nodes".

If you still think this is a problem then I need more information? I need to know:

1. All Flexi Access permissions granted the role.
2. Exactly what steps to take to reproduce the problem.
3. The exact result you get, and what result you expected to get.

If you're able to take a screen shot of what you see under the Flexi Access tab and attach them to your comment, that would be helpful as well.

Nice! Couple things. 1. It looks like the node author is automatically added to the "Current users" list. Doesn't seem like a big deal except users could accidentally remove themselves and then lose access to their own node. 2. I know it says it in the fieldset description, but i was still caught not doing it right. I added a user and spent a few minutes trying to figure out why access wasn't being granted to the user. Then I remembered to click "Commit updates." This is a little confusing because when I click "Add user" it adds the user immediately making it appear as though that's all I had to do. Additionally I can leave the page, NOT committing update, and not be aware that my users that I just added are lost. Possible solution: I notice, at least in my environment, that when I click on "Commit updates" it leaves me on the same page. I wonder then if the "Add user" function could be considered redundant? Perhaps change "Commit updates" label to "Add user." That is...commit as I go (add). Or make "Add user" commit at the same time. Although, I'm only looking at this from my use case. If other sites want to include view, update, delete for their node authors then "Commit updates" for all three at once makes sense.

Otherwise for 2 need something like a auto dialog that pops up "Did you want to save your changes" ?

Actually your new snapshot fixed #8 for me. I just don't think I was clear. thanks again! I've played with a number of other node access modules and configurations and Flexi access [now] is really the most flexible!

It looks like the node author is automatically added to the "Current users" list. Doesn't seem like a big deal except users could accidentally remove themselves and then lose access to their own node.

Yes, the owner of the node is automatically added to the "View permission" list, but he/she can be removed from it by self or by an admin. This is by design, and is mentioned in README.txt. There are use cases for owners not seeing the nodes they own. For instance, a supervisor may create a personalized task and assign ownership of the task to an operative, but view and edit access to the node is not granted until later.

I know it says it in the fieldset description, but i was still caught not doing it right. I added a user and spent a few minutes trying to figure out why access wasn't being granted to the user. Then I remembered to click "Commit updates."

Yes, I agree that this can be improved. However, one of the uses of this module to maintain access lists to documents in a military CMS on a "need to know"-basis. Typically 12-20 operatives (and nobody else) shall have access to a specific document. I started out doing a full save of the ACL every time a single operative was added to the list, but this made the UX very sluggish. The users of this system prefer the current two step process (add a bunch of people quickly, then save the entire list by clicking "Commit updates"). Your way is better if the main use of the system is to manage access to own nodes, but that is not the only use case for this module. I've planned a "Did you forget to save your changes"-modal. But unless somebody else volunteers to do it, it has to wait until I can find the time.

Understood. I can work around both of those. A rather simple fix...I could add some simple css and make the commit button stand out. Pulsate even, but I don't know how to do that just yet :)

I wounder if you could silently number the acl list. Then I could specifically 'display: none' for "0" or "1", however numbering works, since the author will always be the first in the list. ? Too much?

Actually it doesn't have to be in the background/silent. I wouldn't mind seeing a numbered list and may prove useful in man use cases. Either way I could still hide or not display author (first in list).

Disregard #16. Testing shows that the author does not remain at the top of the list (0 or 1). The list is built lowest UID to biggest. This makes it a bigger concern IMHO as the author can more easily get lost among the others and can more likely be removed unknowingly. I still think there should be a way to provide the author a unique css selctor (author class) for hiding or display: none if admin chooses. Doing so wouldn't change the focus of this module...just gives admin more options. Dare I say makes the module more "flexible" :)

gisle, see attached. It shows what I was seeing in my mind for Flexi. (and not using autocomplete there).

A thought, as I continue playing with this. Re: para 2, #12 above. How about a message next to every new user added that reads: (not saved).

Bill
Jane
Cory (not saved)
Stacey (not saved)

Or a general message that triggers when one new user is added and remains until the user commits changes. Somewhere in the ACL fieldset.

"You have unsaved changes."

I am not working on this any more.

I've rewritten the issue summary to make it clearer what this is about.

Because this boils down to making some changes in the ACL module it requires someone that is able to cooperate with the maintainer of the ACL module.

As maintainer of Flexi access , this is not something I need or want to give high priority. Postponing until someone steps forward and say they want to commit time or resources to get this resolved.

After nearly five years, nobody has volunteered for this. Time to close.