Creating a new account, I get the following error:

Database error: no such table: subscriber SELECT 1 FROM subscriber WHERE semail='login@mydomain.net' AND suname IS NOT NULL AND sverified

I’ve rebuilt the repository, but the issue is still there.

Any idea how to solve this? (I’m using Fossil 2.7)

The table should be created automatically. I do not know what is going wrong on your system.

To work around the problem, please run the command:

fossil alert subscribers

From an open check-out.

Thanks. It solved the problem. I’ve been able to create a new user.

I can’t be sure what has gone wrong, but when I list the existing users, it seems that no one has subscribed or succeeded to subscribe since last October, when I upgraded to Fossil 2.7.

Same happens to me with a fresh, local repo, using both official Linux binary as well as self-compiled one (v2.8).

fossil alert subscribers helped, indeed.

Also, the 'Display Name' offered during self-registration is not used - 'User ID' is, instead.

the 'Display Name' offered during self-registration is not used - 'User ID' is, instead.

The display name is used in email alerts, but not currently by the web UI.

The reason it's not done at the moment is simply because it requires an extra DB hit to pull the information up. Then among those who don't care about the small inefficiency, you have to find someone willing to do the work to fix it.

If you wanted to tackle this project yourself, the change would go in src/forum.c. It looks like to fix this you'd need to change the login_name() call in forum_from_line() to something based on the second SELECT query in alert_compute_event_text() over in src/alert.c.

in order for it to be useful in UI, the Display Name would have to be unique

Why?

In fact, I'd be relying on Display Name to not be unique: I have two accounts here, home and work (guess which ones they are!) and I'd prefer to be known as "Warren Young" in both cases, because that's the name I go by at both home and work. ;)

what's the actual point of a separate name

It has a civilizing effect.

I don't mean to assert that Fossil should try to enforce a real names policy, just that when the local norms encourage one to use a real name as their identity, those hiding behind 'nyms stand out and start off with a credibility deficit. I've seen this happen time and time again.

The table should be created automatically. I do not know what is going wrong on your system.

Doing only this:

fossil new z.fossil
fossil open z.fossil
fossil settings self-register 1
fossil server

it's not.
It seems to me that in the above scenario this func (alerts.c):

/*
** Make sure the table needed for email notification exist in the repository.
**
** If the bOnlyIfEnabled option is true, then tables are only created
** if the email-send-method is something other than "off".
*/
void alert_schema(int bOnlyIfEnabled){
  if( !alert_tables_exist() ){
    if( bOnlyIfEnabled
     && fossil_strcmp(db_get("email-send-method","off"),"off")==0
    ){
      return;  /* Don't create table for disabled email */
    }
[...]

is either called with (1) or isn't called at all...

Hi,

I was having a similar issue with the creation of new users for a new repository that has enabled auto-registration, but where there was no initial commit (just initial setup, like in this example, but using the UI instead of command line).

The problem was solved by making a first commit, and then auto-registration worked properly. I don't know if this means that the table creation which is causing the problem should be created then on first commit, or if such creation fits better the default expectations if it is created when the repository is created / configured, without requiring any first commit, but for what is on this thread, it seems that the later would be the expected behavior.

Cheers,