Merge users and profiles (request for feedback)

This was partially discussed in https://github.com/pocketbase/pocketbase/discussions/225#discussioncomment-3511148 and other similar older discussions.
The current approach of having 2 separate entities (users and profiles) to manage the application users is not very convenient and has several drawbacks:

It is confusing (and unnecessary) to have both user and relation type fields.

Setting a profile field value during user create is too verbose and nonintuitive. Currently the process requires sending multiple non-transactional requests:
// create the user model
await client.users.create({
  email<EMAIL_ADDRESS>  password: "123456",
  passwordConfirm: "123456",
});

// authorize as the previously created user
await<EMAIL_ADDRESS>'123456');

// update the user profile associated to the previously created user
await client.records.update('profiles', client.authStore.model.id, {
   name: "test",
   anotherCustomField: "Lorem ipsum...",
});

The profiles collection has create and delete API rules, but they are not really useful. Furthermore, because an empty profile is created automatically on user create, the profiles create API rule is not actually triggered (unless the profile record was deleted and then created manually).

Because the users api doesn't have API rules, currently everyone is allowed to create a new user.

In addition to the above, there also no easy support for full "manager-subordinate" users management.
While one user could be allowed to edit the profile data of another user, currently it is not possible, without using PocketBase as framework, to allow for example one user (eg. manager) to completely manage or delete another user (eg. subordinate).

Considering the above shortcomings, I propose to merge the user models and the profiles collection into a new single system collection called users.
This basically means that:

We will remove the user type field and migrate it existing usage to a relation type field (pointing to the new users collection).

We will be able to use the new collection's API rules to better control who can access and perform each crud user operation.

We will be able to create/update a user with just one request, something like:
await client.users.create({
  email<EMAIL_ADDRESS>  password: "123456",
  passwordConfirm: "123456",
  name: "test",
  anotherCustomField: "Lorem ipsum...",
});

Because of the specifics and the edge cases related to the system fields (email, verified, password) we will have to modify the default behavior of the record_upsert form.

While I'll try to automate as much as possible the required DB changes, this unfortunately will not be fully backward compatible.
Of course, there will be a detailed migration guide, but still users will have to update manually their existing custom app code.
This issue is with high prirority because it will not be backward compatible and the quicker we introduce the changes the "less damage" it will cause.
Please comment with your feedback if you have any different use case or idea how to handle better the current implementation shortcomings (pseudo code and examples are also welcomed).

Honestly it sounds pretty good, as I don't need to create a a profile after user creation, but small question. Does this mean the user has to edit via the user's endpoint and user list had to be from that as well?

This sounds reasonable to me @ganigeorgiev, I like the plan as you have proposed it. It would be nice to have API rules for the user itself and full "manager-subordinate" permissions would be important for an app I'm working on. I also think working off a single user.id and not having to worry about user.profile.id could help simplify things from a dev perspective.

While I'll try to automate as much as possible the required DB changes, this unfortunately will not be fully backward compatible.

For my specific app this shouldn't be a problem at this point. Happy to delete my users and manually recreate them, but don't want to speak for others.

This issue is with high priority because it will not be backward compatible and the quicker we introduce the changes the "less damage" it will cause.

I definitely appreciate this. Would love to start building on the new user architecture sooner rather than later.

@theMackabu:  Does this mean the user has to edit via the user's endpoint and user list had to be from that as well?

Good question. I haven't decided on that yet. Since the users will be a system collection, I think we can allow access from both services in order to minimize the breaking changes and for consistency with the admins service.
Or in other words, the following SDK calls could be equivalent:
client.users.getList();                   <=>   client.records.getList("users");
client.users.create({ ... });             <=>   client.records.create("users", { ... });
client.users.update("USER_ID", { ... });  <=>   client.records.update("users", "USER_ID", { ... });
client.users.delete("USER_ID");           <=>   client.records.delete("users", "USER_ID");

Internally the users api action could "redirect" to the records api so that the actual handling will happen in a single place.

Personally I'd rather have one way of doing things over backwards compatibility (assuming it doesn't limit functionality). PocketBase is new enough that hopefully it wouldn't be unduly burdensome for folks to rewrite these sections of their apps. Allowing both is something you'll carry forward and new users will continually question which way they should do it and the difference between them. Maybe this is an unpopular opinion so thumbs down this if you disagree.
What would the update look like for changing passwords?
await client.records.update('users', 'RECORD_ID', {
  password: '123456',
  passwordConfirm: '123456',
});

@jimafisk Maybe you are right. I will think a little more on this when I started working on the proposed changes, because supporting both apis may cause also confusion which request event hook is triggered (user or record), so maybe it would be better to throw an error if someone tries to update the users collection records via the regular records api (or the other way arround).
About the password change - in my local notes I have outlined 2 options to consider:

Don't allow users to directly update their email and password, requiring them to explicitly call /api/users/request-password-reset and /api/users/request-email-change (at it is now).

Allow users to update their email and password, but require to send also the old password for verification (when changing the password also require 2 new fields to read the new password from). Here are couple of examples how this could would like:
// change only the email
await client.users.update('USER_ID', {
    email<EMAIL_ADDRESS>    password: '123456',
});

// change only the password
await client.users.update('USER_ID', {
    password:           '123456',
    newPassword:        '654321',
    newPasswordConfirm: '654321',
});

// change the email and password at the same time
await client.users.update('USER_ID', {
    email<EMAIL_ADDRESS>    password:           '123456',
    newPassword:        '654321',
    newPasswordConfirm: '654321',
});

// change the email and password at the same time + other fields
await client.users.update('USER_ID', {
    email<EMAIL_ADDRESS>    password:           '123456',
    newPassword:        '654321',
    newPasswordConfirm: '654321',
    // other regular fields:
    name: "test",
});

For admins we will have a separate endpoint which will allow changing all user system fields (email, password, verified) from the Admin UI, without requiring to enter the current user password beforehand.

Honestly the second option seems more in-line with how a lot of other services do it, require old password to set new one.

These changes sounds great to me!
I also agree that keeping both methods for the sake of backwards compatibility is not a good idea - just remove the old method. Users should expect breaking changes before 1.0

I was able to experiment a little with the proposal and the suggestions from above and here are a little more details about the planned changes.
I think the user model and it related services could be completely removed.
Instead we will introduce the following collection types:

auth
catalogue (default)
single (for example to handle app config/options; #159)

(the names of the types are subject to change; suggestions are welcomed)
Or in other words, the "users" will be replaced with auth collection(s).
All existing user auth routes will be replaced with a corresponding collection route, for example:
/api/users/auth-via-email  =>  /api/collections/users/auth-via-email

The SDKs will no longer have a client.users and client.records services and instead a new collection service will be created that will be accessible through client.collection(ID_OR_NAME).*. For example:
// base crud:
client.records.getFullList("test", )           => client.collection("test").getFullList()
client.records.getList("test", )               => client.collection("test").getList()
client.records.getOne("test", "RECORD_ID")     => client.collection("test").getOne("RECORD_ID")
client.records.create("test", {})              => client.collection("test").create({})
client.records.update("test", "RECORD_ID", {}) => client.collection("test").update("RECORD_ID", {})
client.records.delete("test", "RECORD_ID")     => client.collection("test").delete("RECORD_ID")

// auth collection only:
client.users.authViaEmail(...)         => client.collection("test").authViaEmail(...)
client.users.authViaOAuth2(...)        => client.collection("test").authViaOAuth2(...)
client.users.refresh()                 => client.collection("test").authRefresh()
client.users.requestPasswordReset(...) => client.collection("test").requestPasswordReset(...)
client.users.confirmPasswordReset(...) => client.collection("test").confirmPasswordReset()
client.users.getAuthMethodsList()      => client.collection("test").getAuthMethodsList()
client.users.getExternalAuthsList(...) => client.collection("test").getExternalAuthsList(...)
client.users.unlinkExternalAuth(...)   => client.collection("test").unlinkExternalAuth(...)

// deleted:
[X] client.users.requestEmailChange(...)
[X] client.users.confirmEmailChange(...)

The special @request.user.* filter rule will be replaced with @request.auth.*.
You will be able to query the auth collection name (@request.auth.collectionName) allowing you to even use different auth collections for roles/groups separation.
A new manage action and API rule will be added for the auth collections to allow manager/supervisor auth models to be able to change the special subordinate fields like email, password, verified, etc. without providing the original user password.
The owner of the auth model will be able to change their email or password via the update action if authorizationPassword is provided, for example:
// change only the email
await client.collection('users').update('RECORD_ID', {
    email<EMAIL_ADDRESS>    authorizationPassword: 'old_pass',
});

// change only the password
await client.collection('users').update('RECORD_ID', {
    password: 'new_pass',
    passwordConfirm: 'new_pass',
    authorizationPassword: 'old_pass',
});

// change the email and password at the same time + some other regular field(s)
await client.collection('users').update('RECORD_ID', {
    email<EMAIL_ADDRESS>    password: 'new_pass',
    passwordConfirm: 'new_pass',
    authorizationPassword: 'old_pass',
    // regular fields:
    name: 'test',
});

The authorization token schema will be included in the token, meaning that you no longer will have to prefix the token with Admin or User:
Authorization: Admin TOKEN  =>  Auhtorization: TOKEN
Authorization: User TOKEN   =>  Auhtorization: TOKEN

There will be also a lot of other changes to the internals, for example to simplify the Record model accessors we will rename:
   SetDataValue            -> Set
   GetDataValue            -> Get
   GetBoolDataValue        -> GetBool
   GetStringDataValue      -> GetString
   GetIntDataValue         -> GetInt
   GetFloatDataValue       -> GetFloat
   GetTimeDataValue        -> GetTime
   GetDateTimeDataValue    -> GetDateTime
   GetStringSliceDataValue -> GetStringSlice

For example, you'll be able to access the user email via record.GetString("email") (this is to unify the record data access API when PocketBase is used as framework).

Overall this will be a major refactoring and a lot of components will change. As mentioned in https://github.com/pocketbase/pocketbase/discussions/123#discussioncomment-3539859, new features will be pushed back for a while, so please be patient. In short, the next couple of weeks I'll try to work on:

[ ] Finalize the core code changes.
[ ] Refactor all unit and integration tests.
[ ] Refactor the admin UI and incorporate the collection types in the design.
[ ] Refactor the JavaScript and Dart SDKs to reflect the changes (including their unit tests).
[ ] Redesign the documentation (maybe it will be a good idea to cleanup the code and finally make it public)
[ ] Prepare a migration script for the database
[ ] Prepare a migration guide for all other changes that cannot be automated

This probably will be the last major breaking change before v1.0.0 and if you have any other ideas or suggestions, please add them as comment, so that I could consider them during the refactoring.

@ganigeorgiev some feedback:

in the example above you used "test" as the collection name for both the catalogue type collection and the auth type collection right:
// base crud:
client.collection("test").getFullList()
client.collection("test").getList()
...

// auth collection only:
client.collection("test").authViaEmail(...)
client.collection("test").authViaOAuth2(...)

but this would not be the case for a real app right? you could not have the same name for two different collections - so maybe you would use "test" for the catalogue collection and maybe "users" for the auth collection?
just want to make sure I'm following along.

as for the collection type names, I like both auth and single but not sure about catalogue. I don't have a better suggestion though :) just does not feel very natural to me
when it comes to the naming changes, I'm also not sure.
previously, we had:
client.records.getList("test", )               // get list of records
client.records.getOne("test", "RECORD_ID")     // get one record
client.records.create("test", {})              // create a record
client.records.update("test", "RECORD_ID", {}) // update a record
client.records.delete("test", "RECORD_ID")     // delete a record

with the new naming changes:
client.collection("test").getList()               // does not get list of collections?
client.collection("test").getOne("RECORD_ID")     // does not get a collection?
client.collection("test").create({})              // does not create a collection?
client.collection("test").update("RECORD_ID", {}) // does not update a collection?
client.collection("test").delete("RECORD_ID")     // does not delete a collection?

to me this makes less sense! but I guess it's personal preference
other naming changes look great!

regarding the changes to the auth collection:
client.users.authViaEmail(...)         => client.collection("test").authViaEmail(...)
client.users.authViaOAuth2(...)        => client.collection("test").authViaOAuth2(...)
client.users.refresh()                 => client.collection("test").authRefresh()
client.users.requestPasswordReset(...) => client.collection("test").requestPasswordReset(...)
client.users.confirmPasswordReset(...) => client.collection("test").confirmPasswordReset()
client.users.getAuthMethodsList()      => client.collection("test").getAuthMethodsList()
client.users.getExternalAuthsList(...) => client.collection("test").getExternalAuthsList(...)
client.users.unlinkExternalAuth(...)   => client.collection("test").unlinkExternalAuth(...)

is there a specific reason why you want to specify the name of the collection here (in this example "test" versus it being set? do you want to support people having multiple auth collections?
if not, then maybe it could still make sense to use something like client.users even though it now uses a collection under the hood rather than another model.
why I personally would prefer client.users over something like client.collection("users") comes down to two reasons:

it is shorter.

const { token, user } = await locals.pocketbase.users.authViaEmail(email, password);

is already pretty long and
const { token, user } = await locals.pocketbase.collection("users").authViaEmail(email, password);

would be even longer

more convention over configuration makes for more readable code whenever you look at other peoples pocketbase auth code

should be noted that both 1) and 2) are not major issues but minor nitpicks.

finally, regarding

if you have any other ideas or suggestions, please add them as comment, so that I could consider them during the refactoring.

not sure if this is what you meant, but I would like to make another push for https://github.com/pocketbase/pocketbase/issues/312 if you are anyways refactoring collections. I've used pocketbase in two webapps so far and indirect expand would have been very useful in both of them!

sorry for the long post, hopefully some of it might have been useful.
again, these changes look great and I'm sure they will be great for the pocketbase project regardless of what function names are used.
thanks!

@ollema Thanks for the feedback.

in the example above you used "test" as the collection name for both the catalogue type collection and the auth type collection right:

The idea is that the auth collection will have everything what the default catalog colleciton has + additional auth endpoints and some special system fields (email, verified, passwordHash, etc.). Or in other words, you could treat the above example as if the "test" colleciton is auth.

as for the collection type names, I like both auth and single but not sure about catalogue. I don't have a better suggestion though :) just does not feel very natural to me

I also don't like catalog (or catalogue) but I can't think of anything better. Initially I considered "list", but then in the code it kinda read strange when collection.IsList() is called (eg. someone may think that this is slice or similar).

why I personally would prefer client.users over something like client.collection("users") comes down to three reasons:

The idea of introducing client.collection(ID_OR_NAME).* is to unify the crud and auth actions in a single service and to allow multiple auth collections (eg. you could want the manager auth collection to have different fields than the subordinate auth collection).
Keeping both client.users and client.records could lead to some strange inconsistencies and duplication of the crud services. I think it is a lot easier to reason when everyhing is a collection and can be accessed through the same api (eg. you don't have to know whether a collection is auth, catalog or single in order to call create or update).
Yes, it is a little longer to type, but users coming from Firebase may find this pattern familiar.

Initially I considered "list"

Was coming here to make the same suggestion. I thought list made more sense than catalogue but I see your point @ganigeorgiev. Just spitballing, is the "collection" naming open to change? It's a little strange to have a single collection in the first place. Maybe the overall structure could just be "data" instead of "collection" of which you have auth, collection, and single types. Not sure if that conflicts with other PB concepts so sorry to add noise, just wanted to throw other ideas out there.

@jimafisk We can change "collections", but "data" is too broad/general as a term and I don't think it is better in this case.
In practice, users rarely will have to work directly with the types, since in the Admin UI we will have human readable labels and probably a short description what each collection type do and expect to store.
An alternative to "single" I considered previously also "oneoff" but I dropped the idea because the spelling could be ambigious (one_off, oneOff, etc.).
About the SDK service naming - Instead ofclient.collection(name) we can use client.use(name) (similar to how in SQL you target specific database)  as a more shorter version. For example:
client.collection('users').getList()  vs  client.use('users').getList()

client.collection('users').authViaEmail()  vs  client.use('users').authViaEmail()

Personally, I prefer collection() because it is clear what actually the method is referring/targetting.

// auth collection only:
client.users.authViaEmail(...)         => client.collection("test").authViaEmail(...)
client.users.authViaOAuth2(...)        => client.collection("test").authViaOAuth2(...)
client.users.refresh()                 => client.collection("test").authRefresh()
client.users.requestPasswordReset(...) => client.collection("test").requestPasswordReset(...)
client.users.confirmPasswordReset(...) => client.collection("test").confirmPasswordReset()
client.users.getAuthMethodsList()      => client.collection("test").getAuthMethodsList()
client.users.getExternalAuthsList(...) => client.collection("test").getExternalAuthsList(...)
client.users.unlinkExternalAuth(...)   => client.collection("test").unlinkExternalAuth(...)

I'm confused with this API. As in, if a collection wasn't an auth collection are these methods going to exist on it? For example, if I did
client.collection("products").authViaEmail(...) // <- where products is obviously not an auth collection

Is that valid?

@blackmann Yes, you will be able to call that, but you'll get an API error telling you that the referred collection is not an auth.

TLDR; Mixing auth methods with the base collection methods is an overextension of its responsibilities
IMO, I think this design/API will become convoluted. Because as auth collections get extended with new methods, they'll be applied to collections in general. I (personally) find that weird.
How about, say a more explicit, name API like client.auth("managers") which will just return a result with these methods as an extension of [the base] collections.

I also want to use this opportunity to say, this is really great work and I'm using this in my next SaaS project starting this weekend. It's providence that I found this.
Thank you!
Stumbled on it from some Youtube shorts!

Mixing auth methods with the base collection methods is an overextension of its responsibilities

But this is currently how the client.users.* service is organized.
client.users.getFullList()
client.users.getList()
client.users.getOne()
client.users.create()
client.users.update()
client.users.delete()
client.users.refresh()
client.users.authViaEmail()
client.users.authViaOAuth2()
...

How about, say a more explicit, name API like client.auth("managers") which will just return a result with these methods as an extension of [the base] collections.

I thought of this, but I don't like that it collides with client.authStore.* and it is not consistent with client.admins.* (the admins will not be a collection since they have different business logic binded to them, like skipping API rules, special middleware, etc.).

An alternative to "single" I considered previously also "oneoff"

I agree that single is better, I don't have a problem with it, just wanted to think it through.

Personally, I prefer collection() because it is clear what actually the method is referring/targetting.

I'd tend to agree that collection('whatever') is more clear than use('whatever').

I think this design/API will become convoluted. Because as auth collections get extended with new methods, they'll be applied to collections in general.

I would assume the extension would apply to auth collections only?

@ganigeorgiev - the API decisions you've made so far have be great, so I'm definitely comfortable with you making executive decisions on what you think is best.

@jimafisk  I would assume the extension would apply to auth collections only?

Yes, auth related methods will be available only for auth collections. Obviously, since the collection is accessed via its name or id, nothing will stop you to us an auth method with a non-auth collection, as @blackmann mentioned, but you'll get an API error.
The same will be true if we move the auth related methods in a separate auth(name) service. We will have a type checker on the server-side no matter the SDK API. The whole complication around client.collection(name).* is because I want to support multiple auth collections (at work I have a use for that for a small internal company knowedge base, where there is expected to have 2 different auth models - staff and client and both have different set of fields).

@ganigeorgiev what I mean is...
How the current client.users.* is great. Because you could only access those methods .authVia*, .confirmPassword, etc on just the client.users but not other collections.
In other words, intentions should be clear while reading code instead of cross-checking with admin panel or during runtime.
But as @jimafisk said, you'll have to make the executive decision. I'm just a troublemaker, haha.

@blackmann : In other words, intentions should be clear while reading code instead of cross-checking with admin panel or during runtime.

I get what you mean but I think even if we ended up choosing the client.collection().* API, the name of the collection should be enough to make it clear while reading the code what is the intention of the collection (eg. "users", "clients", etc.). Tomorrow after work I'll research other libraries for ideas/inspirations and will post here if I stumble on something.
In the meantime, the TLDR version of the above discussions, seems to be around:

The names of the 3 new collection types - auth, catalog, single.

The changes in the SDKs API. Based on the feedback, I think we can narrow the options to these 2:
client.records.getList("users");                              vs   client.collection("users").getList();
client.records.getOne("users", "RECORD_ID");                  vs   client.collection("users").getOne("RECORD_ID");
client.records.create("users", {});                           vs   client.collection("users").create({});
client.records.update("users", "RECORD_ID", {});              vs   client.collection("users").update("RECORD_ID", {});
client.records.delete("users", "RECORD_ID", {});              vs   client.collection("users").delete("RECORD_ID", {});
client.auth.viaEmail("users"<EMAIL_ADDRESS>"123456");  vs<EMAIL_ADDRESS>"123456");
client.auth.viaOAuth2("users", ...);                          vs   client.collection("users").authViaOAuth2(...);
// other auth related methods...

(for now, I'm inclined more towards the latter because it is consistent with the existing services and it also may feel familiar to Firebase users).

Could you also add the auth methods to the api preview in the dashboard for the auth collections? I often use the preview to copy paste the code and I think it will be useful for the auth methods too.

@denisgurev  Yes, I will consider it when redesigning the Collections UI.

The names of the 3 new collection types - auth, catalog, single.

Other suggestions instead of catalog:

collections with the following collections types:

auth, ~list~ (confusing), single
auth, multiple, single
auth, set, single`
auth, series, single`

data with the following data types:

auth, collection, single

Did I miss anything?
I honestly like almost every example listed above here more than catalog, but of course that is just personal preference. I especially like replacing collection types with data types, that feels very at home to me!

The changes in the SDKs API. Based on the feedback, I think we can narrow the options to these 2:

If you are looking for user input, I would like to cast my vote for option 1 for reasons stated earlier in the thread

thanks @ganigeorgiev - very valid points, sounds great!

Hi, just became aware of this discussion due to the linking in another issue. It's a long thread with a lot of things discussed. I would like to summarize the most important things at the beginning for me (the following discussions are mostl about naming and conventions for CRUD services) and would like to add some notes:

Merge collection "user" and "profile" in a new system collection "users" which are currently connected via a relation
New system collection "users" should be used as a normal collection ("clien.records.getList('users')") rather using it as a special resurce ("client.users.getList()")
Use not a new system collection "users" but have collection types (auth, catalogue, single); the collection type auth has special CURD service like `authViaEmail, etc.
Use new API rules to query @request.auth.* to query different collections with the tpye auth; using different collections for users would allow to have roles like "admin"-users are in the collection "admin", "member"-users are in the collection "member"

Hope that matches the most important points; especially the new collection type auth.
I'm not a big fan of mixing the special process of authentication with the underlying resources user / profile / account (however you are calling it) with the normale resources stored in the collection. I do understand that the basic CRUD services like "list all", "get one", "create", and so an are technically the same and can be internally shared in the core app. But the resources "user" / "profile" will ever have some special methods or implementation for example to sanitize sensitive information like password or a method which will update the current password. That's why I would say that the underlying resources for the authentication should be handled separately. PocketBase is not an IAM or a fully identity solution; that's why I would keep it simple. Products like Firebase are separating the resource user and the corresponding process of authentication too (see for example https://firebase.google.com/docs/reference/js/v8/firebase.User ). Plus, in future there will be additional feature requests to include special processes or special attributes like mobile number verification and authentication, OTP code, and very important to have a federation of users. I think it's easier to keep it separately.
Personally, I'm a fan of separating the resources user and profile. The resource user is to manage the authentication process and profile is used to save additional information of the user which may change over the time. I like the idea of having a simple key/value store managed by the user-land code. Looking, for example at Keycloak, the have an additional relation table user_attribute. A technical implementation not have an additional relation may to use the existing table user and have an attribute profile as a JSON document for a key/value store. That would mean I can store more or less anything from user-land code as long as I'm responsible for un/marshalling it.
To be honest, I do not the like the idea of having a special collection type auth. I do not understand the benefits for this. I'm managing all my DB updates with the migrations to have a streamlined CI / CD that results in the same database in the different stages. By using a collection type auth you must ensure that the database migration files will have all necessary attributes / fields like username, password, email, and so on. I think this results in a heavy mess in the future by having new feature requests like for example OTP, federated users, and so on. I do unterstand the technically background to share the underlying methods for the collections (which are basically SQL tables) and to provide the same CRUD services to the SDK API. But again, for me the authentication process and underlying resource are too important and special to mix; plus new feature requests make it more difficult to implement.
You have mentioned two additional benefits for using the special collection type auth as follows

Using different collections for users would allow to have roles like "admin"-users are in the collection "admin", "member"-users are in the collection "member"
Use new API rules to query @request.auth.* to query different collections with the type auth

I think that these points are not necessarily linked to a new collection type auth.
Using different collections for different kind of users (like admin, member, staff, etc.) may result in multiple account for the same human person (human person "max" may be a "member" and a "staff", and so on). Linking OAuth provider would be quite tricky; federating user identities as well, SSO would not be possible.
I would rather see a new attribute "roles" which may be in the core app or is a user-land managed attribute.
Haven't yet used API rules in details but I'm using Open Policy Agent (OPA) a lot; it's the same idea. As a vision I would LOVE to have OPA integrated in PocketBase API rules. In the meantime it would be great to have full access to the request-input (or the authenticated user; JWT and user-model) to access all user-land attributes like "roles". With that you could implement an RBAC, ABAC, and a full "manager-subordinate".
So, long post, short:

Do not mix authentication (and related resource like "user") with collections
Have a key/value store for "profile" (additional table, additional JSON attribute in the same table)
No special collection type auth
Extend API rules to have full access to the JWT and authenticated user model (for example to get the attributes"profile.roles")
Implement OPA for API rules and JWT / user model is the input data

Sorry, to have different oppinion. Hope this helps in the discussion.

@mbecker Thanks for the feedback.

Personally, I'm a fan of separating the resources user and profile.

You still will be able to create your own profile collection and create a relation to it if you want to keep your users data in a separate collection.

By using a collection type auth you must ensure that the database migration files will have all necessary attributes / fields like username, password, email, and so on.

The existing user model fields (email, verified, passwordHash, etc.) are system fields and will be automatically created for each auth collection (and underlying table) and they cannot be deleted or renamed. From the Admin UI you will be able to manage only the configuration of their custom fields (the same as it is now with the profiles collection).

To be honest, I do not the like the idea of having a special collection type auth. I do not understand the benefits for this.

The main benefits of treating the users authentication as a regular collection are:

there is no need for special search handling
you'll have API rules to control who is allowed to create users
you could have multiple auth collections supporting auth models with different set of fields, not just "role".
one auth collection can be configured to be allowed to fully manage the users in another auth collection (including changing their password, email, verified state without prior confirmation to be required).

Using different collections for different kind of users (like admin, member, staff, etc.) may result in multiple account for the same human person (human person "max" may be a "member" and a "staff", and so on). Linking OAuth provider would be quite tricky; federating user identities as well, SSO would not be possible.

If your auth models have the same set of fields, then you could just use  a single auth collection (by default "users" will be created). OAuth2 linking and everything related to the authentication will be only within the collection namespace.

Extend API rules to have full access to the JWT and authenticated user model (for example to get the attributes"profile.roles")

This is already supported. You should be able to query the user profile fields by doing @request.user.profile.*.

Implement OPA for API rules and JWT / user model is the input data

I don't plan implementing an extra layer access layer. It will complicate both the management in the UI and when used as framework. The event hooks are the recommended way to extend and tailor the default PocketBase behavior if users need more fine grained auth controls than what the API rules provide.

While the field type “user” may be identical to a relation field pointing at the user table, I do think it’s a comforting and nice feature to have this dedicated “user” field type.

@lukepighetti Based on the several raised issues and discussions in the past, most users seems to find it confusing to have both a user model and profiles collection (for example https://github.com/pocketbase/pocketbase/discussions/242).
Having only one entity ("collection") should be a lot easier and intuitive for the developers.

Also, I do think it’s important to not force PII like email into a public facing record. That appears to be one benefit of the separate “profile” table.

I agree, but since the users will be a collection, you will be able to limit the access to the user records with the collection API rules.
Users will always have the option to create their own profiles collection and reference it with a relation field. The only difference from the existing implementation is that it will not be created by default.

@ganigeorgiev with the new architecture would there be a way to allow users from different auth type collections to use the same login form? I'd like to have a manager-subordinate relationship between "staff" and "members" where we'd need to collect additional profile information for members, but don't need this for staff. This seems like the correct use-case for two different auth types, but wasn't sure if I'd need to handle this logins separately if I did that as opposed to a single auth type with a custom "role" field. Thanks!

with the new architecture would there be a way to allow users from different auth type collections to use the same login form?

On the frontend you can show the same login form, but when submitting the form you'll need to specify the auth collection you are trying to sign-in, eg. client.collection("staff").authViaEmail(...). The idea is that each auth collections will have their own options to configure the auth behavior. Currently this are the options that I'm planning to use based on my needs:
type CollectionAuthOptions struct {
	FullAccessRule          *string  `form:"fullAccessRule" json:"fullAccessRule"`
	AllowOAuth2Auth         bool     `form:"allowOAuth2Auth" json:"allowOAuth2Auth"`
	AllowOAuth2Registration bool     `form:"AllowOAuth2Registration" json:"AllowOAuth2Registration"`
	AllowUsernameAuth       bool     `form:"allowUsernameAuth" json:"allowUsernameAuth"`
	AllowEmailAuth          bool     `form:"allowEmailAuth" json:"allowEmailAuth"`
	RequireEmail            bool     `form:"requireEmail" json:"requireEmail"`
	ExceptEmailDomains      []string `form:"exceptEmailDomains" json:"exceptEmailDomains"`
	OnlyEmailDomains        []string `form:"onlyEmailDomains" json:"onlyEmailDomains"`
	MinPasswordLength       int      `form:"minPasswordLength" json:"minPasswordLength"`
}

The configuration of the individual OAuth2 providers will be global and shared across all auth collections; each auth collection will have only options to allow/disallow OAuth2 sign-in/up.
Additionally, each auth record will have an optional emailVisibility field, so that users can control on their own whether their email should be visible in listings or expansions (this will be ignored for admins or when the FullAccessRule is satisfied).
Each auth colleciton will have its own table, meaning that you'll be able to have a user registered both in staff and members for example. We'll ensure only that the auth record id is unique across all auth collections in order to simplify the API rules check when doing something like userId = @request.auth.id.

@jimafisk If you don't have a way to identify upfront to which collection you want to submit the login form, you can apply a "failover" flow - first send the request to the staffs collection and if it fail send another request to the members collection. If both fail, show an error:
const email = "...";
const password = "...";

try {
    await client.collection("staff").authViaEmail(email, password);
} catch (_) {
    // failover to "members" authentication
    try {
        await client.collection("members").authViaEmail(email, password);
    } catch(err) {
        alert("Invalid login credentials");
    }
}

@JessedeJonge It's hard to tell. I've been asked a lot lately for ETAs (especially on the support email) and I understand that it is important, but as I mentioned in https://github.com/pocketbase/pocketbase/discussions/123#discussioncomment-3539859, I work on PocketBase only on my free time and I don't want to constraint my self with hard deadlines.
The "pure" server-side changes are already done, but a lot of the existing unit and integration tests need to be rewritten from scratch, which along with the Admin UI redesign, probably will be the most time consuming parts of the refactoring.
Today I've taken a day off from my day job and I've started working on the server-side tests, but still there is a lot of work that needs to be done and I don't want to rush it (especially when users authentication is involved).
If you need some "approximate time estimate", probably I'd say somewhere around mid October.

Make sure you take your time so you don't burn out. PocketBase looks like it has a bright future.

Just went thru this excellent thread, and I probably won't get too many people agreeing with my point of view, but heck I'll add my 2c, as I am a user of many Baas and similar type of software. I am amazed at certain aspects of Pocketbase, which make it a dream platform for certain business uses cases. However, I would say that user authorization is not one of the features on Pocketbase that I think is revolutionary or that will give it mass adoption. There are just too many authorization platforms that are way ahead and it will take an enormous amount of work to get it up to par and then keep up. Do you really want to spend your time developing a new authorization platform? Personally, I see the strengths of Pocketbase in entirely different areas and I think a focus on user authorization tables is a distraction, and that adding other features instead would be a more wise use of time,  and would add alot more value to the platform. It's just a guess, but I suspect most people trying out Pocketbase are just using the admin interface, and admin APIs, because they want an easy to use backend for some application, that actually feels like database (personally I dislike how all these Baas try to be like a spreadsheet) and isn't painful to set up and use. I doubt storing user authorization is what most people are looking for, again because there are so many other solutions already out there that work well. Simply having user tokens, which Pocketbase already does well, is probably sufficient.
In terms of 2 other features that would be more beneficial than user authorization:

[ ] Admin Roles:  I suspect that many people trying out Pocketbase just use the admin role, and then like me are blown away by the excellent admin interface to manage the database. It's so incredibly well thought out and designed and solves so many problematic issues with other no-code databases.  And yet, if you wanted to share the database admin with your small team, you couldn't it because there is only a super admin role, and it is too risky to give a super admin role to some members. So personally, I think a key feature to add is Admin Roles, that restrict access to certain features of the database, e.g. certain admins can only view data, but can't change anything, while other admins can edit data, put only on a per collection level. I think something like this is far more important than user authorization b/c most people will use Pocketbase for the database aspect.
[ ] Webhooks: I certainly agree that adding serverless functions into Pocketbase is a total waste since there are better platforms for this. So this is why I think an easy way to create webhooks from the admin interface, based on database changes, would be an incredible addition. Many people using Pocketbase can't program in Go, so they won't know how to use Event hooks to set up a webhook. But, if you have an easy admin UI interface to create webhooks that anyone can use, the potential here is enormous, as you can build a full application quite easily by just sending all the business logic to the webhooks. This by the way, was a key feature of Hasura that helped it take off.

The above 2 features are honestly the only 2 critical features, I think are lacking right now in Pocketbase. Everything else added on top is obviously amazing, but without those 2, I think the use cases get a bit restricted here. It's doubtful anyone using Pocketbase really wants to spend time developing a front end for their team to add/edit data, and they probably already have serverless functions they can hook into for business logic.
One final feature, given my thoughts on user authorization:

[ ] SSO: I think many potential  users will opt to keep their current user authorization provider, rather than move user authorization to Pocketbase. So it would be great if there was a way to authenticate users with Pocketbase if they are authenticated with another provider, like Auth0. If you take a look at something like Discourse, they have a very simple type of flow for SSO that makes it extremely easy to authenticate users to the platform even if you use a 3rd party authorization provider. I wonder how difficult it would be to implement this in Pocketbase. For example, if a user is authenticated with my Auth0 app, can I also get them authenticated with Pocketbase to get them a user token?

@osseonews For the SSO - there is no built in solution for that, but you can always implement it on your won if you use PocketBase as framework by passing additional context from the 3rd party auth system. For example you could check https://github.com/pocketbase/pocketbase/issues/136#issuecomment-1186191919 (this will change slightly after the refactoring, but more-or-less the idea will be the same - an auth model will be considered authenticated if it exist in the request contex).

@ganigeorgiev Thanks. Issue 136 answer the question, but my difficulty is that I don't know Go and more importantly don't know how to set up Pocketbase as a framework on Digital Ocean. I've already got it up and running without extending it, and continue to be incredibly impressed. Maybe there is some guide for setting up framework on DO? Or maybe this is something pockethost.io can handle?
In any case, I do agree with the person in Issue 136 where they said as follows: "no more effort into auth. pocketbase already has more than enough for standard use." If you can easily autheticate with a header as in 136 code, then I think auth is solved, and most people, especially enterprises, will almost always use their internal auth provider.

It's a cool idea to allow 3rd party auth, but personally I would be sad if the built-in auth was sacrificed for this. The big sell for me is that PocketBase is an all-in-one solution that doesn't require complicated integrations. There are endless BaaS solutions targeting the enterprise market, imo PB carved a niche with practical self-hosting that's resonating with folks.

@jimafisk I agree 100%, just saying the the auth that is available now is suitable for nearly all cases, and enterprise users, who will ultimately pay for this platform, will never migrate from their current auth platform to a pocketbase auth, so I don't see much benefit in further building out auth. "There are endless BaaS solutions targeting the enterprise market".  Yes, that's true, but none are truly portable and all are silly expensive in the long-run with huge lock-in. Plus, most neglect some basic features that are available out of the box with Pocketbase. That's why I think Pocketbase resonates. Upload an executable and you have your database backend with an amazing admin interface + API in minutes! This is a dream! I think most people will use Pocketbase as a Baas to replace many use cases, but will still retain existing auth. Will be interesting to see how this develops.

Small proposal to move authViaEmail and all required data for them into provider table with provider type 'emailAndPassword'.
New auth method will get provider type and required values for them. It's unify logic and solve problem with update user data because in user model will be stored only user data (not auth data which required verification in email case and maybe phone number in future).
New users model require only id, created, updated fields. All other fields optional.
New authProviders model with id,  created, updated userId, providerType (forignkey to authProviderOptions. Some examples: 'email', 'phoneNumber', 'oauth2.google', 'oauth2.facebook'), lastUsed, and some json fileds provider_data(contains inforamthion from oauth token or for emial provider verified, verification_code if email have been sent and some other fields), meta (additional information like comment or any other)
New authProviderOptions model with id, type, options (type json).
Exmaple row for email provider 1, 'emailAndPassword', { 'AllowedDomains': ['gmail'], 'EmailVerificationTokenDuration': 604800, 'templates': {'Verification': {...}, ...}}}
and  for google provider 2, 'oauth2.google', {'appName': ..., 'appSecret': ..., 'AllowAuth': true, 'AllowRegistration': true, 'AutolinkBy': ['email'], ...}
Api methods examples:
// sign in using email
await client.collection("users").signIn('emailAndPassword', {'email': 'example.com', 'password': 'qwerty1234'});
// sign up using email
await client.collection("users").signUp('emailAndPassword', {'email': 'example.com', 'password': 'qwerty1234'});
// sign in using google
await client.collection("users").signIn('oauth2.google', {'code': '...'}); // insted of code we can send accessToken.
// sign out
await client.signOut()

This model is highly expandable. In it, for example, you can generally remove the auth via email and leave only the auth via google. You can also easily add any options for any user auth method and for each auth provider globaly. What do you think aboud this changes?

@heckad

Small proposal to move authViaEmail and all required data for them into provider table with provider type 'emailAndPassword'. New auth method will get provider type and required values for them. It's unify logic and solve problem with update user data because in user model will be stored only user data

But this is basically how currently the user data is managed using the profiles collection. You wouldn't really benefit too much by moving the email and other common user fields to a separate table - it will just complicate the internals requiring always to have a join with the related "auth provider".
The idea of this issue is to simplify the users management and to add support for:

allowing create/update of a user in a single transactional request together with the user specific data
multiple auth models for fully "manager-subordinate" relation (eg. one user to be able to change the password of another, or even delete other users).
api rules to control who can create new users

@ganigeorgiev

You wouldn't really benefit too much by moving the email and other common user fields to a separate table

What if it is necessary that only users from our google workspace can sign in? If email and password would be a simple provider, we just can off them. I just don't know whether to make it as a separate feature request or it's better to make it into the current changes since backwards compatibility breaks.

it will just complicate the internals requiring always to have a join with the related "auth provider".

Can you explain why does it required always to have a join with the related "auth provider"? Maybe we have an external jwt token generator which generates correct tokens. In such a case, we didn't require any linked auth method at all.

@heckad

What if it is necessary that only users from our google workspace can sign in? If email and password would be a simple provider, we just can off them.

But you'll be able to do that (see the auth collection options in https://github.com/pocketbase/pocketbase/issues/376#issuecomment-1243574727). Why moving the email field in a separate table will help with that?

Can you explain why does it required always to have a join with the related "auth provider"?

Because you'll need to perform a search/sort based on the user email, username, etc. Additionally this will increase the complexity for developers using PocketBase as framework, because they will have to manually query or use some special helper to fetch the email every time when they need to read it.

Maybe we have an external jwt token generator which generates correct tokens. In such a case, we didn't require any linked auth method at all.

I don't see issue with that. If all possible auth methods are disabled (email, username, oauth2) you'll still be able to create and manage your users based on your custom auth logic. As mentioned in this https://github.com/pocketbase/pocketbase/issues/376#issuecomment-1250267806, an auth model is considered authenticated as long as it exists in the request context.

But you'll be able to do that (see the auth collection options in #376 (comment)). Why moving the email field in a separate table will help with that?

It's just that these fields only apply to one authorization method. It is very strange to see them in the main model when they may not be useful. Intuitively, I want to take them out to where they will be the very place.

Because you'll need to perform a search/sort based on the user email, username, etc. Additionally this will increase the complexity for developers using PocketBase as framework, because they will have to manually query or use some special helper to fetch the email every time when they need to read it.

Filter example:
client.collection('users').filter({"provider.emailAndPassword.email"<EMAIL_ADDRESS>
Also, we can filter by another provider if a provider has different email
client.collection('users').filter({"provider.google.email"<EMAIL_ADDRESS>( email and other data field extracted from token)

I don't see issue with that. If all possible auth methods are disabled (email, username, oauth2) you'll still be able to create and manage your users based on your custom auth logic.

It would be great to have the built-in ability to use third-party tokens as if they were actually issued. For example, configure where to get JWKS and the user id field name. Probably this is also the feature request.)

It's just that these fields only apply to one authorization method. It is very strange to see them in the main model when they may not be useful. Intuitively, I want to take them out to where they will be the very place.

That's not always the case. As mentioned previously, there are use cases where you need to share the fields with other auth providers. The password field is one example. Another is for example, linking an oauth2 account to an existing user by its email, or even verifying the user email with the oauth2 sign-in (this is actually already implemented in https://github.com/pocketbase/pocketbase/blob/master/forms/user_oauth2_login.go#L127-L188).

Filter example: ...

The shown example uses the SDK. If we move the individual email field to separate table, internally you will have to join it to the user model and this will not be very conventient when PocketBase is used as framework.

It would be great to have the built-in ability to use third-party tokens as if they were actually issued.

This is too user-land specific and I don't think it can be integrated by default. If you need custom auth logic, you have to use PocketBase as framework and create a middleware similar to the linked example above. For JWKS you may want to check https://github.com/pocketbase/pocketbase/issues/144.

I think discussion is good, but be careful bike shedding on such a small high leverage personal project unless there is a huge benefit to the proposals

I think a big feature that should come out of (and enable) this is controlling which record fields should be public vs private.
For example, when merging users and profiles, the password, passwordConfirm, userId, and provider fields should be marked as private/hidden. This way, when attaching the profiles relation to a collection (eg articles), none of the sensitive information will be included when ?expand=author is present on the articles list response.
This would be useful if the toggles were available globally as I don't want all fields to be publicly visible in the API response.

@lukeed Private/hidden API fields for now are left out of the scope of v0.8.
The implementation in the upcoming v0.8 pre-release hides by default all sensitive auth model fields (eg. password/passwordHash, tokenKey, etc.). The user will have an option only to toggle the visibility of their email using the system emailVisibility bool field. Or in other words, when expanding a user relation, you'll have access to the following props:
{
    // common meta fields available for all records
    "id": "...",
    "created": "...",
    "updated": "...",
    "collectionId": "...",
    "collectionName": "...",
    "expand": {...}

    // fields available only for auth collections
    "username": "...", // all users will have a required username (it is autogenerated by default)
    "verified": true,
    "emailVisibility": true,
    "email"<EMAIL_ADDRESS>// visible only if emailVisibility is true

    // other collection fields...
    "name": "..."
}

The email address will be always visible (aka. ignoring emailVisibility) when 1 of the following conditions is met:

the current authenticated model is admin
the current authenticated model is the owner of the record
the current authenticated model is another user (could be also from another auth collection) that satisfies the record's Collection "Manage" API rule

(the same applies when you perform search/sort over the email field)
If you need to control the visibility of the other fields, for now they'll have to be moved in a separate collection (aka. similar to the existing profiles workflow).

Sure, but that sounds like a lot of work to bake in a one-off exception system when it wouldn’t be much more to generalize the hidden fields behavior across all collections. Going ahead with the above will work for users but if a generalized solutions ever comes, then it either becomes a breaking change for users mgmt or there’s two ways to do the same thing for users

@lukeed The emailVisibility is not exactly the same as hidden/private fields, because it allows the user (or anyone who has permission to modify the record) to control themselves whether they want their email to be public visible or not.
I don't think hidden/private fields will introduce a breaking change in the future. It will probably will be implemented as field option (similar to the required, unique, etc.) and you'll be able to change it only if you are authenticated as admin by modifying the collection schema. In any case, v0.8 ended up with a lot of features already and I don't want to expand it's scope anymore because it is a blocker for other contributions.

I'm wary of walking back this design decision. It sounds like the splitting of users and profiles was very well thought out. I'm not convinced that the bonuses of reverting this is worth the squeeze. But that's just one man's opinion .

@lukepighetti Just for the last 1-2 weeks there were 5 similar issues caused by the confusion between users and profiles - https://github.com/pocketbase/pocketbase/issues/762,  https://github.com/pocketbase/pocketbase/discussions/817, https://github.com/pocketbase/pocketbase/issues/821, https://github.com/pocketbase/pocketbase/issues/828; and there are at least 2 more similar requests sent to the support mail). While we can add more documentation and explain the differences better, still the existing separation is not very intuitive and it's seems confusing for most developers.
Also, please keep in mind that you'll still be able to create your own profiles collection and associate it with the new "auth" collection(s) if you want to manage your users data this way. The refactoring is actually consisting mostly of moving the users handling under the collection APIs and the merge of the 2 entities is just a side-effect of that. While this makes the internals harder to maintain and test due to the introduced conditional behavior (since now we have different "collection types" that may have special validations and their own options), the public api in general is unified and it should be a lot easier to work with.
Unfortunately  last weekend I had to deal with some urgent issues at work and it prevented me to finalize the refactoring tests, but this weekend, if nothing else comes up, I think I'll be able to publish a v0.8.0 pre-reelase so that anyone who wants to test it will be able to preview and share their opinion on the new api (I'm planning a 2-weeks window to collect feedback before publishing a final v0.8.0).

For anyone who wants to test the new changes, I've just pushed a v0.8.0-rc1 pre-release.
Please note that it contains breaking changes!
The changelog comes with some migration instructions but if someone has trouble migrating their old v0.7.x pb_data feel free to open an issue/discussion and I'll try to provide more details. Official v0.8.0 open sourced site documentation will be available soon, but in the meantime you could refer to the updated "API previews" for client-side examples/api guidance.

@ganigeorgiev I've just migrate my test project and other than having to change the loggedUser.profile.name to loggedUser.name, loggedUser.profile.avatar to loggedUser.avatar, etc. fields in my code everything seems to works great.
Love the small changes in the admin,especially the new api preview. I was also going to post an issue about multi-relations with 1000+ items that were failing to load in the browser but it seems that it is already fixed in the new version 🥳!

@ganigeorgiev is there a way to expand user relation now without profiles?

@karniv00l It should work the same way for all collections, aka. ?expand=relField1,relField2.
Please note that the relation will be expanded only if the user is allowed to view the expanded relation record.

@ganigeorgiev thank you! I forgot to set up API rules

just ported my app to 0.8 - works great so far! really nice improvements across the board!


fix(ssr): v-model w/ select

close #7392

/ecosystem-ci run

Sorry, I forgot that ecosystem-ci could only be run when the PR is up-to-date with the main branch. Now force pushed.
/ecosystem-ci run

/ecosystem-ci run

The Ecosystem CI is all green now. But the snapshot test failed, and I can't understand the error message. Could you take a look?

The Ecosystem CI is all green now. But the snapshot test failed, and I can't understand the error message. Could you take a look?

just update the snapshot, all test green now.


Add files via upload

The latest update of 3d viewer,team memeber can use it  to make a test.

unnecessary


[PR-4]Decision making module for automatic migration

PR has following changes:
class for periodically watch metric and call prediction module for top migration candidate
class for predict kernel server node for replica.
Note:

PR is written on top of #746 and #753.  #746 and #753 are closed and  #794, #795, #796 are opened for handling metric management.
This PR has addressed review comments for #745

Thanks. Please rebase before requesting a review.

Please check that the comments describing this PR are correct (all the PR's mentioned there have been closed, so I assume it's out of date).
And please confirm that all of this PR needs to be reviewed?  It's quite huge.
Then please self-review.
Then ask @VenuReddy2103 to review.
Then ask me to do a final review before merging.
Thanks.

Review comment fix from PR #745:

General convention for package name is to use lowercase
Status: "migrationDecision" module changed to "migrationdecision".
Don't need logger for each instance of it. Make it private static final.
Status: MetricWatcher logger changed to "private static final"
Why transient volatile ?
Status: Removed "transient" modifier from ResettableTimer in MetricWatcher
Instead if timer != null, then simply return can be more clear ?
Status: Timer instance creation moved to constructor. So removed null check from start method of MetricWatcher
What we need was nodeMetric from client to the kernelserver. But we took from kernelserver to the client. Did we assume both to be same ? They both are not necessary to be same.
Status: Updated code as per suggestion. Now rate and latency are used from kernelClient node metric.

@VenuReddy2103 , I have handled all review comments from PR #745. Please have a look.
@quinton-hoole   #746 and #753 are closed and new PR  #794, #795 and #796 are open respectively for microservice and node metric management. Same has been updated in PR description.

@AmitRoushan I still cannot review this PR until #794 , #795 and #796 have been reviewed.  And I can't review those until https://github.com/amino-os/Amino.Run/pull/794#issuecomment-500074934 has been answered.  So basically all of these PR's are blocked.

@quinton-hoole
I have reverted KVstore code changes. Changes are made to test migration.
Also we fixed one bug , fount during testing.
Please find the attached status report below:

Build report

KVStore App report

Hankstodo App report

MinnieTwitter App report

HankstodoRuby App report

KVstorejs App report

@quinton-hoole
I have fixed most of review comments but still i need some more time to run some test scenario for migration.

Thanks Amit
On Mon, Sep 9, 2019, 04:57 Amit Roushan<EMAIL_ADDRESS>wrote:

@quinton-hoole https://github.com/quinton-hoole
I have fixed most of review comments but still i need some more time to
run some test scenario for migration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/amino-os/Amino.Run/pull/793?email_source=notifications&email_token=AKNAA6H25X3YXZABUOV67MLQIY2Y3A5CNFSM4HSZF2U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HJGPY#issuecomment-529437503,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKNAA6AQPSFU42J76OXHWHDQIY2Y3ANCNFSM4HSZF2UQ
.

@AmitRoushan  How is your testing going?

@AmitRoushan ?

@AmitRoushan @VenuReddy2103 What is the status with this PR please?

@AmitRoushan @VenuReddy2103 What is the status with this PR please?


[sketch] migrate tldraw files from other tldraw versions

Motivation
A Composer user wants to import the tldraw files they've created using tldraw.com but they are failing to import.
Finish Line

The Sketch plugin should support importing tldraw files, regardless of the schema with which they were created.
Update tldraw to the latest version, currently 2.0.2
Ensure we can migrate existing sketch objects created with the previous version of tldraw to the latest version.
RELATED: to upgrade past 2.0.0.alpha-19, we need to talk to the tldraw team about a commercial license (pricing is unclear)

Did some exploration on this today and here's some notes:

Any sketch objects created with 2.0.0.alpha-19 will fail to load once we upgrade unless we manually migrate them.
TLDraw provides migrations across versions, and it should be possible to run the migration code to get from 2.0.0.alpha-19 to 2.0.2

Here's an example of the migration with the tldraw-yjs integration
The migration works by calling migratePersistedRecord() and passing in the serialized schema.

When a client running an older version of the sketch plugin tries to read a newer file, it's actually possible to do down migrations to migrate backwards.

Some open questions:

How do we get the serialized schemas for 2.0.0.alpha-19 objects when we haven't been persisting it up to this point? Maybe we can deploy the serialized schema in code along with the upgrade and load it somehow?
How does this interact, if at all, with the work we're doing on echo-schema?

blocked on export issue #6490


Request for preprocessing code for Matterport3D or preprocessed dataset

Hello, I want to try the network on Matterport3D, but experience problems when stitching views. My results are shown in the picture below. Could you please provide me your stitching codes or preprocessed dataset for Matterport3D? Thanks!

Hi I also was wondering if it might be possible to ask for the same thing. Thank you!

Hello, I encountered the same issue. How did you resolve it?

Hello, I encountered the same issue. How did you resolve it?

Hi, I use the preprocessing code provided by UniFuse to stitch the skybox images together. I hope this helps you.

您好，我遇到了同样的问题。您是怎么解决的？

您好，我使用 UniFuse 提供的预处理代码将天空盒图像拼接在一起。我希望这对你有所帮助。

I obtained the depth map using the UniFuse method, and the depth values of the upper and lower boundaries of the image are both 0. How did you handle this part


Chore: add organization or repo secrets to enable PyPI publishing

In order to have Github Actions upload to PyPI, the repository or organization needs to have encrypted secrets.
Since MTC will likely want to control how those are managed, I am assigning this to MTC (@lmz feel free to reassign).

@lmz I assume you'd like this capability?

🧊 for now.


Multiple forests to One Dir - Group Filter

Under the heading 'Multiple forests, single sync server, users are represented in only one directory'
I think it's important to call out here that the use of a group filter is not recommended and can lead to unexcepted results.
If you need more details please just let me know.
Br.
Joshua
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0562f646-ef99-e341-e2fc-fcc3eed44d15
Version Independent ID: 1fc5ebad-f1b3-babe-f492-c6c888c7781a
Content: Azure AD Connect: Supported topologies
Content Source: articles/active-directory/hybrid/plan-connect-topologies.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@JBines thanks! What sort of details which you like this to cover?

@MarileeTurscak-MSFT Thanks for the reply. I was thinking we should just add a one liner here but maybe some background would be helpful :)
I have found issues with a couple of customers using multi forest sync's to a single azure ad where the use of group filters are also used. It has some strange outcomes. For example if a contact is create in one forest and not placed in the filtering group.  If the contact is match to a mailbox user from the other forest and a join occors the cloudfilter value will then be set to $true and the mailbox will be in a deleted state. Like I said 'unexcepted results'
As you know group filters are only supported as part of a pilot but my view is, that in multi forest enviroment the use of any group filters should to be ruled out at the design stage. As it currently stands some could say that they are piloting this scenario and then wonder why they are have strange results. Maybe they will keep doing it anyway but maybe it will help ;)

Hi @Jbines,
I made a pull request to update the doc with some guidance. The list of things to keep in mind when using group filters with a multi-forest environment is included here:

When synchronizing multiple AD forests, you can configure group-based filtering by specifying a different group for each AD connector. If you wish to synchronize a user in one AD forest and the same user has one or more corresponding objects in other AD forests, you must ensure that the user object and all its corresponding objects are within group-based filtering scope.

Hope this helps!


Adding support for Scottish Gaelic (gd)

I work with national libraries in the United Kingdom. We've been very happy with your Welsh language detection, and would like to add support for Scottish Gaelic.
In this repository I've generated a gd language profile from texts supplied by the National Library of Scotland (they can't be openly licensed unfortunately, so they are not in the repository).
The language profile is here: https://github.com/ukwa/language-profile-creation/blob/master/profile-output/gd
I tuned the minimum N-gram frequency up to 50 in order to get the profile down to about 30KB in size. If you'd like a different size/configuration please let me know.

Hello again. I'm happy to reformat this in any way you need, so it can be included. Just let me know.


Fermi level from a dense k-mesh

Hello! I would like sumo to get the Fermi level from a calculation of dense k-mesh, which is more accurate, not from a calculation of bands along the high-symmetry lines. Is this possible? Thanks for your work!

I found discussion #68 also related. I think if you can allow the user the set the Fermi level as input, that would be ideal. Thanks!

@pamukb This should be relatively easy to add. Thank you for the suggestion.
@ajjackson Yeah, a catch-up about this sounds good, I'll message you offline.

Hi @pamukb
Just an update to say that it is now possible to set a user-specified reference energy with --zero-energy. This can be accessed via a Developer installation (it's on Master already) now, and will be in the next PyPI release.
Happy computing,
Adam


fix: avoid breaking Bazel 5 users

Related to #584 which removed a Bazel 5 workaround
Makes platform_utils harder to discover, but the generated doc for it was useless, and this is the simplest way to ease the bazel-lib 2.0 rollout.
Type of change

Refactor (a code change that neither fixes a bug or adds a new feature)

Test plan
None

This plan was too simplistic, the platform_utils is loaded by some of our documented helpers, so the bzl_library chain can not be broken so easily 😓


Set up automated deploy step

From what I can tell, the site is served from the gh-pages branch.
I've noticed we've been committing the dist directory and other build artifacts to master but ideally we should only ever have to push them to gh-pages.
We can use something like the gh-pages npm module to keep our master (development) and gh-pages (production) branches separate.
I have my blog as an example of how these two branches can exist. The development branch generates what goes into a public/ directory and the contents of that directory are what you see in the master branch.
I'd be happy to take this on as a task if others find it useful.

Hey pam,
I had this conversation last week with some people in the office. I like the idea of improving it because I really dont like to commit dist files everytime.
What we can do maybe is to create a script that generates dist files and creates a new branch called gh-pages and push force it to github. This way we will always have 1 commit on gh-pages with the latest changes. What do you think?

That's exactly what the npm module, gh-pages does 😄  👍

Cool, in my opinion we can use it them 💃

@glauberramos I closed this issue because I had unintentionally deployed 🙊 . We can deploy locally or (preferrably) on Snap by taking a build and promoting it to the deploy step when it's green
https://snap-ci.com/funretro/distributed/branch/master


Allow user to change theme

Join our Discord server to discuss ideas and ask questions.

when you mean change theme , do you mean something like a dark mode , and other modes?

This issue is related to #4.
Check this comment I think you'll get the idea https://github.com/thtauhid/terminal-portfolio/issues/4#issuecomment-1742735223
This issue if for implementing the 3rd point discussed in the comment.

okay , looks like it has been assigned.
i will be on the look out

I have completed this. Thanks

Completed in #76


Add GitHub Workflow for Auto-Closing Similar Issue Requests

Feature Description
Explanation of Workflow
Trigger: The workflow runs every time a new issue is created.
Check Duplicates: Uses a GitHub Action to detect similar issues by comparing the title and content with keywords and common phrases.
Close and Comment: If a duplicate is detected, it closes the issue and comments on it, linking to the original issue.
Use Case
This duplicate detection workflow significantly streamlines project management by automatically reducing redundant issues, helping maintainers focus on unique, unresolved problems. It saves time by automating the identification and closure of similar issues, preventing contributors from repeatedly addressing the same questions or bugs. With a clear link to the original issue, users can easily follow updates, improving transparency and reducing confusion. The feature enhances productivity by keeping the issue list organized, ensuring that attention goes to high-priority or novel issues. Overall, it fosters a more efficient, user-friendly environment, promoting collaboration and faster resolution of project needs.
Benefits
Time Efficiency
Improved Organization
increased Project Productivity

How it detects similar issues if the contributor create the same issue with different name

The workflow uses NLP and keyword analysis to detect duplicate issues, even with varied titles. It compares both title and content for similar phrases or keywords, allowing for rephrased matches. Synonyms and common terms help identify duplicates with different wording. By closing duplicates and linking to the original, it keeps issues organized and focused on unique problems.


Any plans on making the repo more ergonomic as a CMake dependency?

Hi, first of all, thank you for these C++ bindings! I'm wondering if you have any plans of making the repo more CMake-compatible? (Either by making it fetch Vma and run the generator when the dependency is fetched and built or by adding branches with pre-generated headers for corresponding VkHpp semantic versions that can be pulled instead of having to run the generator).
At the moment, my project's CMakeLists.txt has a structure like this:
# ...

include( cmake/CPM.cmake )
# ...
CPMAddPackage<EMAIL_ADDRESS>)
CPMAddPackage<EMAIL_ADDRESS>)

target_link_libraries( ${PROJECT_NAME} PRIVATE
   # ...
   Vulkan::Headers
   VulkanMemoryAllocator
)

Which generally lends itself to dependencies being handled in an ergonomic manner (~2 lines per dependency) that provides cloning, building, etc as needed during building. But currently there doesn't seem to be any simple way of adding a VmaHpp dependency since it would rely on having to run the generator would result in a lot of additional complexity overhead in CMakeLists.txt, I'd imagine.
Ideally I think a lot of users would like to be able to just do something like this:
# ...

include( cmake/CPM.cmake )
# ...
CPMAddPackage<EMAIL_ADDRESS>)
CPMAddPackage( "gh:YaaZ/VulkanMemoryAllocator-Hpp#target-1.3.220" )

target_link_libraries( ${PROJECT_NAME} PRIVATE
   # ...
   Vulkan::Headers
   VulkanMemoryAllocator-Hpp # or whatever it's called
)

where the branch contains generated headers for a VkHpp target version and a CMakeLists.txt that pulls in the appropriate Vma dependency. This would make life so much easier for dumb end-users like me... 🥲
Alternatively if you know of some Modern CMake project that uses add_custom_command or execute_process and what not to run the generator when needed and cleanly integrating Vma + the built VmaVk as dependencies I'd love to see it so that I can attempt to gleam some insight from it. 🙏 (Sadly a lot of more advanced CMake is still beyond my depth...)

Hi @Falkgaard! The idea was that the end user wouldn't have to run the generator at all. I assumed that Vulkan-Hpp and VMA API wouldn't change very rapidly, so just releasing updates together with VMA would be enough. Not to mention that bringing Java as a dependency to build some C++ project is a bad idea.
I believe managing compatibility with the wide range of versions of Vulkan-Hpp and VMA is difficult, because generator script itself changes and will not work with old Vulkan-Hpp, for exanple. So why do you need to run the generator at all? Doesn't pre-generated headers work for you?
Anyway,  if there's some way to ease the setup, I'm all for it, I'm just not sure running the generator on user machine is the right way.

Addressed in this PR: https://github.com/YaaZ/VulkanMemoryAllocator-Hpp/pull/13


Issue with CheckboxlistfromEnum

i am getting this error when attempting to use checkboxlistfromenum. Am I missing something from the example
{System.NullReferenceException: Object reference not set to an instance of an object.
at TwitterBootstrapMVC.Renderers.Renderer1.IsSelected(Object value, Enum e, Boolean isIEnumerable, Boolean isArray)    at TwitterBootstrapMVC.Renderers.Renderer1.RenderInputListFromEnum(HtmlHelper1 html, BootstrapInputListFromEnumModel model)    at TwitterBootstrapMVC.Controls.BootstrapInputListFromEnumBase2.ToHtmlString()
at System.Web.HttpUtility.HtmlEncode(Object value)
at System.Web.WebPages.WebPageExecutingBase.WriteTo(TextWriter writer, Object content)
at System.Web.WebPages.WebPageBase.Write(Object value)
at ASP._Page_Views_Home_Index_cshtml.Execute() in d:\Projects - AGOTools\AGORepository\AGO NuGet Packages\AGO.Web.BootstrapMVC.TestProj\Views\Home\Index.cshtml:line 18
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.StartPage.RunPage()
at System.Web.WebPages.StartPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at System.Web.Mvc.RazorView.RenderView(ViewContext viewContext, TextWriter writer, Object instance)
at System.Web.Mvc.BuildManagerCompiledView.Render(ViewContext viewContext, TextWriter writer)
at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResult(ControllerContext controllerContext, ActionResult actionResult)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult)    at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult)}

maybe, maybe not. It'd be great to see an example of how you are using this method in the code, what are your values.

@Html.Bootstrap().CheckBoxesFromEnumFor(x=> x.Trial).OrderByValue(true).DisplayInColumns(4, 5, true)

public class HomeViewModelcs
{
public Collection Trial { get; set; }
}
public enum trial
{
    whammy, whammy2
}

the property public Collection Trial { get; set; } should be of the same type as your enum:
public trial Trial { get; set; }

actually, it should be an Enumerable of that enum:
public List<trial> Trial { get; set; }

i think the model was not getting instantiated before it when. sorry about that. I was on a get and did not think about that

no problem, good luck!


codepush release-react fails for Hermes Android builds if CODE_PUSH_NODE_ARGS are set

Description
appcenter codepush release-react fails for Android Hermes builds if CODE_PUSH_NODE_ARGS are set
Repro Steps

Enable Hermes for Android builds
Set CODE_PUSH_NODE_ARGS="--max_old_space_size=2048"
Run appcenter codepush release-react for Android

Expected behavior
CodePush release is created successfully
Details

Is there a particular beacon/command that you are having trouble with?

appcenter codepush release-react

Which version of the App Center CLI are you using?

2.10.0

Which OS version did you experience the issue on?

macOS BigSur 11.1

What command line/shell are you using?

zsh

What version of Node.js and NPM/Yarn are you using?

node v12.18.2, npm 6.14.8

Logs:

Detecting android app version:

Using the target binary version value [REDACTED] from "android/app/build.gradle".

Running "react-native bundle" command:

node --max_old_space_size=2048 node_modules/.bin/react-native bundle --assets-dest [REDACTED] --bundle-output [REDACTED] --dev false --entry-file index.js --platform android --sourcemap-output [REDACTED]
Welcome to React Native!
                Learn once, write anywhere

info Writing bundle output to:, [REDACTED]/index.android.bundle
info Writing sourcemap output to:, [REDACTED]/index.android.bundle.map
info Done writing bundle output
info Done writing sourcemap output
info Copying 324 asset files
info Done copying assets
Converting JS bundle to byte code via Hermes, running command:

node_modules/hermes-engine/osx-bin/hermes --max_old_space_size=2048 -emit-binary -out [REDACTED]/index.android.bundle.hbc [REDACTED]/index.android.bundle -output-source-map -w
hermes: Unknown command line argument '--max_old_space_size=2048'.  Try: 'node_modules/hermes-engine/osx-bin/hermes -help'
hermes: Did you mean '-sample-profiling=2048'?
Error: Failed to release a CodePush update.

Additional note:

While going through the appcenter-cli code, I found that Node arguments meant for the react-native-cli command are being passed to the Hermes command as well. I think there should either be a separate environment variable for the Hermes command or the args should not be passed to the Hermes command

Hello @RishabhKarnad
Thank you for getting in touch with us!
We will take a look and get back to you with an update.

Hey @RishabhKarnad
Thank you for waiting!
I have clarified the information with the CodePush team.
Internally, the release team uses React-native bundle. We suggest to create a project bundle not through AppCenter-CI, but directly through React-native bundle, to see how it works there! If the problem persists, please let us know!

We haven't heard any update from you for a while.
So I'm closing this issue right now, but feel free to reopen it in case of any questions.


[20.09] wordgrinder: fix build

Motivation for this change
Backport of #97911
ZHF: #97479
cc @NixOS/nixos-release-managers
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Please follow https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#backporting-changes and use git cherry-pick -x.

:point_up: Yup, basically needs chrerry-pick info in commit message.
Other than that, WFM macos 10.14.

Oops, sorry about that. Should be fixed now.


Support basic control flow

Support basic control flow such as if statement for error handling and loops
Make sure to keep it minimal.

consider retries and circuit breakers

should implement diffrent error types. retryable and not retryable


update notification configuration support

Issue #, if available:
Description of changes:
Adding cfn support for notification channel configuration filter
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Will reopen a new pull request regarding notification configuration support


⚠ Pactify has degraded performance

In bce1775, Pactify (https://www.pactify.fr/) experienced degraded performance:

HTTP code: 200
Response time: 1546 ms

Resolved: Pactify performance has improved in e0b3012 after 18 minutes.


⚠ Fortnite has degraded performance

In ea424f6, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1655 ms

Resolved: Fortnite performance has improved in 68eba37.


request and fs errors on MacOS

the project development was started on Windows 10, when it was run the first time on MacOS it has thrown error about parsedResult is undefined which causes problems with request module and fs usage it seems.
Possible causes:

fs module security mode
yarn install issue
promise resolve works differently than on Windows
👽

update:

it seems after debugging none of the modules are causing the error
the request options and environment variables are correct
in separate files both fs and request packages work fine
the request callback has an issue and returns undefined

it was silly: the app.env file was saved from Windows so it still had crlf lineendings: resulted in faulty post requests to OCR space. after converting the env file to lf everything works as on Windows.
anyway the error printing should be finetuned a bit.
the truth is out there 👽


mark sys_execute_zkr as unstable

I accidentally opened a duplicate PR. Closing this one. Lets use #2285


GoPro Hero5 Black GPS metadata

Hi David,
Hope all is well.
We created a video at Almeria circuit in Spain. We extracted the GPS sample data from the video file using gpmf-parser (see below).
2017-11-14 14:54:25.558 TrackDay G[32053:20237373] lat = 51.981814, lon = 34.015645
2017-11-14 14:54:25.559 TrackDay G[32053:20237373] lat = 51.981963, lon = 34.015891
2017-11-14 14:54:25.560 TrackDay G[32053:20237373] lat = 51.743817, lon = 33.234863
2017-11-14 14:54:25.560 TrackDay G[32053:20237373] lat = 51.234011, lon = 31.642675
2017-11-14 14:54:25.561 TrackDay G[32053:20237373] lat = 51.571080, lon = 32.678427
2017-11-14 14:54:25.561 TrackDay G[32053:20237373] lat = 51.576497, lon = 32.691670
2017-11-14 14:54:25.562 TrackDay G[32053:20237373] lat = 37.052133, lon = -2.214017
2017-11-14 14:54:25.562 TrackDay G[32053:20237373] lat = 37.052146, lon = -2.214036
2017-11-14 14:54:25.562 TrackDay G[32053:20237373] lat = 37.052159, lon = -2.214055
2017-11-14 14:54:25.563 TrackDay G[32053:20237373] lat = 37.052167, lon = -2.214064
2017-11-14 14:54:25.563 TrackDay G[32053:20237373] lat = 37.052172, lon = -2.214069
2017-11-14 14:54:25.563 TrackDay G[32053:20237373] lat = 37.052172, lon = -2.214067
2017-11-14 14:54:25.564 TrackDay G[32053:20237373] lat = 37.052173, lon = -2.214069
2017-11-14 14:54:25.564 TrackDay G[32053:20237373] lat = 37.052176, lon = -2.214074
2017-11-14 14:54:25.564 TrackDay G[32053:20237373] lat = 37.052177, lon = -2.214075
2017-11-14 14:54:25.565 TrackDay G[32053:20237373] lat = 37.052179, lon = -2.214084
2017-11-14 14:54:25.565 TrackDay G[32053:20237373] lat = 37.052179, lon = -2.214087
2017-11-14 14:54:25.565 TrackDay G[32053:20237373] lat = 37.052181, lon = -2.214093
2017-11-14 14:54:25.566 TrackDay G[32053:20237373] lat = 37.052185, lon = -2.214102
2017-11-14 14:54:25.566 TrackDay G[32053:20237373] lat = 37.052185, lon = -2.214105
2017-11-14 14:54:25.566 TrackDay G[32053:20237373] lat = 37.052187, lon = -2.214109
2017-11-14 14:54:25.567 TrackDay G[32053:20237373] lat = 37.052190, lon = -2.214115
2017-11-14 14:54:25.567 TrackDay G[32053:20237373] lat = 37.052193, lon = -2.214120
2017-11-14 14:54:25.568 TrackDay G[32053:20237373] lat = 37.052196, lon = -2.214127
2017-11-14 14:54:25.568 TrackDay G[32053:20237373] lat = 37.052202, lon = -2.214137
2017-11-14 14:54:25.568 TrackDay G[32053:20237373] lat = 37.052206, lon = -2.214146
2017-11-14 14:54:25.569 TrackDay G[32053:20237373] lat = 37.052212, lon = -2.214156
2017-11-14 14:54:25.569 TrackDay G[32053:20237373] lat = 37.052220, lon = -2.214170
....
Clearly the first 6 GPS coordinates are completely wrong. They are in the middle of nowhere. The rest of GPS coordinates are correct.
Can you please advise why is this happening? It seems to happen to every video.
Here is the raw video file: https://www.dropbox.com/s/jrfvb101xsqxp2b/GOPR0065.MP4?dl=0
Many thanks!
Xiaoyue Huo

The first 5-6 seconds there is no GPS lock at all.  This is typically if you start capture immediately after power up (like if you use quick capture.)  After the lock begins you will get some odd positioning information, yet we provide confidence data so you can determine if you want to use it.  GPSF - GPS Fix  - 0 no lock, 2 - 2D lock, 3- full 3D lock.  In this clip we got a 2D lock at 6 seconds, and a full 3D Lock at the 24s mark.  2D lock is okay, you use GPSP to determine how accurate the lock is.  For those 6 wrong samples, the GPSF was still at 0.

Hi David,
Thanks for your reply. This is very helpful. It means we should start using the GPS from 2D lock.
Many thanks!
Regards,
Xiaoyue Huo


Add armv7 assembly for cc-test

Thanks! Is there any particular reason for adding this though?

I independently rediscovered https://github.com/alexcrichton/cc-rs/pull/627 (since it's not in a release), and was trying to get a simple STR using cc-test, which was not building at all because of the lack of armv7.S.

Ah ok makes sense! FWIW I think the _asm symbol can be removed since that's just me being too lazy to use preprocessor differences to deal with macos/linux differences in the x86_64.S file.


Gdown does not download when called asynchronously (EC2 Ruby on Rails)

Provide environment information
I do not have python installed in my instance
What OS are you using?
Ubuntu 20.04.6
Describe the Bug
When I call a sidekiq job through my ruby on rails application synchronously, the file gets downloaded (I run gdown --fuzzy --id {file_id} -O {file_name}). The same job, with same parameters, in the same machine, when called asynchronously (perform_async), gdown doesnt download, neither is an error being thrown.
Expected Behavior
Downloading should happen even when called asynchronously
To Reproduce
Create a job in ruby on rails that performs system call to gdown download anything. Call it synchronously and asynchronously and see changes

i get 'gdown not found' when I run async, no errors when i run the same command in sync

The issue was that I performed pip install without sudo, so sidekiq could not get the local user installation of gdown. After installing using sudo, this is no longer an issue now


MODINREACH-157 INN-Reach Circulation Flow Action: Receive Un-shipped/Unannounced Item

Purpose
Provide an API endpoint to process receiving actions for unshipped (No ITEM_SHIPPED message received) items associated with an INN-Reach transaction by transaction ID.
JIRA: https://issues.folio.org/browse/MODINREACH-157
Approach

Added endpoint to receive unshipped item
Refactored and re-used logic for item check-in
Added tests

Learning

Pre-Merge Checklist:
Before merging this PR, please go through the following list and take appropriate actions.

Does this PR meet or exceed the expected quality standards?

[ ] Code coverage on new code is 80% or greater
[ ] Duplications on new code is 3% or less
[ ] There are no major code smells or security issues

Does this introduce breaking changes?

[ ] Were any API paths or methods changed, added or removed?
[ ] Were there any schema changes?
[ ] Did any of the interface versions change?
[ ] Were permissions changed, added, or removed?
[ ] Are there new interface dependencies?
[ ] There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

What other modules will these changes impact?
Do JIRAs exist to update the impacted modules?

[ ] If not, please create them
[ ] Do they contain the appropriate level of detail?  Which endpoints/schemas changed, etc.
[ ] Do they have all they appropriate links to blocked/related issues?

Are the JIRAs under active development?

[ ] If not, contact the project's PO and make sure they're aware of the urgency.

Do PRs exist for these changes?

[ ] If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment.  Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

It seems you forgot to update ModuleDescriptor.


Implement reset feedback button

Per user studies, users would find a reset feedback button (that operates independently of the reset code button) useful.

Duplicate of #398 Closing