OpsPortal issueshttps://gitlab.in2p3.fr/groups/opsportal/-/issues2024-01-16T10:27:47+01:00https://gitlab.in2p3.fr/opsportal/sf3/-/issues/164Improve CSI API2024-01-16T10:27:47+01:00Cyril L'OrphelinImprove CSI API
- [ ] is it possible that you could create API when I would be able to download that pakiti history for x days back?
- [ ] is it possible that in daily reports you will not take only last status, but you would take history for example ...
- [ ] is it possible that you could create API when I would be able to download that pakiti history for x days back?
- [ ] is it possible that in daily reports you will not take only last status, but you would take history for example 7 days back and if there will be CRITICAL then it will be in morning report?... I know that it can be confusing for us if last status is already OK, but it is still better for us to check if the site fixed that vulnerability then not getting it at all. Because as you said that you are taking only the last report then it is possible that one CE(CRITICAL) is vulnerable but we won't see it because other CE(with status OK) for that site will report before 7am and we will think everything is ok.
- [ ] The CVE is not always properly exposedv6.10https://gitlab.in2p3.fr/opsportal/sf3/-/issues/163Aligning the Operation Portal with EGI Brand Guidelines2024-01-16T10:24:08+01:00Cyril L'OrphelinAligning the Operation Portal with EGI Brand GuidelinesI am writing to inform you about our recently published brand guidelines, which outline the visual identity and design principles for the EGI brand, materials, website, and platforms. Since you are responsible for the Operation Portal (h...I am writing to inform you about our recently published brand guidelines, which outline the visual identity and design principles for the EGI brand, materials, website, and platforms. Since you are responsible for the Operation Portal (http://operations-portal.egi.eu/) development and maintenance, we kindly request your cooperation in aligning your platform's visual elements with the EGI brand.
Our new brand guidelines provide clear instructions for website developers to ensure a cohesive and unified visual identity across all EGI platforms. It is essential for us to maintain consistency in our digital presence to enhance our brand recognition and user experience.
We understand that each platform has its unique identity, and we are not seeking a complete revamp. Instead, we request specific adjustments that will visually align your platform with our brand. These adjustments might include incorporating our colour schemes, typography, imagery usage, and other design elements in subtle ways that resonate with the EGI brand.
You can access the brand guidelines document through the following link: https://cdn.egi.eu/app/uploads/2023/03/egi-brandguide-2023.pdfv6.10https://gitlab.in2p3.fr/opsportal/eosc-opsportal/-/issues/25Jira authentication to be changed2023-06-30T08:51:12+02:00Cyril L'OrphelinJira authentication to be changedIt seems that the operation portal is making REST call on jira.egi.eu
using Basic Authentication. This is no longer going to work and should
be replaced by a Bearer access token as soon as possible. I'd really
appreciate if you could com...It seems that the operation portal is making REST call on jira.egi.eu
using Basic Authentication. This is no longer going to work and should
be replaced by a Bearer access token as soon as possible. I'd really
appreciate if you could come back to me and tell me if you can change
that, or give me a plan or a time frame. I believe that such
modification should be quite trivial to do.
One can issue a token by logging using the "opsportal" user, then
visiting the profile page and clicking on "Personal Access Tokens" on
the left side, or by visiting the following URL
https://jira.egi.eu/secure/ViewProfile.jspa?selectedTab=com.atlassian.pats.pats-plugin:jira-user-personal-access-tokens
I'd strongly recommend to un-click the "Automatic expiry" box, so that
the token stay forever valid. If not, Jira will send a email to
cic-information@cc.in2p3.fr shortly before the expiration, and the
token will cease to work upon expiration.
You can find more information on the usage of a Bearer token for doing
Jira REST calls at the following page, under the section "Using PATs":
https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html#UsingPersonalAccessTokens-UsingPATs
Also, if, for some very unlikely reason, you would like to
programmatically generate tokens, please do not use the Basic Auth
method as well. And please bear in mind that the number of live tokens
allowed per user is limited.
I stay at your disposition to provide any further information, help,
or discuss your concerns. I'd like to thank you in advance for your
feedback.Cyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/sf3/-/issues/150[VO ID CARD] Bug with multiple email address es2023-03-13T12:34:37+01:00Cyril L'Orphelin[VO ID CARD] Bug with multiple email address es> Dear Cyril,
> We found a problem when updating VO ID Cards. When setting up multiple addresses, we always get an error, as depicted below [1].
> Could you please verify if this is a bug?
> To reproduce the issue, edit any VO ID Car...> Dear Cyril,
> We found a problem when updating VO ID Cards. When setting up multiple addresses, we always get an error, as depicted below [1].
> Could you please verify if this is a bug?
> To reproduce the issue, edit any VO ID Card General information (e.g. https://operations-portal.egi.eu/vo/update/serial/...) and try to use multiple email addresses for the Security field.
> Thanks,
> Nacho.
![image](/uploads/279b7070d43b0a449854b0387909e07f/image.png)ZZZ[GONE] PERRIER GuillaumeZZZ[GONE] PERRIER Guillaumehttps://gitlab.in2p3.fr/opsportal/sf3/-/issues/142Filter logs returned by Lavoisier2023-03-03T11:26:37+01:00Cyril L'OrphelinFilter logs returned by LavoisierIn case of problem with Lavoisier connection an error is thrown
- the logs are too verbose
- we should manage it like 'ERROR 500'In case of problem with Lavoisier connection an error is thrown
- the logs are too verbose
- we should manage it like 'ERROR 500'Cyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/sf3/-/issues/139Evaluate the possibility to use VO Manager role from AAI to give access to VO...2023-03-03T11:26:49+01:00Cyril L'OrphelinEvaluate the possibility to use VO Manager role from AAI to give access to VO ID cardsAttributes related to the VO/group membership and role information are available in AAI.
Maybe it could be used to identify VO Managers .
# Syntax
An entitlement value expressing group membership and role information has the followi...Attributes related to the VO/group membership and role information are available in AAI.
Maybe it could be used to identify VO Managers .
# Syntax
An entitlement value expressing group membership and role information has the following syntax (components enclosed in square brackets are OPTIONAL):
` urn:mace:egi.eu:group:<GROUP>[:<SUBGROUP>*][:role=<ROLE>]#<GROUP-AUTHORITY>`
where:
- `<GROUP>` is the name of a VO, research collaboration or a top level arbitrary group. <GROUP> names are unique within the urn:mace:egi.eu:group namespace;
- zero or more `<SUBGROUP>` components represent the hierarchy of subgroups in the <GROUP>; specifying sub-groups is optional
- the optional `<ROLE>` component is scoped to the rightmost (sub)group; if no group information is specified, the role applies to the VO
- `<GROUP-AUTHORITY>` is a non-empty string that indicates the authoritative source for the entitlement value. For example, it can be the FQDN of the group management system that is responsible for the identified group membership informationCyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/sf3/-/issues/135Add anonymisation of data > 18 months2023-03-03T12:31:39+01:00Cyril L'OrphelinAdd anonymisation of data > 18 monthsAdd anonymisation of data > 18 months
- [ ] Users Table
- [ ] other tables ?Add anonymisation of data > 18 months
- [ ] Users Table
- [ ] other tables ?Cyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/sf3/-/issues/131Capture of VOMS Users2023-03-03T12:32:33+01:00Cyril L'OrphelinCapture of VOMS Users- Email is not updated if the user already exists- Email is not updated if the user already existsCyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/lavoisier-vapor/-/issues/1Improve VAPOR_DIRAC view2022-02-03T15:49:24+01:00Cyril L'OrphelinImprove VAPOR_DIRAC view- add site status : production / certified, or unknown site in GOCDB
- add csv export
- add a complete list in one call- add site status : production / certified, or unknown site in GOCDB
- add csv export
- add a complete list in one callCyril L'OrphelinCyril L'Orphelin2022-02-15https://gitlab.in2p3.fr/opsportal/eosc-opsportal/-/issues/22[EOSC Metrics] Other filters than EGI-ACE for Service Order metrics2022-06-03T13:27:35+02:00Cyril L'Orphelin[EOSC Metrics] Other filters than EGI-ACE for Service Order metricsIn the "STATS per MONTH" in the Service Order Metrics there is a filter for EGI-ACE it would be nice to offer similar stats to all INFRAEOSC-07 projects if they are interested in.In the "STATS per MONTH" in the Service Order Metrics there is a filter for EGI-ACE it would be nice to offer similar stats to all INFRAEOSC-07 projects if they are interested in.1.5Cyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/eosc-opsportal/-/issues/21[SOMBO] Mechanism to inform the readiness of a service2022-06-03T13:28:05+02:00Cyril L'Orphelin[SOMBO] Mechanism to inform the readiness of a service> It would be nice to put in place a mechanism for the provider to let us know not only when an order is validated but also when it is served; not sure how this can be implemented but I am available to discuss this and look for options. ...> It would be nice to put in place a mechanism for the provider to let us know not only when an order is validated but also when it is served; not sure how this can be implemented but I am available to discuss this and look for options.
Debora1.5Cyril L'OrphelinCyril L'Orphelinhttps://gitlab.in2p3.fr/opsportal/sf3/-/issues/106[DASHBOARD] Check services status more dynamically2021-05-19T09:46:37+02:00Cyril L'Orphelin[DASHBOARD] Check services status more dynamicallyThe service status is determined when an alarm is registered and is registered in DB.
This status is never updated if the alarm is not updated.
Instead of registering this status in DB , it could be done with Lavoisier and the PSCORE_hos...The service status is determined when an alarm is registered and is registered in DB.
This status is never updated if the alarm is not updated.
Instead of registering this status in DB , it could be done with Lavoisier and the PSCORE_host_service viewCyril L'OrphelinCyril L'Orphelin