This forum is actually set up that way. It sets the "reader" permissions to "gp7" and gives new users the "reader" permission (letter=u) so that they inherit that. In addition many users have permission "4", which is, IIRC, the ability to post without awaiting moderation. That permission is optionally granted by admin-level moderators (as opposed to "just" mderators) when they moderate a post by a non-anonymous user.

Please excuse brevity - am on a tablet.

Which should mean that users that are not logged in (nobody) can clone,

As soon as they can clone, they can do anything with their local copy, as they have full access rights on that copy. They won't be able to push changes back to the original without the "i" permission.

Users with the u cap. can in addition change their password, also post to the forum without the need for moderation.

That looks right to me, based on this table:

https://fossil-scm.org/fossil/doc/trunk/www/caps/ref.html

but i'm admittedly not at all familiar with the forum-level permissions.

And users with the 'd' cap., can moderate. Does this make sense?

According to that table:

d = Legacy capability letter from Fossil's forebear CVSTrac, which has no useful meaning in Fossil...

It would be really nice with some way of switching to another user, or category.

i'm not clear what you mean: an arbitrary user or your own, for testing the effects of capabilities? If you can suggest a UI/workflow which would achieve it, maybe we can add it.

Hm, I'm encountering a strange problem, when trying to create a user I keep getting the following error:

i see a snippet of code in alert.c which says that that table is only created if:

** If the bOnlyIfEnabled option is true, then tables are only created
** if the email-send-method is something other than "off".

So that setting may need to be toggled on first:

https://fossil-scm.org/fossil/help?cmd=email-send-method

That said: i've not done any forum setup before, so am guessing here, just trying to tread water until someone more forum- and permissions-savvy (coughWarrencough) can chime in.

Which should mean that users that are not logged in (nobody) can clone,

As soon as they can clone, they can do anything with their local copy, as they have full access rights on that copy. They won't be able to push changes back to the original without the "i" permission.

Right, that is fine in this case.

And users with the 'd' cap., can moderate. Does this make sense?

According to that table:

d = Legacy capability letter from Fossil's forebear CVSTrac, which has no useful meaning in Fossil...

Ah ha, ok. Maybe this could be marked somehow in /setup_uedit?

It would be really nice with some way of switching to another user, or category.

i'm not clear what you mean: an arbitrary user or your own, for testing the effects of capabilities? If you can suggest a UI/workflow which would achieve it, maybe we can add it.

I had in mind an arbitrary user, or category group -- which ever is possible. As a setup admin you are already able to "fake" whatever user you want in various ways -- so security wise this wouldn't really be an issue.

What I have in mind is a link, called "Assume user" on the /setup_ulist page, only available to users with the s capability.

Pressing link, you'd revisit the repository with the requested user capabilities (basically, assuming their persona). Then on the Logout page, you'd have another link that would allow you to unassume the user, and go back to your normal self.

Might make sense to somehow put a banner that explicitly highlights that you are assuming another user.

Hm, I'm encountering a strange problem, when trying to create a user I keep getting the following error:

i see a snippet of code in alert.c which says that that table is only created if:

** If the bOnlyIfEnabled option is true, then tables are only created
** if the email-send-method is something other than "off".

So that setting may need to be toggled on first:

<https://fossil-scm.org/fossil/help?cmd=email-send-method

That said: i've not done any forum setup before, so am guessing here, just trying to tread water until someone more forum- and permissions-savvy (coughWarrencough) can chime in.

Hm, that would seem to be a bug then? One should be able to register without requiring an email-send-method I think.

Ah ha, ok. Maybe this could be marked somehow in /setup_uedit?

If you're using setup_ulist, the 'd' permission is not available unless you type it into the capabilities field manually. That page goes out of its way to hide the permissions letter from users, replacing them with descriptions. Whether that hurts or helps legibility is debatable. "Ideally" (IMO) we would have the "?" icons next to each permission which one could pop up for more information, but we don't yet have the infrastructure for such a thing. (We have many places which could make use of that.)

What I have in mind is a link, called "Assume user" on the /setup_ulist page, only available to users with the s capability.

i understand why you would want that, but it would, in terms of privacy/security/ethics, open up cans of worms. It would enable any setup user to, e.g., send posts as another user. Currently that can only be done by resetting that user's password so that you can log in as them, but doing so is obvious to that user because their own password then no longer works. This approach would allow a setup user to "sneakily" do it. (Sidebar: someone with direct db access could potentially backup, reset/abuse, and later restore the user's password hash without having to know their password, but physical access trumps most security measures.)

i agree that it would, on occasion, be convenient, but its potential for abuse outweighs that, IMO. Even if it's never abused, every user would know that it could be abused, which may inherently reduce trust in the security of the system.

What might be feasible, but would probably still be invasive, is the functionally equivalent ability to view the site with a given set of reduced permissions. e.g. an "assume permissions of person X" without "assume the identity of person X." Literally every place which checks permissions in some form would probably be impacted by that somehow, though, and that's literally hundreds of places:

$ grep g.perm. *.c | wc -l
517

So: technically feasible, but practically very probably a major undertaking.

Hm, that would seem to be a bug then? One should be able to register without requiring an email-send-method I think.

i have never personally run through the self-registration, but does it not require sending a mail to the would-be registrant to confirm the registration? (edit: i guess i must have when this forum was set up and when sqlite3's forum went online, but that was too long ago to recall whether an email was involved.)

probably a major undertaking

No, it’s purely a matter of will backed by a bit of UI work. See fossil ci --user-override and fossil amend --author.

The key thing to realize is that you do not need the users password to set the artifact’s U card.

Not that I’m advocating for this. “Will” is the key. If we lack it, raw ability is academic.

See fossil ci --user-override and fossil amend --author.

Those are completely different beasts: they don't modify the current user's permissions, they only modify the corresponding card which gets added to the resulting artifact. Thus they only apply at a singe place in a single function each.

A feature which provides a setup user an "effective" vs "real" set of permissions requires distinguishing between those two at appropriate times. e.g. like when the user wants to flip out of their self-imposed restricted-view mode, and for adding a hypothetical banner which alerts the user that they're viewing a page with permissions other than their own.

Those are completely different beasts

Yes: I’m purposefully digging below what the end user asked for to get to what the end user actually needs.

If all ams wants is to see what his forum looks like to a non-setup user, he doesn’t need to impersonate one to learn that. Just create an alternate ID with the desired caps and log in as that user.

The feature I’m proposing is a way to impersonate another user on forum artifact addition as we currently can for commit artifacts.

Use case: currently if a Setup user edits someone’s forum post, it shows as “by” that user now. If the editor is changing the meaning of the post (e.g. removing offensive language) then this is a good thing, because the speaker has changed, and we want accountability into who said what. If they’re just fixing formatting, though, why not allow the editor to push the change “as” the OP?

Thinking about it, I think my needs are already satisfied. The user capability matrix in the Security-audit page shows what is applicable.

This seems to be a bug?

The forum feature was created first to serve this very forum’s needs and then SQLite’s. Both require an email as an anti-spam measure.

Forums like mine on tangentsoft.com also get to use this feature as-is by buying into the same base design assumptions.

I can imagine a feature where you can mark a repo as allowing registration without going thru the email loop, but who would write it other than someone who wants that feature to exist?

I’m with drh on this: email verification is a good thing.

I’m not saying your wrong to want to do without it, just that this forum software implements the policies that make sense for its current Setup users.

But that feature is already provided by fossil ...

[ ] Email verification required for self-registration

If enabled, self-registration creates a new entry in the USER table with only capabilities "7". The default user capabilities are not added until the email address associated with the self-registration has been verified. This setting only makes sense if email notifications are enabled. (Property: "selfreg-verify")

This reads as if disabling email notifications is a supported feature, and if you enable self registration there is little point to break.

So trying to make a small reproducible case.

fossil init test.fossil
fossil ui test.fossil   # And set self-register to true
fossil server test.fossil

Then try and create a user, this errors out with:

Database error: no such table: subscriber SELECT 1 FROM subscriber WHERE semail='test@foo.com' AND suname IS NOT NULL AND sverified

Thank you, drh!