Inet Service Model Updates

[invisig0th]

No description provided.

[ancailliau]

Feedback on inet:service:message

• from should be an account, or a string, and then from:account the account.
• Field deleted is missing.
• I would miss place or telem, could be modeled as light edge though. Same with the client.
• We store the raw message as a file and reference with a light edge, so not a field data limited to a JSON format.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.62%. Comparing base (2ce1ba9) to head (161e3f5).
Report is 13 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3561      +/-   ##
==========================================
- Coverage   97.72%   97.62%   -0.11%     
==========================================
  Files         237      237              
  Lines       50619    50619              
==========================================
- Hits        49467    49416      -51     
- Misses       1152     1203      +51     

Flag	Coverage Δ
linux	97.62% <100.00%> (-0.01%)	⬇️
linux_replay	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Cisphyx]

Suggested change

	'doc': 'The name of the group on this platform.'}),
	('profile', ('ps:contact', {}), {
	'doc': 'The name of the group on this platform.'}),
	('profile', ('ps:contact', {}), {

[therealsilence]

Mostly minor/clarifications, a few issues.

[therealsilence]

Not sure several of the props declared on inet:service:object (used by inet:service:action) are applicable here, or if they are they represent a specialized use case (creator, owner, created, removed?). Those seem more applicable to object-type access vs. authentication. I'm ok with having edge case props on a form but will caveat that everyday users may find it confusing.

[invisig0th]

Hm, agreed. Lets talk about it in the regular weekly meet :)

[therealsilence]

Should this include a reference to a inet:service:rule, inet:service:permission, or to indicate the type of access attempted? Leave as TODO for now?

[invisig0th]

Would the referenced rule essentially mean "this is the rule which allowed/denied the access" ?

[therealsilence]

Hrrm. Was actually thinking of "type of access requested". If access fails, an error message (if available) might let me know what someone tried to do ("thesilence attempted to delete visi's macro"). But in the case of "access succeeded" (or the absence of an error message) , the form doesn't seem to capture what the requestor did / tried to do.

"Type of access requested" is not necessarily 1:1 with "rule that allowed or denied access". 🤔 Do we think it's a close enough proxy? Am I down a rabbit hole?