1MAIL::ACCOUNT::DELRI(3x)Cone: COnsole Newsreader And EMAIL::ACCOUNT::DELRI(3x)
2
3
4
6 mail::ACCOUNT::delRights - Delete an access control list identifier
7
9 #include <libmail/sync.H>
10
11 mail::ACCOUNT *mail;
12 mail::folder *folder;
13
14 bool ok=mail->delRights(mail::folder *folder,
15 std::string &errorIdentifier,
16 std::vector<std::string> &errorRights,
17 std::string identifier);
18
20 This function implements folder access control lists (ACLs). Access
21 control lists define who is allowed to do certain operations on a
22 folder, or on messages in the folder. Folder ACLs are implement only
23 for IMAP accounts on IMAP servers that implement access control lists.
24 This function will fail if folder is not a folder on an IMAP server
25 that supports access control lists.
26
27 mail::folder::delRights removes identifier from the folder´s access
28 control list.
29
30 Identifier
31 Not all servers support every one of the following access control list
32 identifiers. See the server´s documentation to check which access
33 control list identifiers are implemented by the server:
34
35 “anonymous”, or “anyone”
36 This identifier refers to universal access rights given to
37 everyone, including anonymous users (if supported by server).
38
39 “authuser”
40 Same as “anyone”, except for anonymous users. If the server does
41 not implement anonymous access, then “anonymous”, “anyone”, and
42 “authuser” are equivalent.
43
44 “owner”
45 The owner of the mailbox that contains the folder.
46
47 “administrators”
48 Any member of a group that´s defined as an administrator group, in
49 an implementation-defined way.
50
51 “user=username”
52 A single system user, identified by username.
53
54 “group=groupname”
55 Any system user that´s part of a group identified by groupname.
56 Groups are created and managed by IMAP server-specific tools. See
57 the server´s documentation for information on creating and managing
58 groups (if the groups are even implemented by the server in the
59 first place).
60
61 “-identifier”
62 An access control list identifier may be prefixed by a “-”, which
63 refers to a “negative right”. Negative rights explicitly revoke the
64 associated access rights from the identifier instead of granting
65 the right.
66
67 Negative rights are not implemented by all servers. See the
68 server´s documentation to check if the server implements negative
69 access rights.
70
71 Note
72 username and groupname must specified using the UTF-8 character
73 set.
74
75 Access rights
76 At this time, the following access rights are supported:
77
78 “a”
79 Administrator access: view and change folder access control lists.
80
81 “c”
82 Create subfolders.
83
84 “e”
85 Expunge deleted messages from the folder.
86
87 “i”
88 Insert, or add messages to the folder.
89
90 “l”
91 List, or view the folder´s existence. If a folder does not have the
92 “l” access right, the server will not include this folder when it´s
93 asked to list all folders in the folder directory. However, if the
94 “r” access right is present, the folder may be opened if the
95 folder´s name is known.
96
97 “r”
98 Read, or open the folder. An attempt to open the folder will fail
99 without the “r” access right, even if the folder´s name is known.
100
101 “p”
102
103 “Post messages” to the folder. This access right is currently
104 listed in the ACL specification; however its intention is not
105 clear, and most servers do not do anything useful with this access
106 right. It is listed here for information purposes only.
107
108 “s”
109 Allow changing the read/unread status of messages in the folder.
110 The server will not automatically clear the unread message status
111 flag on messages after they are read, or let this status flag be
112 explicitly changed, without the “s” access right.
113
114 “t”
115 Allow tagging of messages as deleted or undeleted. The server will
116 prohibit changing the messages´ deleted message status flag without
117 the “t” access right.
118
119 “w”
120 Allow changing the draft, replied, and marked message status flags.
121 The server will not allow changes to these flags without the “w”
122 access right.
123
124 “x”
125 Allow this folder to be removed. The server will not this folder to
126 be deleted without the “x” access right.
127
128 Extended error reporting
129 Most IMAP servers have restrictions on which combinations of access
130 rights are valid for which folders. See the IMAP server´s documentation
131 to check for any access rights restrictions. The most common
132 restriction is that the “e”, “t”, and “x” access rights must either be
133 set together, as a group, or not. The server will reject or ignore an
134 attempt to set prohibited combinations of access rights for a given
135 folder.
136
137 Some IMAP servers implement an extended form of the access control list
138 protocol which makes it possible to obtain the server´s restrictions.
139 When an attempt to set an invalid access right combination is rejected,
140 errorIdentifier will be set to indicate which identifier´s access right
141 combination was rejected (usually it will be set to the same value as
142 identifier.
143
144 errorRights will be set to an array of strings, each strings consisting
145 of one or more access rights. The first array element, errorRights[0]
146 will contain the minimum access rights required for this folder (which
147 may be an empty string if the folder does not require any minimum
148 access rights for the identifier). Each remaining string lists an
149 optional access right allowed for this folder. If a string contains
150 more than one access right, it means that these access rights must be
151 added or removed from the access control list together, as a group.
152
154 This method returns true if it succeeds, or false if it fails. If the
155 method fails, use mail::ACCOUNT::getErrmsg() to read a brief
156 description of the error.
157
159 mail::ACCOUNT::getMyRights(3x), mail::ACCOUNT::getRights(3x),
160 mail::ACCOUNT::setRights(3x).
161
162
163
164[FIXME: source] 05/08/2010 MAIL::ACCOUNT::DELRI(3x)