Anyone figured it out? I don't see those fields used in the Contacts app, neither does the documentation provide any clue.
#include <bb/pim/contacts/AttributeKind>
From the docs:
A ContactAttribute is a single piece of information about a Contact,
such as a phone number or email address. A ContactAttribute has a
kind, which specifies high-level metadata about the attribute. Kinds
of attributes are represented by the AttributeKind::Type enumeration
and include email, phone number, name, and so on. A ContactAttribute
also has a sub-kind, which specifies additional, more granular
metadata about the attribute. Sub-kinds are represented by the
AttributeSubKind::Type enumeration and include values such as Work
(for emails), Home (for phone numbers), and so on.
https://developer.blackberry.com/cascades/reference/bb_pim_contacts__contactattribute.html
Related
The background first:
I have an application where a logged-in user(employee) X can see a list of all other users (employees). If the logged-in user X is a manager (their designation), then they can also edit certain attributes of the users they manage. For example, the location, designation, and the department of the user being edited. It should be noted X can edit only those employees who report to him/her, which means there are users which X is not allowed to edit.
When X clicks on a user to edit it, they navigate to a page like http:myapp.com/dashboard/editUser/<ID_OF_THE_USER_BEING_EDITED>
Obviously, X can get smart and manually edit the URL and put in the id of a user they are NOT allowed to edit, so before loading the edit form I need to check whether X has the authorization to edit user Y.
if X is authorized to do so, then that page displays a form (with the current attributes of the users pre-filled in the appropriate fields) to edit the user. Else, I display an 'Access Denied' kind of message.
Right now I have created a very badly named temporary endpoint (/api/v1/maybe_edit_user/?jwt=<TOKEN>&userId=<USER_BEING_EDITED>).
This grotesque-looking endpoint does 2 things:
It extracts the currently logged-in user from the token, and checks whether it has the required access level to edit the user (passed through the GET parameter userId)
If yes, then it returns the current attributes (name, email, location, designation, and other stuff) in the response, which is then pre-filled in appropriate fields when the form is displayed.
Once X submits the form, a PUT request is sent to another endpoint (/api/v1/users/<USER_ID_OF_Y> PUT) and the user Y is updated.
While this works, I don't find it attractive. I am trying to learn to write better, cleaner, and more organized code that is compliant with the standards.
The best practices for REST suggest that all endpoints should be nouns. My endpoint, on the other hand, is not even a simple verb. It's a god-forsaken phrase at the very minimum.
So, the questions here are:
How should I name my endpoint.
Should I use a single endpoint to check for permission, AND fetching the attributes of the user being edited, like I am doing right now? Or should I break them into 2 separate endpoints?
The fact that there is an access control list is an unrelated concern; ignore it.
Resource identifier identify resources. Resources are generalizations of documents.
You want an identifier that is consistent with the production rules of RFC 3986, and it is often convenient (but not required) to choose spellings that enable leverage of URI Templates (RFC 6570), but otherwise the machines don't care.
That means you can choose a spelling that makes things easier for humans; you get to choose which humans get priority here.
it returns the current attributes (name, email, location, designation, and other stuff) in the response
That's your hint as to what the document is; some sort of digest of Bob's... profile? employee record? dossier? that is apparently optimized for use in this specific kind of form.
So the identifier could be as simple as
/this-specific-kind-of-form/source-data/Bob
and a request might look like
GET /this-specific-kind-of-form/source-data/Bob HTTP/1.1
Authorization: Bearer <token>
The implementation looks largely like your sketch - verify the token, compare the claims to those that are required, and return either the resource or some flavor of Client Error (4xx).
The best practices for REST suggest that all endpoints should be nouns.
Don't read too much into that.
Notice that all of the following resource identifiers work:
https://www.merriam-webster.com/dictionary/get
https://www.merriam-webster.com/dictionary/post
https://www.merriam-webster.com/dictionary/put
https://www.merriam-webster.com/dictionary/patch
https://www.merriam-webster.com/dictionary/delete
You can click on any of those links, and your browser will create the correct HTTP request, and the server will do the expected thing.
How can I send a gel:email to multiple recipients? I have records with 3 email addresses in each and I want to send the same email to all 3.
This is my current code:
<core:forEach items="${getDetails.rows}" var="row">
<core:set value="${row.Manager_Email}" var="manager" />
<core:set value="${row.Delivery_Manager_Email}" var="deliveryManager" />
<core:set value="${row.Director_Email}" var="director" />
<core:choose>
<core:when test="${status == 1}">
<gel:email from="Clarity_Do-Not-Reply#gov.nl.ca" fromName="Clarity Administrator" to="${manager};${deliveryManager};${director}" subject="Notification: Project is due to finish within 7 days">
I've tried that and:
to="${manager;deliveryManager;director}"
Neither seem to work. The doc says they can be split with the ; but it doesn't seem to be working. What am I doing wrong?
Does it work with just one of them? I would start and establish that the mail server works in this environment. Choose one of those variables and print it out. If it's not what you are expecting then fix your query or wherever you are getting those bound variables. If it is correct then remove the other two recipients and establish that you can send an email successfully to just one of the recipients. If that works then continue troubleshooting.
If it doesn't work then you may discover that your mail server does not allow relaying, unauthenticated services or sending mail from a non-existent email account. You can start checking those things.
One of the issues with both the GEL email tag and the CORE email tag is that it doesn't support including the same email address twice. If you check your project you might find that the same resource is listed as both delivery manager and manager or director, etc. This is a problem for the tag.
You can get around this by placing all recipients into a data structure that doesn't allow duplicates (like a hash map/set) and then iterate them out back into a semi colon delimited String.
There are probably lots of examples of this type of thing on regoXchange, a huge repository of free GEL scripts and Clarity related customizations and development.
This approach that was in your original script example is the correct way to do it: to="${manager};${deliveryManager};${director}"
That is, using a single delimiter type (semi-colon in this case) to separate each evaluated variable value.
The style from your second attempt definitely will not work as ${manager;deliveryManager;director} is not a valid JEXL expression.
There are additional points to be aware of, such as:
Each of the values in the to attribute should not have anything else that can be mistaken for another delimiter type (e.g. no spaces or commas), as you may not mix and match.
Only use the email address directly, meaning some.one#somedomain.com and don't use forms like "One, Some" <some.one#somedomain.com>
Make sure none of the email addresses are duplicated in the list. Every address must be unique. As mentioned in the answer provided by #coda, you can filter duplicates out with some extra GEL or you can put the logic into your query (the row source) to de-duplicate.
If this is running in a SaaS environment, make sure none of the user addresses you are picking up are among the defaults for some built-in user accounts like username#mailserver.com or similar, as they have resulted in emails being filtered out before sending.
For creating an anonymization/de-identification tool I would like to delete/overwrite all tags/attributes from the DICOM file that are not necessary. I've searched around the internet, but have not found a clear list of which tags are mandatory for a DICOM file.
I found out that there are multiple types, type 1 is mandatory, type 2 must at least be an empty string and type 3 can just be deleted. But so far I have not found an easy list online with all tags and their types. Does anyone have list of tags and types or a list of mandatory tags for DICOM file?
The mandatory attributes (given by their tags) depend on the SOP Class of the DICOM file.
read the Media Storage SOP Class UID (0002,0002) from the File Meta Information (meta header)
in the DICOM standard, locate the IOD correspondent to the SOP Class UID (e.g. "1.2.840.10008.5.1.4.1.1.1" = Computed Radiography Image Storage)
the IOD specification lists the mandatory and optional modules (e.g. Patient Module, General Image Module, etc). The modules marked with M are mandatory, C=conditional, U=optional (user option)
each module lists the mandatory and optional attributes (e.g. the Patient module includes the patient name, the patient ID, sex, etc). Attributes marked with 1 are mandatory, 2=mandatory but can be empty, 3=optional, 1C=mandatory if some conditions are satisfied, 2C=mandatory but can be empty if some conditions are satisfied
There is a nice Presentation about "De-Identification" by David Clunie here: https://www.dclunie.com/papers/D2_1045_Clunie_Deidentification.pdf
The concepts presented went into the DICOM Standard Part 15, Annex E - De-Identification
The current list of attributes to handle for a valid de-identifier is clearly described in the DICOM standard PS 3.15:
Attribute Confidentiality Profiles
In particular see the table:
Table E.1-1. Application Level Confidentiality Profile Attributes
As a side pay special attention to the private tags, as described in the following profile:
Retain Safe Private Option
For historical reference, you should also pay attention that the DICOM standard has greatly changed since the 2008 edition:
ftp://medical.nema.org/medical/dicom/2008/08_15pu.pdf
Some tool (eg. gdcmanon) implements the old section PS 3.15 / E.1 / Basic Application Level Confidentiality Profile (Implementation of E.1.1 De-identify & E.1.2 Re-identify).
Finally, DicomCleaner should give you an idea of what a quality implementation looks like:
How to use DicomCleaner
The original wording of the question: "I would like to delete/overwrite all tags/attributes from the DICOM file that are not necessary" seems to be in conflict with the definition of "de-identification". So either the question is poorly formulated, or you are missing the fact that Type 1 attribute may contain Protected Health Information.
How can I verify if an incoming field is a valid e-mail? Is there a way to use string-functions or anything in Firestore security rules?
Example:
Let's say I have a Create-Request with a field called "email". In my Firestore security rules, I would like to check if the email is a valid email address:
contains '#'
ends with either .xx or .xxx (a casual country-domain-ending)
has a '.' before the last three or two letters of the email
the '.' does not follow directly after the '#' - at least two letters have to be in-between
So that e.g. example#emailprovider.com gets accepted, but not example#.com.
I know that this check is quite extensive and further would like to know if it makes sense to introduce such a validation to security rules?
You can use rules.String.matches.
See
https://firebase.google.com/docs/reference/rules/rules.String#matches
https://github.com/google/re2/wiki/Syntax
How to validate an email address using a regular expression?
Performs a regular expression match on the whole string.
A regular expression using Google RE2 syntax.
If you want to set only email address then It's necessary to validate the field as email address.
I found an example of a regex (and adjusted a bit):
^[a-zA-Z0-9._%+-]+#[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,5}$
The source of this is at the bottom of the following page:
https://firebase.google.com/docs/reference/security/database/regex
You should also take into account the note as well:
Note: THIS WILL REJECT SOME VALID EMAILS. Validating email address
in regular expressions is difficult in general. See this site for
more depth on the subject.
I am using spring validation:
#NotNull
#Size(max = 128, min = 6)
#Email
private String username;
But I want to ensure that the new TLDs are respected. Does spring even look at the email domain TLDs and ensure they are adhered to?
Just to give an example: I want the following to validate: joe#emperor.clothing
What exactly are you after? What do you mean with:
But I want to ensure that the new TLDs are respected
#Email is Hibernate Validator provided Bean Validation constraint which will verify whether a given email adheres syntactically RFC 2822. It does so via a regular expression.
The javadocs of EmailValidator says:
The specification of a valid email can be found in RFC 2822 and one
can come up with a regular expression matching all valid email
addresses as per specification. However, as this article discusses it
is not necessarily practical to implement a 100% compliant email
validator. This implementation is a trade-off trying to match most
email while ignoring for example emails with double quotes or
comments.
This also means, that there is no internet connection established to for example verify whether a top level domain actually exists (in case that is what you mean).