Hello,

I have created a user flag and see a setting for "Users may flag themselves"
I am looking for a "Users may only flag themselves". Is this currently possible?

The reason for this would be a user flag for 'status' where the user can flag themselves as 'available' or 'unavailable'; hence they should only be able to flag themselves and not be allowed to change this flag for other users.

Thank you!

Comments

The reason for this would be a user flag for 'status' where the user can flag themselves as 'available' or 'unavailable'

(Note that with Flag there isn't a way to distinguish between users who regard themselves as 'unavailable' to users who just don't care. That's because a flag either exists or not. So it might be that the Flag module isn't suitable for you.)

This feature could also be useful for "I want to volunteer" flag.

http://drupal.org/node/881992#comment-3322786

I believe we should have this feature.

(In the meantime one can use hook_flag_access(). We should add an example to the manual.)

Hi,

To clarify, my use-case example was for when users register an account their status would be 'unavailable' (unflagged) and they can click 'available' (flagged). So user's that 'dont care' will remain 'unavailable', until they click the 'available' flag. Therefore, it makes sense that only the current user can flag themselves.

I don't know programming at all so I hope this can be added to this AWESOME module =)

Thanks

Another way of handling this would be to use Content Profile module, restrict to the profile content type, then allow users only to flag content they own.

i like this idea. maybe there should be two options for users
_ users can flag themselves
_ users can flag other users

I run a dance website www.dance-ottawa.com, and would like to start users with 'Not looking for a dance partner', but allow users to flag themselves as 'looking for a dance partner'.

Nate, the current user access setting is a boolean (1/0), right? Isn't the main challenge to write an upgrade path to turn it into a string (so we can have several options there)? Do you mind if we skip this upgrade path? ("Upgrading" "default flags" won't be easy either.) You mentioned being still in beta makes it somewhat legit to break things.

#858474: Let users flag own user object only was marked as a duplicate of this issue.

Category:support» feature

This is a feature request.

(Another use case: Users may flag themselves with a "Hide my bookmarks" flag to opt-out from appearing in listings.)

Any progress on this? I could also use this functionality in the 7.x branch.

I've stated this a couple of times but in other issues, I guess I hadn't seen this particular request.

In short, I'm generally against a setting for "Users may only Flag themselves" because I think that a more appropriate solution would just be a profile field, since if you're just adding a checkbox to the user form that only a single user has access to, it seems like it's the same thing as a profile field.

Thinking on this again though, I can see that the same argument could be made for nodes and using global flags for them. The use-case described above also seems like a strong use-case:

The reason for this would be a user flag for 'status' where the user can flag themselves as 'available' or 'unavailable'; hence they should only be able to flag themselves and not be allowed to change this flag for other users.

Finally answering @mooffie's question above:

Nate, the current user access setting is a boolean (1/0), right? Isn't the main challenge to write an upgrade path to turn it into a string (so we can have several options there)? Do you mind if we skip this upgrade path?

Yes I think it's fine that we break the API here to change the setting to a string, however I do think we should include an upgrade path to upgrade those flags that are in the database. Actually because Flag always imports all Flags into the database, this will work even on default flags (though users will need to re-export them because they'll be put into an "Overridden" state).

So yes, let's do this. Sorry for the delay in responding and the change in direction from my previous posts.

You could also argue against the profile field solution from the perspective of efficiency...

Adding a boolean field to any entity creates a whole database table with extensive indexing, just to store one byte of information.
I have already tried to start a discussion on this here: #1235352: Over-indexing of "field_data_field_xxx" tables

A flag, on the other hand, only creates an entry (in an existing table) when it is actually set. So especially when users are given a self-flag that is rarely set (e.g. "not available"), this makes database storage and searching very efficient.

Yes, no more argument necessary, but thanks for your additional input. :)

This isn't a high priority for me, so any takers on this I'd be happy to review patches. :)

Version:6.x-2.x-dev» 7.x-3.x-dev
Status:Active» Postponed

> Thinking on this again though, I can see that the same argument could be made for nodes and using global flags for them.

Indeed -- any entity that has a concept of 'owning user' could want this feature.

I think I'd rather see this happen as a consequence of #1700134: move flag access out of the flag object storage and to regular user permissions.

That would expose normal permissions per-flag.

A flag type could then declare that it supports the concept of 'own entities', and thus flags of this type would expose permissions 'flag own items with flag foo' & 'flag any item with flag foo' instead of the basic 'flag items with flag foo'.

Title:Flag settings for "User can only flag themselves"Flag permission for 'own entities'

Status:Postponed» Active

Permissions change is now in, so this can now be worked on. Anyone up for the task?

For the flag type "Users" it's still not possible I think to allow

"Users can only flag/unflag themselve"

This option would be important to make some Statuses, p.e. "I'm ready"

Thanks for answer

It's still not possible -- the purpose of this issue is to work on the code to make it possible.

Turns out this is going to be trickier than I thought.

We need to override user_access() in subclasses, which is one thing. However, that currently doesn't get an entity ID to look at. You'd think it's a simple matter to pass it one, except that $flag->user_access() gets called out of context by flag_get_flags().

This is because flag_get_flags() occasionally wants to return only the flags a particular user can access.

AFAIK we only call it like this twice:

- flag_form_alter(), which is daft because we check each flag for access a bit later on anyway.
- flag_form_node_type_form_alter(), which puts flag defaults in the node type form. This is potentially a bit trickier (though it's arguably a corner case: if a user can admin content types then they have pretty powerful rights on the site and I can't really think of cases where a user who can create content types and fields can't use all flags).

So those need cleaning up first, and the $account parameter removing from flag_get_flags(): #1878808: remove $account parameter from flag_get_flags().

Change of plan -- I'm starting to think that #1878808: remove $account parameter from flag_get_flags() isn't worth bothering with (though it did help me uncover a bug, hooray!).

Here is the rough plan:

- add an $entity_id param to user_access(), which is optional
- override user_access() in subclasses that know about 'own' stuff
- override get_permissions() in subclasses that know about 'own' stuff. This would also need to change the labelling on the regular permissions to 'Flag *any* foo'.
- figure out of the access_uid property on user flags can be folded into this or not.

Now that 3.0 is out, I don't think we can add this at this stage in development. We'd have to consider it for 8.x.

Closed #2036529: Fine-grained flag permissions as a duplicate, where it's been suggested that a contrib module could provide this.

I'm not sure how a contrib module would hook into things off the top of my head.

I'm starting to write a module that does the following:

- Locks down the permissions for Flag, so that without any permissions being granted a user can't use Flag at all;
- Adds a "Allow the user to use flags they have created" permission;
- Adds a "Allow the user to use any flags" permission;
- Stores the creator of each flag (as opposed to the user who uses the flag to flag a specific piece of content) in the database, to facilitate the functionality detailed above.

I'll try to remember to post back here when I've got something finished (or when I've realised that what I'm trying to do won't work!)

> - Adds a "Allow the user to use flags they have created" permission;

Ah, that's not the permission this issue is about.

This is about being able to flag things that you own -- so the ownership taken into account is the node.

I am not sure why you'd need to have per-user flags. Wouldn't that produce a huge number of flags in the database? That will affect performance -- Flag is not designed to scale in that direction.

You can treat each user's flaggings as separate anyway, if you make your flag non-global.

@joachim: I'm trying to create multiple "scrapbooks" that users can clip nodes to. Each flag represents a different scrapbook. It seems like the only options I've got in order to get this working are entity reference or flag, with the entity reference option involving a new content type for each scrapbook: so the flag option seems preferable from a performance point of view.

I could code this from scratch, but then I'd have to write all the views integration etc myself, and flag provides this out of the box.

Surely each scrapbook would be an entity, not a whole new entity type?

Yes, sorry, each scrapbook would be an entity. Hmm, maybe that would be the way to go, now I think about it: I suppose what I'd really want, then, is a way of connecting the Flag UI to a setup like that; the out-of-the-box entity reference UI is pretty horrible