Update documentation to disable duration settings with -1 instead of 0

[jpraet]

To turn off the notification endpoint polling, the value should be set to -1, not 0.

[wxiaoguang]

-1 and 0 both should work. it's not breaking. and how to document it clearly? recommend to always use 0 from now on?

// in go code
"MinTimeout": int(setting.UI.Notification.MinTimeout / time.Millisecond)

  // and in JS code
  if (notificationSettings.MinTimeout <= 0) {
    return;
  }

[delvh]

Yes, if 0 works as well, it indeed is not breaking.
I've assumed it wasn't, otherwise this PR does not make much sense.

[jpraet]

0 does not work. I've put a console log of notificationSettings.MinTimeout in the JS code and it prints 10000 when MIN_TIMEOUT is set to 0. When MIN_TIMEOUT is set to -1, it prints 0.

Note that setting.UI.Notification.MinTimeout is of type time.Duration, I'm not sure where to find the conversion code from string to time.Duration?

[jpraet]

What about these? I think it's likely these duration properties may also not work as documented?

gitea/docs/content/doc/advanced/config-cheat-sheet.en-us.md

Lines 261 to 262 in 8adba93

	- `PER_WRITE_TIMEOUT`: **30s**: Timeout for any write to the connection. (Set to 0 to
	disable all timeouts.)

gitea/docs/content/doc/advanced/config-cheat-sheet.en-us.md

Lines 289 to 290 in 8adba93

	- `SSH_PER_WRITE_TIMEOUT`: **30s**: Timeout for any write to the SSH connections. (Set to
	0 to disable all timeouts.)

gitea/docs/content/doc/advanced/config-cheat-sheet.en-us.md

Line 418 in 8adba93

- `STARTUP_TIMEOUT`: **30s**: If the indexer takes longer than this timeout to start - fail. (This timeout will be added to the hammer time above for child processes - as bleve will not start until the previous parent is shutdown.) Set to zero to never timeout.

gitea/docs/content/doc/advanced/config-cheat-sheet.en-us.md

Line 690 in 8adba93

- `ITEM_TTL`: **16h**: Time to keep items in cache if not used, Setting it to 0 disables caching.

gitea/docs/content/doc/advanced/config-cheat-sheet.en-us.md

Line 695 in 8adba93

- `ITEM_TTL`: **8760h**: Time to keep items in cache if not used, Setting it to 0 disables caching.

[wxiaoguang]

Then we should look into the problem. IMO 0 is a general value for defaults.

I will take a look at it, just put a request change mark here temporarily

[wxiaoguang]

It's a bug in the legacy ini package (Hmm, not legacy, still active)

Then, at the moment, all time.Duration fields in setting can not accept option value 0 if there is already a non-zero default value.

I would suggest to fix it from upstream, instead of tolerate and bypass the problem .........

	// around ini/struct.go:181
	case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
		// ParseDuration will not return err for `0`, so check the type name
		if vt.Name() == "Duration" {
			durationVal, err := key.Duration()
			if err != nil {
				if intVal, err := key.Int64(); err == nil {
					field.SetInt(intVal)
					return nil
				}
				return wrapStrictError(err, isStrict)
			}
			if isPtr {
				field.Set(reflect.ValueOf(&durationVal))
			} else if int64(durationVal) > 0 {  // 🐞 BUG HERE, even the key/value(0) exists, the ini code ignore the value
				field.Set(reflect.ValueOf(durationVal))
			}
			return nil
		}

.

[wxiaoguang]

After reading the ini code again, I do not have confidence that such behavior could be fixed soon if the ini author doesn't agree to change, the fix might cause some breaking behaviors.

So, at the moment, maybe all document should be updated accordingly, use -1 for all no-duration values.

[delvh]

@wxiaoguang That sounds to me as if this PR should indeed be marked breaking.
Otherwise users might not know to change their configurations.

[wxiaoguang]

IMO there is no code change, it doesn't break anything, it's a document bug fix only. And the fixes also works for 1.16.

If users do not find this bug (not affected), they do not need to change their configuration ......

[6543]

🚀