[Nathaniel-King-Navarrete]

Changes

If the user has explicitly included * in their protected directories path, then protect all matching directories.

Protected Path:

Before:

After:

Protected Path:

Before:

After:

@SanjulaGanepola Should I write some tests for this change? Also, is using Google Translate on the l10n bundles acceptable, or do we just fill out the languages we know? Thanks.

How to test this PR

Change the Protected Paths in Connection Settings under the Source Code tab. The IFS Browser should have a locked icon for those directories.

Checklist

• have tested my change
• have created one or more test cases
• updated relevant documentation
• Remove any/all console.logs I added
• have added myself to the contributors' list in CONTRIBUTING.md

Closes #3507

[buzzia2001]

Hi @Nathaniel-King-Navarrete Is this ready for the review? Test cases are always welcome :-D

[Nathaniel-King-Navarrete]

@buzzia2001 Ready for review.

Thoughts on me not updating the other l10n bundles? Thanks!

[buzzia2001]

Thanks! The boundary-aware matching is a nice improvement. A few issues before merge:

Must fix

1. l10n key mismatch: the bundle key is missing the closing ) that the vscode.l10n.t(...) string in settings/index.ts has, so the lookup never matches. The file also lost its trailing newline.
2. Test leaks config: the it.each cases overwrite config.protectedPaths on the shared connection (in a concurrent describe) and never restore it. Wrap the body in try/finally and restore the original value.
3. * protects the whole IFS: entries that don't start with / are still compiled in the IFS branch, so * becomes ^[^/]*(?:/.*)?$ and matches every path. Add .filter(p => p.startsWith('/')).
4. /QOpenSys case bypass: the /QOpenSys prefix itself is compared case-sensitively, so /qopensys/secret (same object) isn't protected. Normalise the prefix before matching and flip the corresponding test.

To discuss

• At the moment wildcards only apply to IFS entries; MYLIB* still uses exact includes().

Nits

• A RegExp is rebuilt per entry on every call (hot path in the tree views), so consider caching the compiled patterns.
• This is a third glob-to-regex implementation (after Filter.ts and snippets.ts); a shared helper would keep their semantics aligned.
• The pure matcher logic only runs in the live IBM i suite; a unit test wouldn't need a connection.

[Nathaniel-King-Navarrete]

1. l10n key mismatch: the bundle key is missing the closing ) that the vscode.l10n.t(...) string in settings/index.ts has, so the lookup never matches. The file also lost its trailing newline.

(facepalm)

3. * protects the whole IFS: entries that don't start with / are still compiled in the IFS branch, so * becomes ^[^/]*(?:/.*)?$ and matches every path. Add .filter(p => p.startsWith('/')).

Good catch! This should have if (path.startsWith('/')) { //IFS path tipped me off to filter down to only the IFS paths.

To discuss

• At the moment wildcards only apply to IFS entries; MYLIB* still uses exact includes().

I was trying to address the complaints from the ticket, but I am happy to implement what you think is best. Let me know :)

Nits

• A RegExp is rebuilt per entry on every call (hot path in the tree views), so consider caching the compiled patterns.
• This is a third glob-to-regex implementation (after Filter.ts and snippets.ts); a shared helper would keep their semantics aligned.
• The pure matcher logic only runs in the live IBM i suite; a unit test wouldn't need a connection.

@buzzia2001 Do you want the nits in the same PR, or should I create another PR to address them?
Side note, does the core team have a linter for code style? It would be cool to not have to worry about my personal settings accidentally overwriting this repos style. Thanks!