New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add bio fields #6645
Add bio fields #6645
Conversation
50129f9
to
34c8658
Compare
I am not for this change. A writer of the bio fields may be excited and appreciate that it allows markup like that, but I do not think such a markup will actually benefit readers. A colon-separated text or even a normal statements would work well. |
No, this change does not plan for special markup, rather, edit profile form should have +/- field inputs. |
I meant the table is the special markup. |
34c8658
to
97911e3
Compare
@akihikodaki is normalizeAccount not run for the "me" account included with initialState in current master? i am trying to bring my "bio fields" PR up to date and running into this issue... |
I was thinking of doing a similar PR, but making the fields configurable by the admins (perhaps "default fields") and then also adding the ability for "locked" fields, which require an admin or certain application to edit. Our use case is a default field that adds a "verified" status, and that being managed by an application, such that you can't manually add this field, and you could then know with certainty that we have actually verified the user. This is important as we have users that may meet in person (potentially more likely than in other mastodon instances). |
I have just checked it and it looks fine for me. I added diff --git a/app/javascript/mastodon/actions/importer/index.js b/app/javascript/mastodon/actions/importer/index.js
index 5b18cbc1d..907fe558d 100644
--- a/app/javascript/mastodon/actions/importer/index.js
+++ b/app/javascript/mastodon/actions/importer/index.js
@@ -45,6 +45,7 @@ export function importFetchedAccounts(accounts) {
}
accounts.forEach(processAccount);
+ console.log(normalAccounts);
putAccounts(normalAccounts, !autoPlayGif);
return importAccounts(normalAccounts); And here is its output: [{"id":"1","username":"admin","acct":"admin","display_name":"ねこ","locked":false,"created_at":"2018-04-05T12:02:21.752Z","note":"<p></p>","url":"http://localhost:3000/@admin","avatar":"http://localhost:3000/avatars/original/missing.png","avatar_static":"http://localhost:3000/avatars/original/missing.png","header":"http://localhost:3000/headers/original/missing.png","header_static":"http://localhost:3000/headers/original/missing.png","followers_count":1,"following_count":0,"statuses_count":9,"display_name_html":"ねこ","note_emojified":"<p></p>"}] |
97911e3
to
edcac37
Compare
@ThisIsMissEm I'm sorry but that won't work. A verified status like that should not federate, in my opinion, we should not teach users to trust anything like that that comes out of other servers. Besides, you don't even need something so complicated. Add a boolean column to the accounts table and put a checkmark on public profiles, somewhere where it can't be confused with any emoji. |
@Gargron oh, hm. I hadn't really thought about that as a valid option — seemed like it'd cause a compatibility issue and be a bit too much of a fork. I'm still getting bearings as to managing the forked codebase and making sure we can still update to upstream. |
@ThisIsMissEm That's a really small change, I don't think you'll have problems with it. Anyway, left todo in this PR: A UI on the "edit profile" page to edit these fields |
@Gargron for that, is it possible to use react components on the |
1bfe02e
to
251fe66
Compare
account = subject.call('alice', 'example.com', payload) | ||
expect(account.fields).to be_a Hash | ||
expect(account.fields).to include('name' => 'Pronouns', 'value' => 'They/them') | ||
expect(account.fields).to include('name' => 'Occupation', 'value' => 'Unit test') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it worth checking that account.fields
doesn't have more than the payload declared?
de4289e
to
2a4f515
Compare
2a4f515
to
0086549
Compare
These screenshots look awesome! :) |
Regarding verification, see the http://www.kevinmarks.com/distributed-verify.html approach. Add rel=me to these links, and check that they link back with a rel=me as well. Then you can tell that the same person can edit both pages. |
@kevinmarks I did add rel=me, it's the last commit. |
Excellent, I'll give it a try when this gets deployed.
…On Sat, 14 Apr 2018, 12:24 Eugen Rochko, ***@***.***> wrote:
@kevinmarks <https://github.com/kevinmarks> I did add rel=me, it's the
last commit.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6645 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGCwG3Vkq5LYZJNnhWfFJOppSQkmIIlks5todxigaJpZM4SdzKY>
.
|
Does it render to semantic HTML, eg. using a microformat like hCard? |
It's a th/td table. Is there hCard markup for arbitrary information fields? |
I'd probably go for dt/dd
The whole idea of hCard is to tell the fields apart, eg. tag the email field as email, the nickname field as nickname, the birthday field as birthday, etc. Now that I think of it, it'd probably require some further UI to let the users optionally add hCard classes... sounds like a separate feature I guess? |
Arbitrary properties are allowed in h-card, but that might not be ideal.
Worth putting u-url on url properties.
Defined properties are http://microformats.org/wiki/h-card#Properties
…On Sat, 14 Apr 2018, 13:34 Wolf480pl, ***@***.***> wrote:
It's a th/td table.
I'd probably go for dt/dd
Is there hCard markup for arbitrary information fields?
The whole idea of hCard is to tell the fields apart, eg. tag the email
field as email, the nickname field as nickname, the birthday field as
birthday, etc. Now that I think of it, it'd probably require some further
UI to let the users optionally add hCard classes... sounds like a separate
feature I guess?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6645 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGCwNB7RzTkhCkHrfdWcrzE7vklIV8Eks5toezqgaJpZM4SdzKY>
.
|
Well, I never said this was an hCard. The whole idea of this function is to let users define whatever they deem necessary on their profile. So while it could be something common like "homepage", it could also be "github" or "pronouns" or "avatar made by" or "favourite cake". |
You could use the h-card ones as autocomplete (they're based on vcard,
which has had a lot of convergence research)
…On Sat, 14 Apr 2018, 18:04 Eugen Rochko, ***@***.***> wrote:
The whole idea of hCard is to tell the fields apart, eg. tag the email
field as email, the nickname field as nickname, the birthday field as
birthday, etc
Well, I never said this was an hCard. The whole idea of *this* function
is to let users define whatever they deem necessary on their profile. So
while it could be something common like "homepage", it could also be
"github" or "pronouns" or "avatar made by" or "favourite cake".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6645 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGCwPtTYtIZTmZwNlfXFQNSO2yExVmGks5toiwXgaJpZM4SdzKY>
.
|
I actually don't see the benefit of it at all. Do any everyday non-technical users care about being vcard-comforming? Do they want that data to be machine-readable? In my impression, they do not. |
This reverts commit 78ed4ab.
This reverts commit 38ee172.
This reverts commit 627bf47.
* i18n: (zh-CN) #7532 * i18n: (zh-CN) #6984 * i18n: (zh-CN) #7391, #7507 * i18n: (zh-CN) #6998 * i18n: (zh-CN) #7074 * i18n: (zh-CN) #7000, #7032, #7131 (#7032, #7040) * i18n: (zh-CN) #7130, #7188 * i18n: (zh-CN) #6486 * i18n: (zh-CN) #6292 * i18n: (zh-CN) #7347 * i18n: (zh-CN) #6661 * i18n: (zh-CN) #6425 * i18n: (zh-CN) #6597 * i18n: (zh-CN) #6695 * i18n: (zh-CN) #6325 * i18n: (zh-CN) #6460, #7375 * i18n: (zh-CN) #6872 * i18n: (zh-CN) #6818 * i18n: (zh-CN) #7452 * i18n: (zh-CN) #7176 * i18n: (zh-CN) #6460 * i18n: (zh-CN) #7213 * i18n: (zh-CN) #7376 * i18n: (zh-CN) #6556 * i18n: (zh-CN) #6645 * i18n: (zh-CN) #6448 * i18n: (zh-CN) #5303 * i18n: (zh-CN) #7445 * i18n: (zh-CN) Normalization and improvements * i18n: (zh-CN) #7391 * i18n: (zh-CN) #6627 * i18n: (zh-CN) #6956, #7546 * i18n: (zh-CN) #6636 * i18n: (zh-CN) #6610, #6875 * i18n: (zh-CN) #6887 * i18n: (zh-CN) #4514 * i18n: (zh-CN) #6628 * i18n: (zh-CN) #6771 * i18n: (zh-CN) #6772 * i18n: (zh-CN) #7178 * i18n: (zh-CN) #7521 * i18n: (zh-CN) #6570 * i18n: (zh-CN) #6593 * i18n: (zh-CN) #6423 * i18n: (zh-CN) #6157 * i18n: (zh-CN) #7089 * i18n: (zh-CN) #6733 * i18n: (zh-CN) #7072 * i18n: (zh-CN) #6520 * i18n: (zh-CN) Improvment * i18n: (zh-CN) #6631
@@ -75,6 +75,7 @@ | |||
t.boolean "memorial", default: false, null: false | |||
t.bigint "moved_to_account_id" | |||
t.string "featured_collection_url" | |||
t.jsonb "fields" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If fields
is JSONB shouldn't account.fields
be a Hash and not an Array?
See report on https://discourse.joinmastodon.org/t/error-on-profile-edit-for-single-user-nomethoderror-undefined-method-for-hash/1563
@saper no, because profile fields are sorted and json objects are arbitrary
order
…On Thu, Dec 27, 2018, 8:22 AM Marcin Cieślak ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In db/schema.rb
<#6645 (comment)>:
> @@ -75,6 +75,7 @@
t.boolean "memorial", default: false, null: false
t.bigint "moved_to_account_id"
t.string "featured_collection_url"
+ t.jsonb "fields"
If fields is JSONB shouldn't be a Hash and not an Array?
See report on
https://discourse.joinmastodon.org/t/error-on-profile-edit-for-single-user-nomethoderror-undefined-method-for-hash/1563
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6645 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORVxjdEx-uiiilDi9VG0EwJQhLYgnnks5u9Ne9gaJpZM4SdzKY>
.
|
Thanks. But it seems to me that JSONB storage will lose that ordering? Is this the correct serialization (or am I completely confusing something)? |
@saper jsonb columns can be any json type—arrays, objects, or primitive values. |
Ok, but when ActiveRecord fetches JSONB from PostgreSQL, what do we get? I am just searching for clues related to https://discourse.joinmastodon.org/t/error-on-profile-edit-for-single-user-nomethoderror-undefined-method-for-hash/1563 - I think I am probably on a totally wrong path. |
@saper it will return an array for a json array, a hash for a json object, a corresponding rails value (string, number, boolean etc) for json primitive values. |
Thank you! |
A feature that allows adding structured data to profiles. Based on @marrus-sh's implementation (could not find a glitch-soc PR for it though), except the fields are not part of the text.
Screenshots:
How they are stored internally: As a JSONB column on the accounts table, which contains an array of
{ "name": "", "value": "" }
objects. Why: Normally something like this would be implemented via a has_many association with separate database records for every field, but I do not want to add so many more eager loaded queries to everywhere, and the fields don't really need to be queried or updated standalone, so being nested in the account record seems okay.How they are federated: Inside the actor's
attachment
tag they are represented as:Where PropertyValue and value come from the schema.org context, while name comes from the vanilla ActivityStreams context. The value can contain HTML, while the name cannot.