Fossil Forum

veedeehjay 4 weeks, 1 day ago

Post: can no longer access "Activity Reports" despite being setup user.

I rarely view the 'Activity Reports" page, so I do not know when exactly it stopped to work but now it is no longer working:

Use a different login with greater privilege than {username} to access reports.

on different/all local (clones of remote) repos despite being setup user for these cloned repos.

has something changed here in "recent" times?

This is fossil version 2.28 [7a43dcbe15] 2025-11-20 15:10:34 UTC

(and rebuilding the repo does not help)

stephan 4 weeks, 1 day ago

I rarely view the 'Activity Reports" page, so I do not know when exactly it stopped to work but now it is no longer working:

i had completely forgotten that there were any permissions checks on those pages, but a quick SCM check shows that the line which does that has not been modified since early 2015 (which was probably when /reports was added (has it really been that long???)).

The permission in question is "Read", i.e. the "o" permission. That's always on except, perhaps, for private repos, and the /reports page (at least the entry point) is not blocked by any of the spider protections.

It sounds like your permissions have gone a bit astray.

veedeehjay 4 weeks ago

It sounds like your permissions have gone a bit astray.

yes, it would look like that, but I have no idea why and how that might have happened. it concerns different repos, too. regarding "Read" permission (I trust you mean capability): "o" is "check-out", no? also, Inow have indiscriminately selected all of them (abcefghijklmnopqrstuvwxyz234567ACD) without any effect. I still get same "sorry, I can't do that dave" (i.e. "Use a different login with greater privilege than...") message?

I am still the same user on my computer with same uid etc. user account name == fossil user name etc. so I am really at a loss what is going on and what action on my side could have let to this situation?

veedeehjay 4 weeks ago

update: so I now have just updated fossil to version 2.29 [6ea30fb3cd] 2026-03-12 12:52:00 UTC -- and the problem did just go away.... this is sort of strange I guess (the version exhibiting the problem was not ancient, see initial post).

in any way: thanks for bothering. behaviour here seems back to normal after said update of fossil. but why it happened in the first place and whether it can be understood why it is now "fixed" is a different question...

chungy 4 weeks ago

but why it happened in the first place and whether it can be understood why it is now "fixed" is a different question...

You could use fossil bisect good trunk && fossil bisect bad 2025-11-20 to begin to understand why it is now fixed. See /help/bisect for usage information. Though generally, if you have something four months old, especially not on a release tag, it's probably best to double-check that the current sources actually exhibit the same problem.

For what it's worth, I checked out 2025-11-20 and could not reproduce the issue, but I'm not sure what operational mode you found the issue in (fossil ui pretty much bypasses the user capabilities system and gives you Setup capabilities at all times).

veedeehjay 4 weeks ago

yes maybe I could/should do that (although very probably it is not really relevant to anyone, if problem now has evaporated...). also, if you can't reproduce it, probably the problem is more suitable for submission to the "journal of irreproducible results" anyway :).

however, regarding 'operational mode' and fossil ui "bypassing" the user cap. system, my understanding is that fossil does not do that? rather, in a local clone, the/a fossil setup user is automatically created and named identical to user account name? nevertheless, as described I managed to get into a situation where even activating indiscriminately all existing capabilities did not make the error go away.

the fact that everything reverted to normal simply by updating the fossil binary at least seem to indicate that there was/is nothing wrong with repo integrity or configuration. but what sort of issue was at work here and what triggered it, I am really at a loss how that could be explained (never have seen something like that in a decade or so of fossil usage).

chungy 4 weeks ago

regarding 'operational mode' and fossil ui "bypassing" the user cap. system, my understanding is that fossil does not do that? rather, in a local clone, the/a fossil setup user is automatically created and named identical to user account name?

It is set up that way by default, but you could remove all the capabilities from every role and yourself, and see that through fossil ui, you can still do everything, including adding yourself back to Setup. It does appear there's a small bug where the user name in the corner shows "?", but it's probably a harmless bug for such an absurd scenario.

Naturally, if you do this through fossil server, you won't be able to access it at all no matter what. Capabilities are actually respected in that mode.

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button