-
Notifications
You must be signed in to change notification settings - Fork 4
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
Create user service #217
Create user service #217
Conversation
# Conflicts: # projects/dsp-ui/src/lib/viewer/index.ts # projects/dsp-ui/src/lib/viewer/operations/display-edit/display-edit.component.ts
} | ||
); | ||
// prevent getting info about system user (standoff link values are managed by the system) | ||
if (this.displayValue.attachedToUser !== 'http://www.knora.org/ontology/knora-admin#SystemUser') { |
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.
@mdelez This prevents requesting user info for the system user. Is this fine (the user
prop) remains undefined
.
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.
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.
fixed in 089c5af
@mdelez I figured that standoff links should be flagged as readonly since they cannot be edited anyway. They are managed by the system. DSP task: https://dasch.myjetbrains.com/youtrack/issue/DSP-974 |
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.
Neat :)
@mdelez I think it would be a good idea to mention this service someplace so that it can also be used by other components (rather than requesting users from Knora directly). What would fit best? |
I reapplied the optional chaining operator in 98d2c34 |
@mdelez I think the creator info ( When a method is called from a template like here |
I've noticed this as well when calling methods from the template. I see it quite a lot on StackOverflow but I'm getting the impression that it shouldn't be done? I'm open to any suggestions that prevent multiple triggers for no real reason. |
I think it is totally fine when reacting to an actual event like click etc. In the case at hand, however, the tooltip message can be generated once and then be used in the template: tooltipMsg = '';
onInit() {
this._userService.getUser.subscribe(
user => this.getTooltipText()
);
}
getTooltipText(): string {
const creationDate = 'Creation date: ' + this.displayValue.valueCreationDate;
const creatorInfo = this.user ? '\n Value creator: ' + this.user?.givenName + ' ' + this.user?.familyName : '';
this.tooltipMsg = creationDate + creatorInfo;
} and then in the template: <button mat-button
class="info"
matTooltip="{{tooltipMsg}}"
matTooltipClass="info-tooltip">
<mat-icon>info</mat-icon>
</button> |
* main: Update dependencies (#219) Create user service (#217) DSP-759 Check if a Given Date Can Be Edited (#214) DSP-920 Renaming default github branch to "main" (#216) DSP-881 - Value Component Base Class Changes (#210) chore (package.json): update dsp-js-lib and adapt assertions (#215) DSP-522 Refactor search panel style (#206) Wip/dsp 885 default gravsearch query (#211) # Conflicts: # Makefile ( DSP-987 ) Still a bug in expert search ( DSP-885 ) Expert search default/example Gravsearch query throws a 400 Bad Request error
resolves DSP-775
UserCache
To be done in another PR:
add error handling in case a requests fails (https://dasch.myjetbrains.com/youtrack/issue/DSP-973, relates to https://dasch.myjetbrains.com/youtrack/issue/DSP-402)
Currently, the failed request is stored in the cache which is not what we want.
provide method to refresh the cache for an item (https://dasch.myjetbrains.com/youtrack/issue/DSP-972). Then this method could be used to re-request information for a specific user.